Looks like that. But what is strange, since my post here I've set logging to my WAN rule to see incoming traffic to the OpenVPN port, yet for the 2 entries in the OpenVPN log I only see one matched entry in the firewall log. I would expect them both in the firewall log.
I'm on 2.5 (upgraded from working 2.4.5p1) I imported both their CA the client certificate and set
Data Encryption Algorithms to:
Encryption Algorithm: AES-256-CBC
NCP Algorithms: AES-256-CBC
The Fallback Data Encryption Algorithm to:
Auth digest algorithm to:
Decompress incoming, do not compress outgoing (Asymmetric)
Disable Compression [Omit Preference]
net30 - Isolated /30 network per client
Ping settings set to:
I do have my default gateway set to my ISP, and I and set rules for the packets I want routed via the tunnel. I also tag the packets and added a floating rule looking for those tagged packets in case the tunnel is down,and drop them, since vpn traffic I want out the tunnel only and never routed via default gateway.
It was a MTU issue and most frustratingly it came to me at random. There was no particular reason to it other than me going, "Huh. I've never thought of MTU." and did some Googling to find the right MTU for OpenVPN and found that the default 1500 was too much for my network and had to step it down to around 1160 which fixed all the issues I've had before. I'm sure the routing quirk on the host was a one-off, but finally the VPN works just like how I want it.
@bob-dig Sorry, my error, and sincere apologies. I now realise that I was actually examining the wrong server config file in /var/etc/openvpn/ - I now have three separate OpenVPN Servers. Please ignore the post.
@viragomann La vpn se establece sin errores, si tengo habilitado el acceso remoto, haciendo pruebas no llego con ping a ningún equipo.
Have to use a translater.
See, what I wrote above.
You can simply check that with pfSense, using the Ping tool in the Diagnostic menu.
Do a ping to a computer with default options. I think, you will get responses.
Then change the sourece to OpenVPN and try again. Do you still get a response?
list itemBefore anything, follow the instructions on JumpCloud for setting up LDAP and binding a user to LDAP: https://support.jumpcloud.com/support/s/article/using-jumpclouds-ldap-as-a-service1
The following command outputs the certificate authority to the /tmp/ directory as jumpcloud.chain.pem.
echo -n | openssl s_client -connect ldap.jumpcloud.com:636 -showcerts | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/jumpcloud.chain.pem
Skip the first certificate of the chain.
Add the next 3 certificates in the chain individually as Certificate Authorities in pfSense using the following settings:
System > Cert. Manager > CAs tab > Add
Descriptive name: JumpCloud CA (add a 1, 2, and 3 after each certificate)
Method: Import an Existing Ceritifcate Authority
Trust Store: check this box
Randomize Serial: check this box
Certificate Data: paste the single certificate here
The following command outputs only the JumpCloud LDAP Server certificate to the /tmp/ directory as jumpcloud.ldap.pem
echo -n | openssl s_client -connectldap.jumpcloud.com:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/jumpcloud.ldap.pem
Add the Server Certificate to pfSense.
System > Cert. Manager > Certificates tab > Add/Sign
Method: Import an Existing Certificate
Descriptive name: JumpCloud Server Certificate
Certificate data: paste the certificate here
If you don't have a JumpCloud account set up and bound to LDAP, you'll need to do that first.
You can use your account or create a new user. There only needs to be one bound account but there can be multiple.
Users > Select the user you'd like bound to LDAP > User Security Settings and Permissions > check the Enable as LDAP Bind DN box and Save user
LDAP > Add a new LDAP server > Add the user groups or users
Create the LDAP Server in pfSense
NOTE: you can get YOUR_ORG_ID from JumpCloud's Settings page
System > User Manager > Authentication Servers tab > Add
The thing I didn't understand is that selecting a gateway in the rule other than Default directs all matching traffic only to that gateway, unlike where the default gateway choice is left alone. I added the inverse destination you suggested.
That didn't work for internal traffic at first, but then I realized that I'd selected the WAN gateway in the following Default allow any to LAN rule, and so that prevented interLAN traffic. (I had done that for all VLANs in order to enable access to the internet for those without the additional NAT rules.)
So I selected the "Don't pull routes option in the OpenVPN client definition and then changed the gateway in the Default allow any to LAN rule to Default. I've deleted the additional rule above the VPN rule that allowed access to other subnets. This is more elegant, and things seem to be working.
I found the problem. There was a floating rule that disabled access to the internal network. We never used floating rules, but we did have virtual networks where the rules were for and these networks were removed with the move to the new location. After disabling these rules my test works (a simple webserver with a default page and a NAT-rule to access it from outside)
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.