So below is a screenshot for my DNS resolver with NordVPN. For the DNS in the general settings I have them exactly as the guide shows, first DNS is not set to any interface and the second is set to the VPN interface. I did try assigning the DNS resolver to both the WAN and the NordVPN interface but it did not help. Is there anything else I am missing? Patrick  

Are you talking about a user for an SSL/TLS Remote Access or a site-to-site PSK OpenVPN tunnel? If it's for a remote access SSL/TLS setup then their certificate must be signed by your CA, what you're having them do is not compatible with how OpenVPN needs to work. They can't make their own self-signed certificate that will work with the VPN. Unfortunately, until pfSense 2.4 you can't have them make a CSR that can be signed by the pfSense VPN CA in the GUI, though you could maybe copy the CA cert+key somewhere and manually do it with openssl at the command line and then send them back the signed certificate. If they do a CSR and send you the CSR, you never see their key. That's an area we're working to improve in 2.4.

I have already told you exactly what you need where. You do not need to push anything. You do not need iroutes. You just need to look at every site and put the networks you want to reach FROM THAT SITE ON THAT OPENVPN INSTANCE in IPv4 Remote Networks there. UDP is better for OpenVPN transport. You still have TCP on TCP connections inside the tunnel for guaranteed delivery where required. One writeup: http://sites.inka.de/bigred/devel/tcp-tcp.html

pfSense 2.3.x uses OpenVPN 2.3.x.  pfSense 2.4.x (still in Beta) uses the newest OpenVPN, 2.4.x, and I've found that key renegotiation is much faster and smoother in the 2.4 version of OpenVPN, so I can't wait until pfSense 2.4.0 is ready to ship. At any rate, my thread was mostly about the Client configuration, but some directives apply to Server configuration as well.  The most important directive to use is reneg-sec 0 to disable the timeout every 3600 seconds (1 hour).  I've since disabled the reneg-bytes 1073741824 directive since it got to be annoying, since it still takes about 1 minute to renegotiate. I'm not sure if remote-cert-tls server applies to a server configuration (in fact, it may not). tl;dr:  the most important directive to use is reneg-sec 0 to disable the key renegotiation timer. Re: your question about having to re-issue OpenVPN installers to all employees:  I doubt it.  It really depends on what you have in the employee configuration files.  reneg-sec 0 in the server config should disable it for the connection unless your client configs have some other number set in reneg-sec.

It will be harder to track exporting the CA certificate to all your clients as LE evolves and changes it. Trust me. It's a BAD idea to use that as a VPN server certificate.

@johnpoz: Why not just get your typical wifi router that supports 3rd party and put dd, openwrt on it and off you go? This is the other option I'm considering but it requires more config on my part.  I'm looking for these routers to be as plug and play as possible as I don't live near most of my family members.  I have a pfsense box with separate wifi setup at my parents as you eluded to but I did all the setup.  I'm trying to make these setups as user friendly as possible for non-technical users.  This way I can avoid as much troubleshooting of issues in the future.

Huh??  Have no idea what that question is suppose to be asking.. Why can some host you setup not access the internet?  Guess would be you set it up wrong ;)  Since it seems you clearly have internet access since your posting this ;)

One WAN IP is sufficient. OVPN-1 UDP or TCP listening on port 1194 OVPN-2 UDP or TCP listening on port 1294 So, only port needs to be different. Using one OVPN instance, I don`t know if is possible on pfSense.

It's fixed.. format the hard drive and reinstall from cd. set it up and it worked right away. Don't know why the factory reset didn't do the trick. Thanks for those who responded

Thank you for the advice.  I will attempt those suggestions.  I edited my original post to make things clearer and more descriptive for anyone else who may be able to render advice.

Hi, having NAT and port forwarding rules in port 443 there are problems with passing openvpn traffic on port 1194 with udp and tcp protocol. Since it is the second backup firewall, I solved this setting: Port-share x.x.x.x port (with port configured in openVPN also enabling udp traffic) Thanks for your reply! tripper

Similar setup well documented here https://forum.pfsense.org/index.php?topic=76015.0

You could start with the documentation https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

MTU size errors can also cause this. If your MTU is too large on the WAN side, the oversize packets get silently dropped, as OpenVPN is UDP. Try custom options mssfix 1424

You're correct that the tunneled server is not the default gateway – I do serve tunneled DNS via DHCP but I also have failovers, that way if the tunnel ever goes down users under the "client" pfSense box will still be able to access the internet, just not the LAN bridge. Thought it might be a NATting issue of some kind.  I did opt for box #2, as the ClearOS server is a VM in and of itself. I could go through the nightmare of connecting it via a vSwitch with specific routing instructions but since it's all internal and behind several firewalls on both ends of the tunnel anyway, I think it'll be fine. For the intended bridging purpose, it's not the end of the world that all tunneled requests will appear to come from the "server" pfSense VM. Thanks for the concise and helpful assist. Works perfectly now. +1 to viragomann

Excellent!  Glad it's working! Just a quick note, you can also enable the "route-nopull" directive from the GUI: [image: 0tKB21S.jpg] It obviously works either way but thought I would mention it.

Ok, problem solved. Client Gateway pointing to another firewall pfsense (I have two). thank you tripper

Your server is configured more like what we'd typically see in a remote access server vs. a site to site config.  This would be much more straight forward if PFsense was the server.  If you're planning on keeping DDWRT as the server, you may have to consult the OpenVPN forums for tuning your config.  I can't confirm whether those iptables statements are valid… especially that NAT statement. route 192.168.2.0 255.255.255.0 172.16.2.1 This is incorrect.  The server takes the first IP on the tunnel network, so you should be routing traffic destined for 192.168.2.0/24 to the virtual IP on the remote end of the tunnel network… most likely 172.16.2.2, but you'll need to verify that. On the client-side config, I don't know what that is, but I can say with absolute certainty that what you have displayed is NOT a client config from PFsense.  Please post the client1.conf from PFsense