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? :/

@jimp: Any CARP VIPs? IP aliases on CARP VIPs? hi Jimp, i think is something with the installed certificate or with previous installation of Pfsense. i tried the same profile on a different computer a never installed Openvpn and it works. is there is away to clean all installed certificate of Pfsense ? and all other trach ? i fixed the problem, for people with the same problem, go to cert manager on your windows and delete the openvpn certificate, remove openvpn and install it again

Sorry, solved. Enter any additional options you would like to add for this client specific override, separated by a semicolon EXAMPLE: push "route 10.0.0.0 255.255.255.0";

Ok will do. thanks for that.