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

    WAN connection randomly drops?

    General pfSense Questions
    6
    41
    8.8k
    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.
    • E
      ExecutableFix
      last edited by ExecutableFix

      It is most definitely something wrong with pfSense. The same thing is happening to a VM somewhere across the country.

      Here's the log of that VM:

      Feb 23 00:14:51 	php-fpm 	        60158 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
      Feb 23 00:14:51 	php-fpm 	        60158 	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
      Feb 23 00:14:51 	php-fpm 	        60158 	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
      Feb 23 00:14:50 	check_reload_status 		Reloading filter
      Feb 23 00:14:50 	check_reload_status 		Restarting OpenVPN tunnels/interfaces
      Feb 23 00:14:50 	check_reload_status 		Restarting ipsec tunnels
      Feb 23 00:14:50 	check_reload_status 		updating dyndns WAN_DHCP
      Feb 23 00:14:50 	rc.gateway_alarm 	96155 	>>> Gateway alarm: WAN_DHCP (Addr:145.44.x.1 Alarm:0 RTT:5.100ms RTTsd:3.103ms Loss:17%)
      Feb 23 00:11:48 	php-fpm 	        27479 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
      Feb 23 00:11:48 	php-fpm 	        27479 	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
      Feb 23 00:11:48 	php-fpm 	        27479 	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
      Feb 23 00:11:47 	check_reload_status 		Reloading filter
      Feb 23 00:11:47 	check_reload_status 		Restarting OpenVPN tunnels/interfaces
      Feb 23 00:11:47 	check_reload_status 		Restarting ipsec tunnels
      Feb 23 00:11:47 	check_reload_status 		updating dyndns WAN_DHCP
      Feb 23 00:11:47 	rc.gateway_alarm 	8754 	>>> Gateway alarm: WAN_DHCP (Addr:145.44.x.1 Alarm:1 RTT:5.367ms RTTsd:3.278ms Loss:21%) 
      
      

      And here's my log (after putting a switch between the bridged router and pfSense:

      Feb 25 03:46:01	check_reload_status		Reloading filter
      Feb 25 03:46:01	check_reload_status		Restarting OpenVPN tunnels/interfaces
      Feb 25 03:46:01	check_reload_status		Restarting ipsec tunnels
      Feb 25 03:46:01	check_reload_status		updating dyndns WAN_DHCP
      Feb 25 03:46:00	rc.gateway_alarm	43954	>>> Gateway alarm: WAN_DHCP (Addr:185.x.x.1 Alarm:0 RTT:1.397ms RTTsd:.280ms Loss:5%)
      Feb 25 03:43:59	php-fpm	                43417	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
      Feb 25 03:43:59	php-fpm	                43417	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
      Feb 25 03:43:58	check_reload_status		Reloading filter
      Feb 25 03:43:58	check_reload_status		Restarting OpenVPN tunnels/interfaces
      Feb 25 03:43:58	check_reload_status		Restarting ipsec tunnels
      Feb 25 03:43:58	check_reload_status		updating dyndns WAN_DHCP
      Feb 25 03:43:58	rc.gateway_alarm	71623	>>> Gateway alarm: WAN_DHCP (Addr:185.x.x.1 Alarm:1 RTT:1.477ms RTTsd:.290ms Loss:22%)
      

      The interval is different for both VMs tho and mine is settling at somewhere between 2 and 1.5 days. On the other VM there were 5 days in between. It's starting to look like some sort of DHCP lease setting is configured wrong? Maybe you can give some more insight @stephenw10 ?

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

        Neither of those logs indicate any issue other than there was more than 20% packet loss on the WAN to the IP being monitored. Everything else there is exactly what I would expect to happen when there is that much packet loss.

        Make sure you are monitoring an IP that actually responds to ping reliably. The ISP gateway may not always do that.

        If that's the only gateway you can disable 'gateway monitoring action' on it whilst still monitoring. That will avoid most of what you see in the logs there but it shouldn't be causing a problem.

        Make sure you have a default IPv4 gateway set in Sys > Routing > Gateways rather than automatic to avoid switching to a bad gateway.

        Steve

        E 1 Reply Last reply Reply Quote 0
        • E
          ExecutableFix @stephenw10
          last edited by

          @stephenw10 There's only one gateway configured in the routing section which is my ipv4 dhcp. I've already tried to set the monitoring ip to the google dns, but the same alarms still appear. At the time those alarms appear the internet is infact down. Is there a setting I'm overlooking here?

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

            No that's fine then. If the internet is actually down the alarms should trigger.

            What exactly is the problem here?

            E 1 Reply Last reply Reply Quote 0
            • E
              ExecutableFix @stephenw10
              last edited by

              @stephenw10 It's the fact that the internet is down every 1.5 day when that literally never happened before I switched to pfSense. It's nice that the pfSense alarms trigger, but that's not the problem. It seems like pfSense disconnects the internet every 1.5 day for no apparent reason. It looks like the same thing is happening to the random VM server which makes it seem like it's a pfsense bug or setting that's configured incorrectly.

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

                If you disable the gateway monitoring action it will not actually do anything other then set an alarm.

                Check the quality monitoring graphs in Status > Monitoring. Are you seeing packet loss consistently or just spikes before it goes down?
                How were you monitoring the connection be fore you had pfSense?

                Steve

                E 1 Reply Last reply Reply Quote 0
                • E
                  ExecutableFix @stephenw10
                  last edited by ExecutableFix

                  @stephenw10 This is the graph showing the packet loss at the moment it goes downf9a952f7aff57918b2f50fd3935cd9ab.png

                  There are no other spikes (traffic, packets etc) to be found. It's just plain packet loss at a random time. I wasn't really monitoring the connection before pfSense, but I never experienced internet outages this often. The only outages that happened were more like 1 hour+ long and those only happened rarely

                  1 Reply Last reply Reply Quote 0
                  • JKnottJ
                    JKnott @ExecutableFix
                    last edited by

                    @ExecutableFix said in WAN connection randomly drops?:

                    That shouldn't be the reason for a random drop.

                    Poor connections are often the cause of intermittent failure. I've seen those RJ45s fail many times.

                    PfSense running on Qotom mini PC
                    i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                    UniFi AC-Lite access point

                    I haven't lost my mind. It's around here...somewhere...

                    E 1 Reply Last reply Reply Quote 0
                    • E
                      ExecutableFix @JKnott
                      last edited by

                      @JKnott

                      @JKnott said in WAN connection randomly drops?:

                      @ExecutableFix said in WAN connection randomly drops?:

                      That shouldn't be the reason for a random drop.

                      Poor connections are often the cause of intermittent failure. I've seen those RJ45s fail many times.

                      This is different tho, plus there definitely wouldn't be a pattern

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

                        Ok, good news. The binary part of the fix for this is now in 2.4.5 snapshots:
                        https://github.com/pfsense/FreeBSD-src/commits/RELENG_2_4_5/sbin/dhclient/dhclient.c

                        The next available snapshot should have it. The full fix also requires changes to the dhclient script which can be applied via the system patches package. I have briefly tested that and it didn't seem to break anything.

                        That patch is here: https://redmine.pfsense.org/attachments/download/2682/pfsense-dhclient-script-patch.txt

                        If you're able to test it we may be able to include it in 2.4.5.

                        Steve

                        E 2 Replies Last reply Reply Quote 1
                        • E
                          ExecutableFix @stephenw10
                          last edited by

                          @stephenw10 Oh that's awesome news. I'll try to give it a shot tomorrow. Hopefully this is indeed the fix for the random drops

                          1 Reply Last reply Reply Quote 0
                          • E
                            ExecutableFix @stephenw10
                            last edited by

                            This post is deleted!
                            1 Reply Last reply Reply Quote 0
                            • E
                              ExecutableFix
                              last edited by

                              I've just installed 2.4.5_RC and applied the patch, let's see if this works

                              1 Reply Last reply Reply Quote 0
                              • E
                                ExecutableFix
                                last edited by

                                Update:

                                Feb 26 11:25:15	check_reload_status		Reloading filter
                                Feb 26 11:25:15	check_reload_status		Restarting OpenVPN tunnels/interfaces
                                Feb 26 11:25:15	check_reload_status		Restarting ipsec tunnels
                                Feb 26 11:25:15	check_reload_status		updating dyndns WAN_DHCP
                                Feb 26 11:25:15	rc.gateway_alarm	44749	>>> Gateway alarm: WAN_DHCP (Addr:185.47.x.1 Alarm:0 RTT:1.455ms RTTsd:.288ms Loss:5%)
                                Feb 26 11:23:19	check_reload_status		Reloading filter
                                Feb 26 11:23:19	check_reload_status		Restarting OpenVPN tunnels/interfaces
                                Feb 26 11:23:19	check_reload_status		Restarting ipsec tunnels
                                Feb 26 11:23:19	check_reload_status		updating dyndns WAN_DHCP
                                Feb 26 11:23:19	rc.gateway_alarm	87807	>>> Gateway alarm: WAN_DHCP (Addr:185.47.x.1 Alarm:1 RTT:1.437ms RTTsd:.274ms Loss:21%)
                                

                                I don't know what to do anymore. This happened after the patch had been applied. The loss is always about 20% and the interval matches again: 1.5~1.6 days. That can't be a coincidence anymore

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bcruze
                                  last edited by bcruze

                                  Under interface -wan -advanced there is a reject dhcp lease option

                                  Put the wan-dhcp ip there and apply to see if it helps

                                  This was the last thing I tried before getting a static ip from my provider which ultimately fixed my issue

                                  E 1 Reply Last reply Reply Quote 0
                                  • E
                                    ExecutableFix @bcruze
                                    last edited by

                                    @bcruze Could you provide a screenshot? I can see these settings:
                                    10b5d0fcb586771e99187c9b1187cfe3.png

                                    I also calculated the time between the downtimes and it's 1 days, 7 hours and about 40~50 minutes every time. It's definitely some sort of lease time issue

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      bcruze
                                      last edited by bcruze

                                      i worded it wrong apologies.

                                      reject leases from : is the area i ment to say.

                                      you can also try the FreeBSD default for a preset. i tried it but it did not fix my issue

                                      its kind of confusing, if you tweak it you have to select saved cfg to see what its actually set too. at first i didn't think it was saving my settings...

                                      E 1 Reply Last reply Reply Quote 0
                                      • E
                                        ExecutableFix @bcruze
                                        last edited by

                                        @bcruze So setting that option to the x.x.x.1 ip should reject new leases and thus not disconnect my internet. Was your issue exactly the same? Is it something that is caused by the way pfSense handles these things?

                                        1 Reply Last reply Reply Quote 0
                                        • B
                                          bcruze
                                          last edited by bcruze

                                          according to what i've read Pfsense should ignore the lease change. at least what i've read online.

                                          i changed ISP from charter spectrum to a carrier grade nat fiber to the home company. previously my IP never changed with spectrum so i never saw this issue. with CGNAT my Nokia modems internal ip changed roughly every 24-29 hours. my internet would go down and unplugging the cable from the nokia from pfsense and plugging it back it would fix it. OR if you went into status - interface > release wait a few seconds then renew. my connection would come back up.

                                          my work around is paying 10 dollars a month(static IP address) to my provider to stay online as they have no way of changing the programming of the Nokia modem. all the other modems they did not suggest. and i refuse to replace my Pfsense routers, ubnt POE switches and ubiquiti Nano, LR access points! to their equipment...

                                          E 1 Reply Last reply Reply Quote 0
                                          • E
                                            ExecutableFix @bcruze
                                            last edited by

                                            @bcruze I unfortunately don't have the option to get a static IP, but my IP has infact never changed before so I'm not too worried about that happening. The only thing I'm concerned about is the fact that the internet automatically comes back up again (which could indicate an issue with my isp rather then pfSense). I've not had to manually do anything for it to be online again. I'll definitely give this a shot and see of it resolves anything.

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