OpenVPN client showing 100% packetloss following 2.5.0 upgrade
-
@vjizzle Just wanted to give an update. I got it working and I finally figured out what it was.
I'm using Torguard, and with the newest version of OpenVPN there were some settings that were added and/or removed since their last guide to setting up a client. The issues I was experiencing all fell on one setting that their guide says to leave unchecked - "Dont pull routes".
I never had this setting enabled on version 2.4.5. Plus some new settings that didnt get applied properly, so obviously it explains why everything went down after the upgrade.
With the "Don't pull routes" disabled, EVERYTHING was being routed via the VPN client, no matter what PBR I had in place. So if the client was configured wrong and not up, my entire network would go down as well. Once enabled, PBR would only route via the VPN client and everything else through the WAN.
What a fucking shit show the last week has been trying to figure this shit out. -
@hypnosis4u2nv my part is mainly on the fallback which was default to AES-256-GCM instead AES-128-GCM and gateway monitor. Once I set fallback to AES-128-GCM and gateway monitor either disable or enable. If you want to monitor it, as @vjizzle pointed out that use public domain. I recently just enable monitor and monitor my two vpn connection. I also checked "Don't pull routes" and "Don't add/remove routes" to avoid conflict with the two torguard vpn connection that i'm using. Otherwise, i will have situation where user A will have same public ip address of user B but both user are assign to different VPN connection.
-
@hypnosis4u2nv
Good to hear that you got it working :). Maybe I should have mentioned it but I always have the "Don't pull routes" option enabled (in version 2.4.5 and 2.5) because I use several VPN tunnels and rely on pbr to route the traffic where needed. -
@vjizzle Weird that it didn't cause me issues on 2.4.5, worked just fine with it unchecked. Question, do you also enable "Don't add/remove routes" on your configuration?
-
@nevar I knew about the gateway monitor IP to get it not showing a loss, which is why I initially responded to this problem. Thankfully, it also helped me start looking into what could be the cause of my unrelated routing issue. I didn't enable "Don't add/remove routes" but sounds like I should if I'm using more than one vpn client. I was considering adding another one and creating a gateway group for a fail safe if one gateway goes down, the other will continue to provide internet access.
-
@hypnosis4u2nv
Hi. I only have Don't pull routes enabled. -
@vjizzle I used that how-to as well. Worked out pretty good for me.
-
Ok, so my application is probably quite a bit different to what most of you are using OpenVPN client for - multiple pfsense clients doing peer to peer to a single pfsense server, carrying a guest network across many sites. But, perhaps my solution will also work for you....
system > routing > tunnel_gw > advanced > use non-local gateway
I already had non-negotiable AES-128-GCM for encryption.
This allows me to continue using gateway monitoring - I'm actually monitoring the far-end IP of the tunnel, ie the server tunnel address.
-
My solution is easy, don't specify a 'Monitor IP'.
- Disable Gateway Monitoring = unticked
- Disable Gateway Monitoring Action = unticked
- monitor IP = empty
What happens is that if not monitor IP is set pfSense uses the 'Virtual IP' presented by the OpenVPN client to PING and this only becomes available after the OpenVPN client has successfully connected.
I suspect that PINGs to the outside world are happening before the client/route is initialised or that the PING is not being routed and this is why if you use a real IP the monitoring is not working and because of this failure, pFsense flags the Gateway as offline.
My pf version: 2.6.0-RELEASE (amd64)
-
@shoulders said in OpenVPN client showing 100% packetloss following 2.5.0 upgrade:
What happens is that if not monitor IP is set pfSense uses the 'Virtual IP' presented by the OpenVPN client to PING and this only becomes available after the OpenVPN client has successfully connected.
Hmm...
You could just set the monitoring IP to 8.8.8.8 and call it a day, too. pfSense won't use an IP for monitoring that isn't specified, but if it is you should submit that as a bug to https://redmine.pfsense.org/ because that is not the intended situation. -
@rcoleman-netgate no external 'Monitor IP' address works on the OpenVPN gateways. I can ping from a client PC on the network to external address with no issue once the connection is up.
(System --> Routing --> Gateways)
The monitor address is populated with the 'Gateway/Virtual Address' for this OpenVPN connection so it looks good to me.