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

    WAN Connectivity Issues after upgrade to CE 2.7.2

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 3 Posters 498 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.
    • X
      xSirrus
      last edited by

      Ever since upgrading to pfSense 2.7.2 CE from 2.6.0 CE, the WAN interface will lose connectivity until pfSense is rebooted. My fiber modem never goes offline and there have been no outages with my ISP. No hardware changes have taken place with the firewall. It is not virtualized.

      Looking at the logs, I saw this before I rebooted the firewall:

      Feb 22 08:01:31 	rc.gateway_alarm 	54098 	>>> Gateway alarm: WAN_DHCP (Addr:x.x.x.x Alarm:1 RTT:1.046ms RTTsd:.259ms Loss:21%)
Feb 22 08:01:31 	check_reload_status 	438 	updating dyndns WAN_DHCP
Feb 22 08:01:31 	check_reload_status 	438 	Restarting IPsec tunnels
Feb 22 08:01:31 	check_reload_status 	438 	Restarting OpenVPN tunnels/interfaces
Feb 22 08:01:31 	check_reload_status 	438 	Reloading filter
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: Gateway, NONE AVAILABLE
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use WAN_DHCP.
Feb 22 08:01:32 	php-fpm 	26777 	/rc.filter_configure_sync: GW States: One or more gateways is down, flushing all states: WAN_DHCP

      I have adjusted the WAN monitoring setting in System / Advanced / Miscellaneous > State Killing on Gateway Failure to Do not kill states on gateway failure to see if this helps based on other forum posts.

      If anyone has any insights on why this his happening or is a known bug with 2.7.2, would appreciate a reply. Thank you.

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

        Is there anything logged before that?

        By the time you see a gateway alarm like that whatever is causing it has already happened.

        X 1 Reply Last reply Reply Quote 0
        • X
          xSirrus @stephenw10
          last edited by xSirrus

          Hi @stephenw10

          Here are the preceding logs back to the beginning of the day (user info, IPs removed of course):

          Feb 22 00:02:00 	sshguard 	15307 	Now monitoring attacks.
