@jimp thanks for your reply. May the documentation need to be corrected in order to reflect this scenario?

Well, I'm sitting here having a nice tall glass of Noob Cola. Very refreshing! Yes, it was a firewall issue in the end and face-palm. I had to turn on the rule to allow File and Printer Sharing (Echo Request - ICMPv4-In) in Windows 10 and modify the scope. Thank you for the reminder for the "is it plugged in" rule.

FYI, it works. I had to change to the GW which is made "automatically" so I guess there is no need to manually create it for openvpn local routing? There was also an issue with older cname client names, which had to be addressed. Now back to the original task, connect openvpn to ipsec network :)

Ok, so I did a little more searching around and came upon this site: https://www.ceos3c.com/pfsense/pfsense-openvpn-linux-client/ I followed the steps from that page and low and behold, I was able to connect to my pfSense OpenVPN server with no issues even using my wireless hotspot. Success. Thanks for getting me headed in the right direction. I appreciate your time.

@viragomann said in Route local traffic using Interface IP instead CARP VIP: Add a static route for the OpenVPN tunnel network of the backup box pointing to the backups LAN IP to all your LAN devices which should be reachable over the VPN. Just wanted to let you know that I finally used your advice and created a static route. I now have two OpenVPN servers with distinct virtual IP subnets. The first server is used only on the main (master) box, and the second server on the backup box. Each LAN client has a static route to the backup box's lan ip for the second OpenVPN server's subnet. This works well. Thanks a lot !

System > Advanced > Miscellaneous > Skip rules when gateway is down was the money maker. Its working now. Thank you!

exactly - out of the box unbound does not allow vpn users to query it.. If you want your vpn users to be able to query unbound, you have to create a ACL to allow that. Per the example posted by @bingo600

Yeah the defaults for cert manager have been adjusted - because quite often these certs are installed on things you would be hitting with a browser. Say a web gui for pfsense ;) Or your web server your setting up, or some other gui for other software, or appliances like switches, etc. But when it comes to your openvpn - this is pretty isolated. The only thing using these certs are limited to the openvpn server/client. So the limitations for life of these certs would be controlled by the software and not the OS running the software.

I can't vouch that it wouldn't break anything but you could just edit the system_camanager.php page and comment out the validation check https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/system_camanager.php#L171 Then import it. I don't recall if it's checked before use in OpenVPN frontend or backend so there may be some other similar checks to edit. But the real fix is to use a proper cert. Just because OpenVPN/OpenSSL allows it today doesn't mean it always will.

Did you add Outbound NAT for your RAS tunnel net? -Rico

BAM! That was spot on. Thank you. [image: 1604856067383-e668a5b5-131f-457b-9a93-9a60aceda60f-image.png]

ok, I don't know why, but I am now able to get the IP address within Plex [image: 1604830926525-a32579eb-3c7a-4f75-ab21-be4c59d9d1ac-image.png] so I have check my Plex app on my Phone - All Good my when I check the WebApp on my LG TV = it is not finding the Plex.

@andrewglass3 Fixed - turned out to be a couple of issues, the openvpn package was borked. Tested with a static site to site instead, wouldnt connect. Full clean install and repeat the site2site with shared key and we are up and running! Link speed with i3 6100 pfsense box = 11MB/sec from ovh to home which is saturating the link. Previously on the edgerouter 4 which has no aes-ni or offload ability for openvpn I was lucky to maintain 1.5MB/sec. This is sooooooo much faster :) I really need to learn pfsense fully now :)

@FrankZappa UDP will work, as that's what OpenVPN normally uses. The issue, as you mention, may be the firewalls on the networks you try to connect from.

Hello, I found what was the problem. When we migrated to pfsense from checkpoint firewall, we imported an alias named "OpenVPN" which pointed to openvpn port number... This caused the "syntax error" on the rule because $OpenVPN was a port number and not the interface name of openvpn. But I guess wizard could tel us that OpenVPN variable is already used when validating installation but anyway :) Bye

not sure why but I disabled all the openvpn client interfaces / suricata interfaces / toggled the network adapter offloads / edited the firewall lan rules and then rebooted. added everything back in and rebooted. now everything seems to be coming up in the expected state.