@techy82 That LAN rule you show a snip of, is there anything above that? If it works with the openvpn off then it really looks like an incorrect rule.

@Derelict: Make sure the inbound traffic is NOT matched by rules on the OpenVPN tab (disable all rules there) and IS matched by rules on the OVPN tab. That will get reply-to functioning. Removing the rules from the OpenVPN tab resolved the issue. Thanks!

Why would you want to do that?  that is just the shared secret.. Really no point in that being any higher.. https://community.openvpn.net/openvpn/wiki/Hardening that is the shared secret key, anything over 2048 is just pointless.. This is the key used to sign the tls packets..  Would be better to set your tls min to 1.2 and enable tls encryption… Keep in mind that the some clients do not support tls crypt - I do not believe the ios openvpn connect app as enabled its use yet, etc.  But really don't see how increasing that would matter..

@viragomann: Since you're directing the QNAP Traffic and also it's DDNS registration through the OpenVPN, it will register the public OpenVN IP in the myQNAPcloud DDNS. However, presumably your VPN provider doesn't forward access to you. So if you want the QNAP traffic to bypass the VPN and go over your WAN gateway, just add a firewall rule for the QNAP internal address as source to your LAN interface, allowing access to public addresses (or only to the myQNAPcloud DDNS) over the WAN gateway. You can select the gateway in the advanced options of the rule settings. Thank you, will give that a try.

@dsp3: From your pfsense openvpn log ERROR: FreeBSD route add command failed: external program exited with error status: 1 Overlapping subnets I would guess. You need to check this. Thank you for tossing an idea my way.  I started diving into that error and researching errors with route pulling/pushing.  After a bunch of research I remembered I hadn't looked at the PIA openvpn log to see if it too had the error you mentioned and it did not.  I've done some further research regarding the PIA side of things and I'm no further than I was before.  I've attached the PIA log from openvpn for review and the only thing that I can see as an issue is the link-mtu/cipher/auth/keysize get the "used incorrectly" error (I've seen a ton of people have that issue with PIA and none of them talk about the issues I'm having) but I'm open to suggestions on that front.  I don't see any other errors in that log but maybe my eyes are missing something.  Any thoughts from here? [pfSense OpenVPN Log2.txt](/public/imported_attachments/1/pfSense OpenVPN Log2.txt)

Hi! Is there any step by step instructions for this? Also… it it possible that somebody update purevpn instructions for purevpn site for version 2.4 pfsense? https://support.purevpn.com/pfsense-openvpn-configuration-guide

You should probably start a new thread. But in general you probably need to add 192.168.80.0/24 to the Remote Networks on the Site-to-Site tunnel at the side with the 172.16.16.0/24 network so it knows how to route back to it.

Thanks, works!

There are no errors in that log, though. Maybe you cut the log off too early. Please post the logs from both sides around the time of a failed connection. Please post the logs as text, preferably, not an image, either in a code block inline in the post or attached as a text file.

On your outbound nat pick the interface for the network these servers are on, and nat traffic using pfsense interface IP.. Its just like any other outbound nat, but into your lan.. I have gone over source nat multiple times in other posts.. Find one of those.. edit:  here is a recent thread where showing doing a source nat https://forum.pfsense.org/index.php?topic=137152.0

Well, I ended up blowing away all the OpenVPN settings and rules I had created, then created a new site-to-site PKI OpenVPN connection, and then I created Client Specific Overrides (iroute x.x.x.x y.y.y.y) and voila! IT WORKED! THANKS so much for all your suggestions - much appreciated…

I'm facing a similar issue with 2.4.2, not exactly the same but I'm not sure it merits a new thread. I have my own PKI setup with root CA + intermediate CA, servers and clients are signed by the intermediate, crl is also setup. I have configured the OpenVPN server certificate depth to 2 accordingly. I'm running Netgate's pfSense in AWS, and after upgrading from 2.3.5 to 2.4.2, my previously fully functional OpenVPN clients cannot connect anymore, the clients are left hanging while trying to connect and I get the following errors in the server logs: OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed VERIFY SCRIPT ERROR: depth=2, C=<hidden>, ST=<hidden>, L=<hidden>, O=<hidden>, OU=<hidden>, CN= <hidden (root="" ca)="">WARNING: Failed running command (--tls-verify script): external program exited with error status: 1 VERIFY WARNING: depth=2, unable to get certificate CRL: C=<hidden>, ST=<hidden>, L=<hidden>, O=<hidden>, OU=<hidden>, CN= <hidden (root="" ca)="">VERIFY WARNING: depth=1, unable to get certificate CRL: C=<hidden>, ST=<hidden>, L=<hidden>, O=<hidden>, OU=<hidden>, CN=</hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden></hidden> The crl warnings trouble me already, since that didn't happen in 2.3.x and I had tested the crl revocation functionality. But the main issue seems to be the tls verify script error, somehow it is not able to verify the root CA. I have tried all permutations I could think of (adding the full chain root ca / intermediate ca in the crt files, singling them out, etc), but nothing works. The only thing I can do at this moment is to deactivate the depth check, then my clients connect again. I have also seen in other threads that it might be related to spaces in the X509 data, but I found nothing conclusive. Any help will be appreciated.

You may have to set the cameras to permit access the 10.8.0.0/24 subnet. When connected, your Android device will be appearing as a device on that network trying to get to your cameras. I don't know if your cameras automatically deny devices outside their base 192.168.1.0/24 subnet.

You guys are both fantastic. Thank you so much for helping to explain to me how all this works. This morning, I setup things as Derelict recommended: Server configuration: Tunnel Network: Something unused anywhere - probably a /24 Remote Networks: [none] Local Networks: [Insert Local Subnet/CIDR] Inter-Client Communication: Enabled. Topology: subnet Custom options: route 10.0.0.0 255.255.0.0; route 10.20.0.0 255.255.248.0; route 10.6.0.0 255.255.255.0; Client-specific Overrides: Site 1 Remote Network: 10.0.0.0/16 Site 1 Local Network/s: 10.20.0.0/21,10.6.0.0/24 Site 2 Remote Network: 10.20.0.0/21 Site 2 Local Network/s: 10.0.0.0/16,10.6.0.0/24 Site 3 Remote Network: 10.6.0.0/24 Site 3 Local Network/s: 10.0.0.0/16,10.20.0.0/21 I can now access all resources on the subnets mentioned thanks to your help. I shall buy another SG-3100 in your honor and definitely buy you a beer next time you're in my area P.S. We can mark thread as solved if that's a thing

Interesting post, thanks for providing an update on the MTU. I also agree with kejianshi. NCP is working well for my array of platforms. Nice to see pfSense providing backward compatibility whilst advancing rapidly.

I have also used Pfsense with a VPN configuration for several years now, even modified a script for it to work with PIA vpn service; up to this 2.4 branch  VPN has worked great. Initial intro of 2.4 slowed it down considerably; and this last patch has broken it to the extent now that every day since its been latest update has been applied i get back home to find the VPN tunnel down completely. This has NEVER happened before with any previous revisions even the initial slow performing 2.4.

how exactly did you create those certs?