VPN tunnels massively slows down if high network traffic
-
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?
-
Yes, set the tier and trigger level.
-
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
-
@derelict
you are right. as i am on vacation and hve closely monitored it yesterday the assumption is, that it is not caused by high trafficunfortunately it happens now every 5 minutes if my wife and me are working
-
Pretty much nothing on pfSense can make an echo reply take a second to get back to you.
-
If you have gateway monitoring on WAN (the default setting), the system is automatically keeping track of two pings per second in Status > Monitoring.
From there select settings, change the left axis to Quality / WANGW (or the local equivalent).A good place to start with Options: 8 hours, Resolution: 1 minute.
Another place to check is in Status > System Logs, Gateways. Any events there with "Alarm" in them are times when the ping monitor had excessive loss or latency.
A failure will look something like this: Jan 7 15:05:31 dpinger WANGW 8.8.8.8: Alarm latency 0us stddev 0us loss 100%
Lines like this are just the dpinger process starting or reloading and are normal:
dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 198.51.0.16 identifier "DSLGW "Sometimes it is beneficial to change your monitoring address to something further out. In that example you can see that I am monitoring a google DNS server there. In general, monitoring the ISP gateway is fine if it reliably responds to pings. Changes to the monitor IP address can be made in System > Routing and editing the appropriate gateway.
-
thanks a lot.
I am pinging outside dns server. the monitoring itself works. With the latency issues comes the issue, that the internet can hardly be used (or even worse)
-
Right. Look at the historical quality graph.
-
-
That delay is abysmal.
Now add the right axis, Traffic, WAN
-
-
OK so there is no traffic reason for the delay.
At first glance I'd say your ISP/Your ISP circuit is having serious problems.
-
depending on the current situation, that i have massive problems at the moment I would assume that as an option as well ...
just wanted to make sure that there is no config error
-
There is nothing in pfSense that can send an echo request out WAN and delay the echo reply 1200ms before it arrives on WAN.
-
I have found out what the issue is. The cheap f*** internet gateway router detects a sync flood and slows down the interface ...
So I will get a fritzbox as a Modem instead of this thing.
as a workaround I have disabled all VPN Clients and only use the wan gw. hopefully it will not get to much on my nerves until this evening
-
Nice, that will do it!
You can't disable that? Or tune it? I assume you mean 'SYN flood' which this is not. Something that is a modem only is a better option though I agree.
Steve
-
Auto correct did the syn“c“ ;)
This isp Router cannot tweak anything ...
Unfortunately today there are no good modems (stand alone) are available. So another Router where no router is really needed
-
@paoloest said in VPN tunnels massively slows down if high network traffic:
Unfortunately today there are no good modems (stand alone) are available. So another Router where no router is really needed
Sure there are, for (V)DSL you can use the Draytek Vigor 165 for example. For cable it depends on your provider.
-
@grimson said in VPN tunnels massively slows down if high network traffic:
Draytek Vigor 165
thanks a lot. have seen this, but it costs more then the fritzbox 7530 - the pros of the fritzbox for me were that the modem (with the same specs) is build in and I can have one more security layer. (and with the fritzbox I can fine tune the parameters)
would you choose the modem over the router?
-
@paoloest said in VPN tunnels massively slows down if high network traffic:
would you choose the modem over the router?
When using pfSense, always. Double-NAT just adds useless complexity and the pfSense devs are a lot faster in fixing security issues than the AVM devs.
-
And beyond the pfsense there is a Sophos utm for one subnet and an xg for Another.
So maybe no bad idea to leave one layer of complexity ;)
-
You guys actually have VDSL2+? No jealousy here!
Otherwise the V130 would likely be cheaper.
Steve
-
@stephenw10
Sounds like another +1 for the vigorVdsl2+ - 3 weeks to go
-
@stephenw10 said in VPN tunnels massively slows down if high network traffic:
You guys actually have VDSL2+? No jealousy here!
Not to bad for a little village in the hills. Real fiber would be nicer, but that's not going to happen anytime soon here.
Edit: this is with a current link uptime of 6 weeks.
-
Nice!