Feb 22 00:26:00 	sshguard 	15307 	Exiting on signal.
Feb 22 00:26:00 	sshguard 	44924 	Now monitoring attacks.
Feb 22 00:41:00 	sshguard 	44924 	Exiting on signal.
Feb 22 00:41:00 	sshguard 	90497 	Now monitoring attacks.
Feb 22 00:50:00 	sshguard 	90497 	Exiting on signal.
Feb 22 00:50:00 	sshguard 	57798 	Now monitoring attacks.
Feb 22 01:00:00 	php 	72115 	[pfBlockerNG] Starting cron process.
Feb 22 01:00:01 	php 	72115 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 01:14:00 	sshguard 	57798 	Exiting on signal.
Feb 22 01:14:00 	sshguard 	22700 	Now monitoring attacks.
Feb 22 01:38:00 	sshguard 	22700 	Exiting on signal.
Feb 22 01:38:00 	sshguard 	55230 	Now monitoring attacks.
Feb 22 02:00:00 	php 	53511 	[pfBlockerNG] Starting cron process.
Feb 22 02:00:01 	php 	53511 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 02:02:00 	sshguard 	55230 	Exiting on signal.
Feb 22 02:02:00 	sshguard 	68346 	Now monitoring attacks.
Feb 22 02:26:00 	sshguard 	68346 	Exiting on signal.
Feb 22 02:26:00 	sshguard 	67920 	Now monitoring attacks.
Feb 22 02:50:00 	sshguard 	67920 	Exiting on signal.
Feb 22 02:50:00 	sshguard 	63955 	Now monitoring attacks.
Feb 22 03:00:00 	php 	40340 	[pfBlockerNG] Starting cron process.
Feb 22 03:00:01 	php 	40340 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 03:01:00 	php-cgi 	72473 	rc.periodic: New alert found: The following CA/Certificate entries are expiring:
Feb 22 03:01:00 	php-cgi 	72473 	Certificate: webConfigurator default () (): Expired 448 days ago 
Feb 22 03:14:00 	sshguard 	62694 	Now monitoring attacks.
Feb 22 03:30:42 	php-fpm 	26836 	/widgets/widgets/gateways.widget.php: Session timed out for user '' from: 192.168.x.x (Local Database)
Feb 22 03:48:00 	sshguard 	62694 	Exiting on signal.
Feb 22 03:48:00 	sshguard 	23085 	Now monitoring attacks.
Feb 22 04:00:00 	php 	57983 	[pfBlockerNG] Starting cron process.
Feb 22 04:00:01 	php 	57983 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 05:00:00 	php 	53199 	[pfBlockerNG] Starting cron process.
Feb 22 05:00:01 	php 	53199 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 06:00:00 	php 	17148 	[pfBlockerNG] Starting cron process.
Feb 22 06:00:01 	php 	17148 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 06:46:00 	sshguard 	23085 	Exiting on signal.
Feb 22 06:46:00 	sshguard 	81600 	Now monitoring attacks.
Feb 22 07:00:00 	php 	4482 	[pfBlockerNG] Starting cron process.
Feb 22 07:00:01 	php 	4482 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
Feb 22 08:00:00 	php 	89712 	[pfBlockerNG] Starting cron process.
Feb 22 08:00:01 	php 	89712 	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload 
Feb 22 08:01:31 	rc.gateway_alarm 	54098 	>>> Gateway alarm: WAN_DHCP (Addr:x.x.x.x Alarm:1 RTT:1.046ms RTTsd:.259ms Loss:21%)
Feb 22 08:01:31 	check_reload_status 	438 	updating dyndns WAN_DHCP
Feb 22 08:01:31 	check_reload_status 	438 	Restarting IPsec tunnels
Feb 22 08:01:31 	check_reload_status 	438 	Restarting OpenVPN tunnels/interfaces
Feb 22 08:01:31 	check_reload_status 	438 	Reloading filter
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: Gateway, NONE AVAILABLE
Feb 22 08:01:32 	php-fpm 	70525 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use WAN_DHCP.
Feb 22 08:01:32 	php-fpm 	26777 	/rc.filter_configure_sync: GW States: One or more gateways is down, flushing all states: WAN_DHCP

          Rebooted Here.

          After doing some more reading, I came up with that it might be pfBlockerNG under Firewall / pfBlockerNG / IP > Kill States which is currently enabled or possibly setting System / Routing / Gateways / WAN / Edit and turn on Disable Gateway Monitoring, or set a more reliable Monitor IP such as 1.1.1.1.

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

            Mmm, nothing much there. pfBlocker didn't do anything at that point because there were no changes.

            But setting an external ping target for monitoring is a good idea anyway.

            X 1 Reply Last reply Reply Quote 0
            • X
              xSirrus @stephenw10
              last edited by

              @stephenw10 said in WAN Connectivity Issues after upgrade to CE 2.7.2:

              Mmm, nothing much there. pfBlocker didn't do anything at that point because there were no changes.

              But setting an external ping target for monitoring is a good idea anyway.

              Thanks for the reply. Any thoughts on turning on Disable Gateway Monitoring or would you suggest targeting a stable monitoring IP first and then moving on to Disable Gateway Monitoring if it persists?

              For additional context, this is a simple home setup, single ISP, and not something that requires intensive WAN monitoring and state killing to switch to a backup connection.

              pfBlocker seemed an unlikely candidate to me as it wouldn't cause 21% packet loss 1.5 min later, it'd cause 100% if something got blocked.

              Final question is if anything was changed between CE 2.6.0 and 2.7.2 with regards to the System / Routing / WAN settings that introduced more aggressive interface monitoring?

              Thanks again in advance for any further insights.

              S 1 Reply Last reply Reply Quote 0
              • S
                SteveITS Galactic Empire @xSirrus
                last edited by

                @xSirrus FreeBSD version therefore maybe drivers. What NIC hardware is WAN?

                Did you try a different patch cable?

                Turning off monitoring will leave it up with the observed packet loss. Doesn’t fix the packet loss of course.

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote 👍 helpful posts!

                X 1 Reply Last reply Reply Quote 0
                • X
                  xSirrus @SteveITS
                  last edited by

                  @SteveITS said in WAN Connectivity Issues after upgrade to CE 2.7.2:

                  @xSirrus FreeBSD version therefore maybe drivers. What NIC hardware is WAN?

                  Did you try a different patch cable?

                  Turning off monitoring will leave it up with the observed packet loss. Doesn’t fix the packet loss of course.

                  Hi @SteveITS

                  It is connected to the onboard NIC which is either an Intel i210 or i211. LAN connectivity is via a 4 port Dell branded Intel i350 based NIC. In either case, both are supported in FreeBSD 14. Since the packet loss is not consistent and rebooting the firewall corrects the issue every time, cabling would appear to be a less likely source of the issue. Thanks for suggesting it as a point of investigation regardless.

                  Yes, I realize turning of monitoring would indeed not solve packet loss, especially if it the result of a faulty cable, faulty modem from the ISP causing the packet loss, or somewhere further upstream on the ISP side. The issue as it stands is that when the packet loss occurs, even if it's 21% loss as shown in the log, with the settings the way they are/were, the states get killed and the WAN connection never recovers until pfSense is rebooted.

                  The timing is also suspect in that I had no stability issues on 2.6.0 and start encountering issues right after upgrading to 2.7.2.

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

                    Yeah if you only one WAN I would disable the monitoring action but leave monitoring enabled. It's useful to have a record of the WAN status for troubleshooting issues.

                    X 1 Reply Last reply Reply Quote 0
                    • X
                      xSirrus @stephenw10
                      last edited by

                      @stephenw10

                      Thanks for the replies and insights. So far it's been over 24 hours with no issues. I'll report back after a longer period of time if issue re-occurs with details.

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