@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?

Did it work out for you with 2.3.4, or did you get another image to work?

Its late, so if I'm posting in error, forgive me. However, when VPNs are involved, its best to makes sure that the networks involved are different. Its also best if both are moved to private but not common numbers… Like 192.168.32.0/24 for the local network. Then 192.168.33.0/24 for the remote network. And move the VPN networks in pfsense to something sane but also unique and uncommon like 10.12.14.0/24 You really don't want your networks getting confused about where to send your packets. You never know what you might want to connect to this in the future, so why not make it idiot proof?

@viragomann: Maybe it's your ISP if he blocks the packets. Your server log shows a second server, listening to UDP 10445. Is it accessible? If it is the other server should be as well. yes on both sides are the openvpn opens to listen to each others. ISP is not blocking anything as it used to work untill the last update . its appear the firewall is blocking the traffic to leave and i beleive is a routing issue. just dont know where to start thank you