Had the same problem with mine before my box crashed (now can't get it back working). Change the first firewall rule from DEFAULT GATEWAY to the GW-WAN…......that will get ALL the traffic off the Tunnel, but the tunnel will stay up and working......then peck, peck your way through the other. Now as to the rest, if I can get mine back up and working I believe that we will have to set up some kind of routes for the VPN and burn a firewall rule in for EACH device you want out the tunnel (by IP, Name, etc) P.S. Backup you config.xml file with your working configuration BEFORE you start tweaking!!! That way if you break it all....you can restore the working configuration....trust me I know. Haven't worked on mine lately...too much Holiday.....

Don't know about you robina80, but if you can get the tunnel up and running OpenVPN to your provider, then every device connecting with your PFsense Box will go out through the tunnel, as I understand it the OpenVPN client is by default bound to the WAN….......... Basically the way mine worked...(before the GREAT CRASH....and Decent Recovery) is that ANY device present on my Network that went to the Internet thru my Box, Went thru the tunnel. In my case I need to get mine back up and configured to EXCLUDE every device except a select few from going out the tunnel.........If it wasn't for the other half's soap's on Hulu and CBS I'd LOVE for everything to go out the tunnel............Women!!!! I know that doesn't do you any good when away from home.... You can set up IPSec, L2TP and PPTP like divsys said....buuuuttt I don't think you can use them all at Once.

Well, considering that the link in that post goes to a dead Drupal site, I'd say that we're probably all better off. Getting something like this going is probably a better long-term solution anyway. https://github.com/evgeny-gridasov/openvpn-otp

Update … fixed, by altering the OpenVPN client config to fast-io; persist-key;replay-persist cur-replay-protection.cache; remote-random; pull; verb 5; key-direction 1;route-method exe; route-delay 2;tun-mtu 1500;fragment 1300;mssfix 1450; persist-tun;keepalive 10 120; keepalive 10 120 was the actual differentiator that made it work.

But if I disable the override my client gets an ipv6 address and everything is golden but I would like to choose the ip of my clients.

If you are running Android 4.4.x you will encounter a bug related to the tun0 interface. After setting up the OpenVPN connection you are able to ping6 the Android 4.4.x device from your server, but you cannot ping6 the server or other IPv6 targets from your Android 4.4 device. This bug doesn't occur in Android 4.3 (And earlier?) and occurs in all Android 4.4.x versions including 4.4.2. There is no known workaround for this issue except hoping on a fix in Android 4.4.3. https://community.openvpn.net/openvpn/wiki/IPv6#Clientissues

You have got a new WAN gateway and pfSense will have reconfigured outbound NAT. Maybe this has messed up your outbound NAT settings for VPN connections.

I thought I'd best post an update: After turning off the gateway monitoring I monitored the VPN connectivity for around 48 hours, it dropped maybe 3 packets the whole time but the VPN stayed connected. Thanks.

Now moving on to the next challenge :) I thought I was in the clear as I can ping both ways and access standard items both ways so I am pretty confident that the setup so far is on the right track …but I think I am missing something. I need to connect to a specific port on the vpn network from the internal network. When I try it netstat on the client side is actually reporting it as established but no data will flow. When looking closely I can see that netstat reports the connection done between the client and the openVPN interface and not the source as I expected. See screenshot enclosed .. the source is 10.0.0.18 Is this the root of my problem and if so how do I make sure the communication flows back?  

Bump…

Hmm. No local DNS resolution, but no routes to the Internet either. Frustrating.

Their analysis was better than mine but reached the same conclusion. There's no way to exploit it via OpenVPN. It's still difficult to exploit even using other methods. http://it.slashdot.org/story/14/06/28/1949243/are-the-hard-to-exploit-bugs-in-lzo-compression-algorithm-just-hype

Apparently the lag was due to packet loss on the servers wan adapter. The stupid part is that server has 2 WAN's. DSL and cable. The OpenVPN server is setup to use the CLUSTER (combined) adapter. My client is setup to connect on either IP address. For some reason the load balancing wouldn't kill the cable connection with the heavy packet loss. Even though in the gateways have settings of 1 and 3 in the packet loss threshold with a down of 4. Any idea why the cable connection would not boot itself from the load balancing cluster? :/