Well this was fixed in the latest OpenVPN connect client on iOS (1.2.7) so we can start our bad habits again

I have a simillar issue on an x86 which I have posted about in the forum before. For me the issue is only certificate depth checking… have this issue on 3 VMs. Anyone taking notice of this? Best regards, V

I fixed the issue. From memory I had to create a BRIDGE interface between my MGMT VLAN interface and OpenVPN TAP interface and remove the assigned IP from the MGMT VLAN interface and assign it to the BRIDGE interface. I now use a tun routed setup though.

Amazing what a little "light" reading can do for you, that and stepping away from it all when your eyes feel like they have sand in them. Opted to restore my pfsense install from a period before I started trying to hide my traffic. Worked great. Then I followed a more recent DIY to install openvpn and PIA, and what do you know, it freaking worked. I even went to a bunch of dns leak test sites, and voila, NO MORE DNS LEAKS! My traffic is protected from prying eyes, and my children can't see things that they won't forget by using pfblockerng However, this leaves me without the ability to remote into my pfsense box from work. Another project for another day!

Does this help ?  https://openmaniak.com/openvpn_static.php  

@viragomann: Of course, the packets should be routed to the vpn server. However, the traceroute shows the packets are directed to 192.168.8.254 from the source device, while according to the routing table above 192.168.8.250 is the pfSense LAN IP. ??? What's the real LAN IP now? sorry for the confusion, I did change the pfsense LAN IP to *.254 from *.250 since I finally managed to get it working (albeit a bit complicated) so I can finally shut down my openwrt router. I have several VLAN set up in the pfsense (management interface, trusted, guest, iot) and all pfsense LAN : my topology is something like this: WAN pfsense home (192.168.0.2) ==> connected to the ISP router few vlans in the 192.168.x.0/24 subnet (management, trusted, guest, iot) all client on the VLAN interface can browse the internet fine and all interface currently have any to any except for the IOT WAN pfsense office (pubic IP) and also has few VLANs, in the 10.0.x.0/24 subnet subnet for openvpn interface is in 10.0.102.0/24 I managed to get it work after I followed https://forum.pfsense.org/index.php?topic=29944.0 and modified according to my needs so only routes to VPN tunnel based on the destination IP/network and working good so far :) Not sure this is the correct way to do it but it's working. More configuration needed (usually only configure the client config file in the openvpn server), now I need to also configure few firewall rules for in the openvpn client end (in addition to configure the outbound NAT) The odd thing is, if I traceroute from office lan side to internal network it does pass thru openvpn lan interface and I dont need to configure anything on the firewall openvpn server side. C:\Users\thasan>tracert 192.168.5.201 Tracing route to 192.168.5.201 over a maximum of 30 hops   1    <1 ms    <1 ms    <1 ms  10.0.7.254   2    6 ms    6 ms    11 ms  10.0.102.3   3    12 ms    16 ms    10 ms  192.168.5.201 whereas if i traceroute from the other side it ommits the pfsense LAN IP and goes directly to the openvpn interface traceroute 10.0.7.10 traceroute to 10.0.7.10 (10.0.7.10), 30 hops max, 38 byte packets 1  10.0.102.1 (10.0.102.1)  7.177 ms  5.878 ms  6.333 ms 2  10.0.7.10 (10.0.7.10)  6.048 ms  *  6.322 ms I am happy now :), but just wondering is this the correct way to do it

Perfect  :) It is working everything now. THANK YOU. About the Thing with "Force all client-generated IPv4 traffic through the tunnel." Is also fixed, i've forgot to enter every Network on the other Side (those two Office LAN and CEO LAN). When I've done that, it was working without checked "Force all client-generated IPv4 traffic through the tunnel." Thank you. // COLSE

@Derelict: PIA could change that at any time. Exactly! So for now I'm using for gw monitoring one of Level 3 resolvers - 4.2.2.[1-6]

You can achieve this by setting up client specific overrides, one for each client. VPN > OpenVPN > Client Specific Overrides. It is required that each client has a separate, unique certificate. Klick Add to set up a new CCO, enter the common name as it is set in the clients cert, assign an unique /30 tunnel subnet to each client, at "IPv4 Local Network/s" enter all the remote subnets the client should be able to access and at "IPv4 Remote Network/s" the subnet behind the respective client. In the client config also enter all remote subnets, which should be accessible in the "IPv4 Remote Network/s" box.

I was experiencing similar log issues where the web UI showed "No logs to display" for OpenVPN. I was able to fix this by going to the Settings tab on the logs screen and clicking "Rest log files".

I also ran into this issue since my ISP started throttling / rate limiting my connection speed and I saturate the WAN link with VPN traffic.  Easy to reproduce using speedtest.net. This is typical behavior when an upstream service is throttling or rate limiting throughput, packets are delay (but not dropped) in order to choke back the downstream connection speed. The problem your experiencing is because Gateway monitor uses dpinger, which has a configured limit on how long it waits for responses before determining they are "lost".  What's important to note is the Loss % is not actual data loss, but "missed" ping responses, because they arrived too late to be counted. Key item that indicates this is RTTsd; RTT is of course the aggregate ping transit time, but the RTTsd is the Standard Deviation between each received ping response.  When the link is quiet the RTTsd will generally be fairly low, but when the RTTsd goes up it means that something up stream is intermittently delaying packets resulting in a larger deviation between each ping attempt. Thus if the pings are delayed beyond the configured wait time, they are considered "lost" even if they still arrive. I was able to get around this by going to System >> Routing >> Gateways and edit each gateway to increase the "Loss Interval" under the advanced section to increase the time that dpinger waits for responses before considering them "lost".  After that, my loss percentages dropped to near 0%, but then I started seeing the real latency of the delayed packets skyrocket, so had to tweak with the Latency threshold values as well to keep the gateway from dropping out from excessively high latency when it is saturated with traffic. You'll need to do some testing with traffic saturation on your VPN/WAN in order to come up with monitor values that do not cause the gateway monitor to considered the link offline.  I ended up having to configured some pretty high values on the upper latency threshold to keep the link from being knocked offline when running heavy traffic loads.

solved the common name of the client's certificate was not the same

Thanks, that's good to know. I will take a look at DNS options and investigate the Active Directory option.  (I recall reading some about Active Directory when resolving issues in setting up the OpenVPN.)