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

"but if you turn on TLS Crypt (new in 2.4, doesn't exist on older versions), then the clients would also have to be 2.4." QFT! This drove me nuts for a bit trying to figure out why my phone could connect to the udp session but not the tcp session.. Seems I had manipulated the settings in the tcp settings and enabled tls-crypt.  While the udp did not have it on ;) The openvpn connect app on the iphone does not support tls-crypt as of yet.  Was like WTF.. My pc connects no issues, but why was the phone not working.. I normally have never had to make any adjustments to the openvpn clients as upgraded over the years.  Currently running 2.4 beta and could connect no problem.  But wanting to check out the settings that were new I did make some adjustments to my tcp settings.  PC clients all working just fine - had not connected from phone in a while using tcp.  But then wanted to connected from work on the wifi and there is proxy.  So you have to use tcp for that - had forgot about the tweaks I had made.  So it threw me for a loop for a bit. So I have highlighted jimp statement - as it could throw you for a loop if you do not pay attention ;)

OpenVPN does not currently perform RADIUS accounting.

Allowing users to download their own VPN installers is not currently possible and not something we are likely to implement until a secure method can be devised. Giving users access to the export package will let any user download an installer for any other user. It does not restrict them to their own installers. The main reason it's a bad idea is that it takes all your extra security/authentication factors (TLS key, certificates, etc) and makes them practically worthless. All someone would need to do is obtain a user's name/password and they could download their VPN installer. Even though we do protect against brute force attacks, that doesn't help if someone gets the user/pass directly by phishing, social engineering, and so on. Search around on the forum and reddit. I've ranted about it several times before.

Bump anyone???

I have looked into that before and it wasn't so easy to deal with. Granted that was a couple years ago, and it might have changed since then. The problem is that all of the other platforms only require us to create a standard style OpenVPN configuration but package it in slightly different ways or add/omit certain directives. Chrome OS requires you to make a specially-crafted file in a completely different format. I'm sure it could be done, but it would require a completely different style than anything else the package has already.

The NAT configuration on the R7000 side looks wrong. You probably do not want NAT there and you do want to define the networks if you expect to be able to directly-address the LAN on that side.