Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VPN tunnels massively slows down if high network traffic

    Scheduled Pinned Locked Moved General pfSense Questions
    44 Posts 7 Posters 7.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      paoloest
      last edited by

      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?

      NogBadTheBadN 1 Reply Last reply Reply Quote 0
      • NogBadTheBadN
        NogBadTheBad @paoloest
        last edited by

        @paoloest

        Yes, set the tier and trigger level.

        0_1551709484282_Screenshot 2019-03-04 at 14.22.30.png

        Andy

        1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

        1 Reply Last reply Reply Quote 0
        • P
          paoloest
          last edited by

          Hey,
          thanks again. I just set up another nordvpn gw. not sure about any config - maybe you could have a brief look

          especially 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?

          3_1551716874560_Screenshot 2019-03-04 at 17.21.47.png 2_1551716874559_Screenshot 2019-03-04 at 17.21.19.png 1_1551716874559_Screenshot 2019-03-04 at 17.21.07.png 0_1551716874559_Screenshot 2019-03-04 at 17.20.46.png

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • P
              paoloest
              last edited by

              Totally right. Thanks, makes sense ;)
              I will configure both through the wan interface

              1 Reply Last reply Reply Quote 0
              • P
                paoloest
                last edited by paoloest

                that's pretty strange. At the same time all failover vpn connections went down nearly the same ...

                0_1551773344122_IMG_0587.png

                maybe it has something to do with the pfblockerng cron?
                0_1551773764201_Screenshot 2019-03-05 at 09.15.24.png

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  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

                  GertjanG T P 3 Replies Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @stephenw10
                    last edited by

                    @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.

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 1
                    • T
                      tim.mcmanus @stephenw10
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • P
                        paoloest @stephenw10
                        last edited by

                        @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 ;)

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • P
                            paoloest
                            last edited by paoloest

                            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
                            1 Reply Last reply Reply Quote 0
                            • DerelictD
                              Derelict LAYER 8 Netgate
                              last edited by

                              And if you look at Traffic > Monitoring on WAN at the time, how much data are you receiving/sending relative to your circuit capacity?

                              Chattanooga, Tennessee, USA
                              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                              Do Not Chat For Help! NO_WAN_EGRESS(TM)

                              P 1 Reply Last reply Reply Quote 0
                              • P
                                paoloest @Derelict
                                last edited by

                                @derelict
                                there is not much traffic consumption going on. Some audio streaming, not more then 1Mbit ...

                                1 Reply Last reply Reply Quote 0
                                • DerelictD
                                  Derelict LAYER 8 Netgate
                                  last edited by

                                  So what's with this: VPN tunnels massively slows down if high network traffic

                                  Chattanooga, Tennessee, USA
                                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                  P 1 Reply Last reply Reply Quote 0
                                  • P
                                    paoloest @Derelict
                                    last edited by paoloest

                                    @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 traffic

                                    unfortunately it happens now every 5 minutes if my wife and me are working

                                    1 Reply Last reply Reply Quote 0
                                    • DerelictD
                                      Derelict LAYER 8 Netgate
                                      last edited by

                                      Pretty much nothing on pfSense can make an echo reply take a second to get back to you.

                                      Chattanooga, Tennessee, USA
                                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                      1 Reply Last reply Reply Quote 0
                                      • DerelictD
                                        Derelict LAYER 8 Netgate
                                        last edited by Derelict

                                        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.

                                        Chattanooga, Tennessee, USA
                                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          paoloest
                                          last edited by

                                          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)

                                          1 Reply Last reply Reply Quote 0
                                          • DerelictD
                                            Derelict LAYER 8 Netgate
                                            last edited by

                                            Right. Look at the historical quality graph.

                                            Chattanooga, Tennessee, USA
                                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.