-Edit 2: -
Even though the tunnel is disabled in config, it can still be alive (don't ask)
It even survives a service cycle. This is probably the reason the overlap existed in the 1st place...
@divsys
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.
@gertjan well its definately related from what I can see.
I have managed to fix the fluctuating speeds by unchecking Enable Data Encryption Negotiation and changed the Fallback Data Encryption Algorithm to AES-128.
I get lots of warnings in the logs but it connects and my speeds are now consistently back to how the were before my upgrade.
How that's working or why, no idea but it seems to fix it for me so guessing from your comment even though it shouldn't affect it, it is for me.
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:
AES-256-CBC
Auth digest algorithm to:
SHA1 (160-bit)
Allow compression:
Decompress incoming, do not compress outgoing (Asymmetric)
Compression:
Disable Compression [Omit Preference]
Topology:
net30 - Isolated /30 network per client
Ping settings set to:
Inactive:
0
Ping method:
keepalive
Interval:
15
Timeout:
120
Custom options:
remote-cert-tls server;
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.
Solution Found
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.
On OpenVPN 2.5.0 you don't pick an encryption algorithm, you pick a list of Data Ecnryption Algorithms and set a Fallback Data Encryption Algorithm for when cipher negotiation doesn't work.
@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?
If anyone else hits this, netgate support found I was using "openvpn" in the outbound NAT rules as the interface. Specifying this to the VPN Client interface resolved the issues.
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
Save
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
Save
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.
In JumpCloud:
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)
