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

can OpenVPNServer and IPSEC be used on the same interface? That's what I'm trying to do on IF vmx0.500. I guess that could be the source of the problem

As far as I know one should use one line for every push option.
That would be:

push "dhcp-option first-domain.com" push "dhcp-option second-domain.com"

You can check if your method works correct in the client log, should look something like:

SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1) Fri Nov 24 13:58:10 2017 us=31484 PUSH: Received control message: 'PUSH_REPLY,..........,dhcp-option DOMAIN first-domain,dhcp-option DOMAIN second-domain,..........'

Post your NAT table and LAN firewall rules.  You probably have a setting wrong.