Packet loss with multiple VPN clients
-
2.4.5_p1 works perfect with my 4 client OpenVPN configuration. Using the exact same configuration on 2.5.1 or above generates massive packet loss on all VPN client gateways and failover stops working. Back to 2.4.5_p1 and all works perfect. Netgate tells me that this is not a bug. What else would it be? Just because I can't pinpoint the exact problem and provide a suggested fix my issue is dismissed. I'm not the professional coder here. I'm not sure if it's a dpinger or OpenVPN issue. No sense in explaining it in detail again as I have done so in multiple posts.. This forum has been zero help on this. Even a comment "It works for me" would be helpful at this point. It's the blind leading the blind here. I had full intentions of becoming a PfSense+ subscriber as soon as it became available but now I am unsure.
-
@townsenk64 said in Packet loss with multiple VPN clients:
This forum has been zero help on this. Even a comment "It works for me"
Hi,
that I may "live" by your words "It works for me"
Right now with only 2 VPNs, because of the Mullvad and Nord for other reasons now I don't have it installed
so we will still just need your more detailed description.....
Well:
-
Hi! I went back to 2.4.5 p1 although when I was running 2.5.0 I had 5 or more openvpn client tunnels running without packetloss. Went back to 2.4.5 p1 for other things but packetloss on openvpn was not one of them.
I suggest wait for 2.5.2 unless there is really a specific feature you need from 2.5.x ( I cannot think of one…). Stay clear from 2.5.x for now, only troubles there.
-
This is using 2.5.2 beta but the results are the same with 2.5.1 through 2.6.0. The connections constantly struggle. one or two may eventually get down to 0% loss and appear to function properly. if any of the four connections reaches 100% loss they never attempt to connect again even though the four gateways are grouped in the same tier. The very same configuration works flawlessly with 2.5.0 and earlier.
-
Okay,
My first step would be to talk to TorGuard support about this, what's the situation on the server side...?
There were also significant changes in the pfSense version change at OVPN
- just to highlight a few:
(I have also had to fine tune, in several clients)
- NCP
- compression behavior
- OVPN v.2.5.0 (this is the biggest)
after quick read of the TorGuard instructions...
You use the same provider for German, Irish, English and Swedish directions (on port 1912), is this correct?
Start heavy loading the VPN tunnels separately per direction and observe a hardware behavior
say: ps uxawww
- just to highlight a few:
-
@daddygo said in Packet loss with multiple VPN clients:
ps uxawww
Thank you for your suggestions Now I am wondering if this is actually an OpenVPN issue or if it's an issue with my OpenVPN Gateways.
The part that confuses me is that the actual vpn tunnels connect and stay connected throughout. The packet loss appears to be in the gateway monitoring portion. I've selected my monitor gateways as the actual vpn endpoint IP's or as close to the endpoint as possible that still returned an icmp ping. My first response was to simply use a public dns server as the monitor gateway such as 8.8.8.8 or 1.1.1.1. I. Doing this I get the exact same results. Is this a Dpinger issue? I've reconfigured the advance gateway setting and changed latency, probe, & packet thresholds without any noticeable difference. I don't know the internal difference between a WAN/upstream gateway and ones generated by Openvpn but I've never had any issues on WAN.
-
@townsenk64 said in Packet loss with multiple VPN clients:
monitor gateway such as 8.8.8.8 or 1.1.1.1.
These give exactly the results that the DNS server load gives, not so relevant, DNS servers are not designed to respond to ICMP, but I know this is often the only solution.
(this is not the main objective with them = ICMP respons)f.e.: Neither SurfShark nor ExpressVPN gateway not respond to ICMP. (security question)
Tracert...... and it will tell you what is the nearest upstream GW in your VPN tunnel that responds to ICMP
I wouldn't think it's a "dpinger" issue, because it works for me and others.
What I would do next:
-
First check the parameters of the WAN-only with ISP connection (pls. heavy load the link, for example with this: https://speed.cloudflare.com/ or https://www.nperf.com/en/)
-
I would take down all the VPN tunnels and bring them up one by one
-
In the meantime, I would monitor the hardware CPU load, as OpenVPN is a single-threaded beast
-
Step by step I would launch VPN tunnels, after you should see if doing so increases packet loss and CPU load
BTW:
What type of ISP connection do you have? (PPPOE, GPON, ADSL, etc)
-
