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.
    • 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
                                      • P
                                        paoloest
                                        last edited by

                                        0_1551863272364_Screenshot 2019-03-06 at 10.07.25.png

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

                                          That delay is abysmal.

                                          Now add the right axis, Traffic, WAN

                                          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

                                            0_1551863632836_Screenshot 2019-03-06 at 10.13.43.png

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