FYI, it appears that NordVPN has addressed whatever issue was causing random ping timeouts after TLS renegotiation. I haven't seen it happen in the past two weeks, which is by far the longest stretch ever.

dpinger works fine. You are seeing an OpenVPN issue. You have to monitor something that will actually respond to pings. The gateway address is automatically inserted. There is no mechanism to "automatically" choose something else. You can place whatever monitor IP address in there you think is better than the gateway address. This has nothing to do with dpinger.

@HeMaN: I have some issues with openvpn clients on the firewall itself as well after upgrading to 2.4 The configuration I have is based on the 2.3 version of this guide (he has it now updated to 2.4): https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ I use two client connections to AirVPN combined in a Gatewaygroup, and it was wording fine on 2.3 In 2.4 I can see the connection with AirVPN is setup ok, but it seems the creation of the interface is giving issues: /sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up ifconfig: ioctl (SIOCAIFADDR): File exists "Solved" it for this moment by disabling one of the clients, then it seems to work agin for that one client. I found the solution for my problem :) In the 2.3 version of the guide I mentioned there was a monitor IP configured for each VPN GW. Comparing them with the 2.4 version of the guide he published now, there was no GW monitor IP. After removing them both stay active. It is either this or the fact I updated pfblockerng to the latest version because of the infamous 502 bad gateway issue, which I changed first before I changed the VPN GW configuration.

Thanks Room 7609! Tried it but alas same result :( Good idear though, I did say that mentioned a few times… Will keep you posted. CP

Thank you jimp and kpa for taking time to reply to my post. I think this script has to wait for the vpn to be up and running before it launches. Anyway I have found the solution to launching the script correct over at https://forum.pfsense.org/index.php?topic=71725.msg756541#msg756541

Glad it's working. There is another reason you have to have the rules not match the OpenVPN tab and only match the assigned interface tab. When they come in passed by the assigned interface rule, the resulting states get flagged with reply-to so the reply traffic gets sent out the interface on which it arrived - back out the OpenVPN tunnel in this case. If the traffic is passed by the OpenVPN interface group tab, there is no way for the system to know which interface it arrived on (it could be any interface in the group) so you don't get reply-to. The reply traffic will be sent according to the routing table which probably means it will be sent out WAN (and die there being out-of-state).

My RADIUS and AD is running from windows server 2008. There's no Google Authenticator package that can integrate with windows machine as far as i know. Thanks, I'll look into the freerad package for pfsense. If I do this, will I be able to configure freerad through commandline and use apt-get to install additional packages for the freerad?

Those are not placed by an OpenVPN server but by an OpenVPN client connecting to a server. Did you assign an interface? Add outbound NAT?

It was that damned CloudFlare rule. I re-ran the list of places that previously showed the VPN IP and they all reported the real WAN IP as expected. I really hope this consistently fixes it.  I'll update the thread if it doesn't fix it after I've pulled some hair out. (BTW, those Facebook IPs are straight from Facebook so only include their CIDR blocks and nobody else.  Back when that info was public.) Shows VPN IP TorGuard.net –> Shows real IP :) DuckDuckGo "What is my IP" --> Shows real IP :) whatismyipaddress.com --> Shows real IP :) BearsMyIP.com --> Shows real IP :) ipchicken.com --> Shows real IP :) ipaddress.pro --> Shows real IP :) Anecdotally, this also tells me just how many sites are CloudFlare customers (at least the free account).  Holy crap it's a lot.

What warning? The client is told what CA to use in the export file. It's not like an SSL connection to a web site. It is a VPN. If you could use a public CA for your OpenVPN server, then ANY certificate issued by that public CA would pass. And you wouldn't be in control of revocations, etc. Export the configuration for the client. That's how it works.

That is because you already have that route in the routing table from your other connection. #notabug Diagnostics > Routes

I was able to resolve the problem! There was some weirdness going on because I had set up the machine on an internal network. johnpoz was right, in that the problem was in the routing table of the internal machine. Once I fixed the internal machine to use the firewall as a gateway, I was able to VPN to it from the external machine.

You don't have to use the OpenVPN installer that comes from the export package if you don't trust it. You can instead download the installer directly from the OpenVPN site: https://openvpn.net/index.php/download/community-downloads.html