VPN tunnels massively slows down if high network traffic
-
Hey guys,
unfortunately I have some problems with using vpn. In my config I route all network traffic through vpn except amazon prime and Netflix.since a few weeks I have massive latency drops in the vpn connection (see picture). If that happens I have to switch all network traffic back to wan interface and it works again - also the tunnel latency gets back to normal.
If you have any ideas to help me I would very much appreciate it
Thanks a lot!!!VPN provider: Nordvpn - OpenVPN config (https://support.nordvpn.com/Connectivity/Router/1089079142/pfSense-2-4-3-setup.htm)
Hardware: mini pc: Intel atom e3845, 8 gb ram, 64 gb ssd
-
Hi,
Keep in mind that the loss concerns ICMP requests. These are dropped if the queue is 'loaded'.
Also : your are using shared resources at the NordVPN side. They could have "busy hours" as any other service.
Btw : I would use another IP as the WAN Gateway 192.168.4.1. It's to close. Your WAN could be down and the (local ?!) 192.168.4.1 is still up.
-
thanks for the quick reply!
I have checked the resources at nordvpn via my iOS app and if I connect directly the performance is very good. In the past I have not had this issues ...
with the ip is a bit complex. I have my internet gateway router from my local isp th connect to the internet with this subnet, so the PFSense is member of it
-
@paoloest said in VPN tunnels massively slows down if high network traffic:
I have checked the resources at nordvpn via my iOS app and if I connect directly the performance is very good
Maybe.
iOS using wifi and you LAN, or "over the air" - so totally different entry point as your ISP.
You can not check Nordnet VPN resources. They will never tell you if they optimized their infrastructure, you know, like "a little bit more clienst per server means extra $$ for them".
As every service supplier, they fill up a server before deploying other servers.
Did you test other VPN IP's ?@gertjan said in VPN tunnels massively slows down if high network traffic:
Btw : I would use another IP as the WAN Gateway
Traceroute to ... well.... Google for example.
Take the IP that follows your 192.168.4.1 - check if it replies to ping and if so : put it here :
-
I'd also be tempted to add additional Nord connections and use them in a gateway group.
-
Nice idea. Thanks a lot. Never heard of this option. Is there also the possibility to switch connections in between a group in case of high latency?
-
-
Hey,
thanks again. I just set up another nordvpn gw. not sure about any config - maybe you could have a brief lookespecially in the OpenVPN Client config - should I use the gateway itself or the group?
In the firewall rule I set up the allow rule to the gw-group, right?
-
The second client should still be on the WAN.
Otherwise you are creating VPN though a VPN! That can never be good for throughput.
Steve
-
Totally right. Thanks, makes sense ;)
I will configure both through the wan interface -
that's pretty strange. At the same time all failover vpn connections went down nearly the same ...
maybe it has something to do with the pfblockerng cron?
-
Yes it could be general congestion on your WAN that you are not seeing because you're monitoring the local device.
Try changing the WAN monitoring target to something external, say 8.8.8.8. Then you will see any latency or loss on that link that the VPN has to travel over.
Steve
-
@stephenw10 said in VPN tunnels massively slows down if high network traffic:
Try changing the WAN monitoring target to something external, say 8.8.8.8. Then you will see any latency or loss on that link that the VPN has to travel over.
As proposed : https://forum.netgate.com/topic/141161/vpn-tunnels-massively-slows-down-if-high-network-traffic/4
Also, test your connection several times under several conditions with http://www.dslreports.com/speedtest - you find another rather technical bottleneck.
-
@stephenw10 said in VPN tunnels massively slows down if high network traffic:
Yes it could be general congestion on your WAN that you are not seeing because you're monitoring the local device.
Try changing the WAN monitoring target to something external, say 8.8.8.8. Then you will see any latency or loss on that link that the VPN has to travel over.
Steve
I’ve actually had issues using 8.8.8.8 in the past where it would generate false positives. I changed my monitors to my customer’s IP addresses instead (another pfSense installation) for better results.
-
@stephenw10 @Gertjan : Thanks a lot - now I have understood what is meant and why ;)
unfortunately I have no singable device in the internet - so I have chosen the two google and Cloudflare dns. any better options?
setting up a cloud host for ping reasons seems a bit oversized ;)
-
That should be fine for now. Are you seeing more realistic numbers for the WAN?
If so wait for a problem on the VPN and see if it's reflected in the WAN values.
Steve
-
Hey,
thanks a lot for your great help so far. Latency figures look way better.Unfortunately the issue is still there.
I see extremely high latency in every gateway, WAN as well as my VPN connections. If I restart the vpn tunnels it instantly comes back to normal values.and interface config looks like this: I block bogon in everey vpn and wan interface
maybe you can have a quick look into the log. I am a bit desperate:
Mar 6 09:09:20 check_reload_status Starting packages Mar 6 09:09:20 php-fpm 41651 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.3.6 -> 10.8.0.2 - Restarting packages. Mar 6 09:09:18 php-fpm 41651 /rc.newwanip: Creating rrd update script Mar 6 09:09:16 php-fpm 41651 /rc.newwanip: 41651MONITOR: NORDVPN_DE498_GW_VPNV4 is available now, adding to routing group Nordvpn 1.0.0.1|10.8.0.28|NORDVPN_DE498_GW_VPNV4|39.317ms|1.043ms|0.0%|none Mar 6 09:09:16 php-fpm 41651 /rc.newwanip: 41651MONITOR: NORDVPN_DE371_GW_VPNV4 is available now, adding to routing group Nordvpn 1.1.1.1|10.8.8.49|NORDVPN_DE371_GW_VPNV4|37.294ms|0.437ms|0.0%|none Mar 6 09:09:16 php-fpm 41651 /rc.newwanip: 41651MONITOR: NORDVPN_DE542_GW_VPNV4 is available now, adding to routing group Nordvpn 8.8.4.4|10.8.0.2|NORDVPN_DE542_GW_VPNV4|26.976ms|0.653ms|0.0%|none Mar 6 09:09:13 php-fpm 41651 /rc.newwanip: Removing static route for monitor 1.0.0.1 and adding a new route through 10.8.0.1 Mar 6 09:09:13 php-fpm 41651 /rc.newwanip: Removing static route for monitor 1.1.1.1 and adding a new route through 10.8.8.1 Mar 6 09:09:13 php-fpm 41651 /rc.newwanip: Removing static route for monitor 8.8.4.4 and adding a new route through 10.8.0.1 Mar 6 09:09:13 php-fpm 41651 /rc.newwanip: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.4.1 Mar 6 09:09:08 php-fpm 339 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use NORDVPN_DE542_GW_VPNV4. Mar 6 09:09:08 php-fpm 339 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGATEWAY' Mar 6 09:09:07 check_reload_status Reloading filter Mar 6 09:09:07 check_reload_status Restarting OpenVPN tunnels/interfaces Mar 6 09:09:07 check_reload_status Restarting ipsec tunnels Mar 6 09:09:07 check_reload_status updating dyndns NORDVPN_DE542_GW_VPNV4 Mar 6 09:09:07 rc.gateway_alarm 69427 >>> Gateway alarm: NORDVPN_DE542_GW_VPNV4 (Addr:8.8.4.4 Alarm:1 RTT:1117.120ms RTTsd:204.793ms Loss:21%) Mar 6 09:09:01 php-fpm 41651 /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.3.6. Mar 6 09:09:01 php-fpm 41651 /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.2) (interface: NORDVPN_DE542_GW[opt3]) (real interface: ovpnc2). Mar 6 09:09:01 php-fpm 41651 /rc.newwanip: rc.newwanip: Info: starting on ovpnc2. Mar 6 09:09:00 check_reload_status rc.newwanip starting ovpnc2 Mar 6 09:09:00 kernel ovpnc2: link state changed to UP Mar 6 09:08:58 check_reload_status Reloading filter Mar 6 09:08:58 php-fpm 20624 OpenVPN PID written: 81043 Mar 6 09:08:58 check_reload_status Reloading filter Mar 6 09:08:58 kernel ovpnc2: link state changed to DOWN Mar 6 09:08:57 php-fpm 20624 OpenVPN terminate old pid: 33138 Mar 6 09:08:27 php-fpm 339 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGATEWAY. Mar 6 09:08:27 php-fpm 73057 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use NORDVPN_DE542_GW_VPNV4. Mar 6 09:08:27 php-fpm 339 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGATEWAY' Mar 6 09:08:27 php-fpm 73057 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGATEWAY' Mar 6 09:08:26 rc.gateway_alarm 88448 >>> Gateway alarm: NORDVPN_DE498_GW_VPNV4 (Addr:1.0.0.1 Alarm:1 RTT:1031.119ms RTTsd:3.413ms Loss:0%) Mar 6 09:08:26 rc.gateway_alarm 89104 >>> Gateway alarm: NORDVPN_DE371_GW_VPNV4 (Addr:1.1.1.1 Alarm:1 RTT:1030.836ms RTTsd:.822ms Loss:0%) Mar 6 09:08:26 check_reload_status Reloading filter Mar 6 09:08:26 check_reload_status Restarting OpenVPN tunnels/interfaces Mar 6 09:08:26 check_reload_status Restarting ipsec tunnels Mar 6 09:08:26 check_reload_status updating dyndns NORDVPN_DE542_GW_VPNV4 Mar 6 09:08:26 rc.gateway_alarm 85882 >>> Gateway alarm: NORDVPN_DE542_GW_VPNV4 (Addr:8.8.4.4 Alarm:1 RTT:1034.794ms RTTsd:8.491ms Loss:0%) Mar 6 09:08:26 check_reload_status Reloading filter Mar 6 09:08:26 check_reload_status Restarting OpenVPN tunnels/interfaces Mar 6 09:08:26 check_reload_status Restarting ipsec tunnels Mar 6 09:08:26 check_reload_status updating dyndns WANGATEWAY Mar 6 09:08:26 rc.gateway_alarm 86020 >>> Gateway alarm: WANGATEWAY (Addr:8.8.8.8 Alarm:1 RTT:1021.963ms RTTsd:5.966ms Loss:0%) Mar 6 09:08:24 php-fpm 41651 /status_services.php: Removing static route for monitor 1.0.0.1 and adding a new route through 10.8.0.1 Mar 6 09:08:24 php-fpm 41651 /status_services.php: Removing static route for monitor 1.1.1.1 and adding a new route through 10.8.8.1 Mar 6 09:08:24 php-fpm 41651 /status_services.php: Removing static route for monitor 8.8.4.4 and adding a new route through 10.8.3.1 Mar 6 09:08:24 php-fpm 41651 /status_services.php: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.4.1 -
And if you look at Traffic > Monitoring on WAN at the time, how much data are you receiving/sending relative to your circuit capacity?
-
@derelict
there is not much traffic consumption going on. Some audio streaming, not more then 1Mbit ... -
So what's with this: VPN tunnels massively slows down if high network traffic
