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

    WAN link going down

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    62 Posts 9 Posters 15.4k 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

      Is that at any time or just at boot?

      1 Reply Last reply Reply Quote 0
      • T
        TieT
        last edited by

        @stephenw10:

        Is that at any time or just at boot?

        At the end of the boot cycle  :)
        I also see that WOL isn't working anymore.. strange

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          WOL is a known x86 issue with a patch on Redmine, completely unrelated.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            I also see that WOL isn't working anymore.. strange

            I guess you are using 32-bit pfSense 2.2 - that is effected by the gen_subnetv4_max issue, fixed by:
            https://github.com/pfsense/pfsense/commit/7094c303b7d46c9f7b24c3f1bd4432187832e85c

            Things that try to calculate the max IP address of a subnet are effected - WOL is one of them.

            You can apply that small fix and WOL should work again.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • T
              TieT
              last edited by

              @phil.davis:

              I also see that WOL isn't working anymore.. strange

              I guess you are using 32-bit pfSense 2.2 - that is effected by the gen_subnetv4_max issue, fixed by:
              https://github.com/pfsense/pfsense/commit/7094c303b7d46c9f7b24c3f1bd4432187832e85c

              Things that try to calculate the max IP address of a subnet are effected - WOL is one of them.

              You can apply that small fix and WOL should work again.

              Thank you !
              I was guessing in that direction, because when using WOL in the terminal it worked  :)

              1 Reply Last reply Reply Quote 0
              • T
                TieT
                last edited by

                Spoke too soon.

                The WAN link is still losing its connection.

                Feb 4 13:37:17 	kernel: arpresolve: can't allocate llinfo for 84.192.192.1 on sk0
Feb 4 13:37:17 	kernel: arpresolve: can't allocate llinfo for 84.192.192.1 on sk0
Feb 4 13:37:13 	kernel: arpresolve: can't allocate llinfo for 84.192.192.1 on sk0
Feb 4 13:37:06 	php-fpm[5814]: /rc.linkup: DEVD Ethernet detached event for wan
Feb 4 13:37:05 	kernel: sk0: link state changed to DOWN
Feb 4 13:37:05 	check_reload_status: Linkup starting sk0
Feb 4 13:36:10 	php-fpm[26356]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 4 13:36:08 	check_reload_status: Reloading filter
Feb 4 13:36:08 	php-fpm[26356]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.254) (interface: LAN[lan]) (real interface: sk1).
Feb 4 13:36:08 	php-fpm[26356]: /rc.newwanip: rc.newwanip: Info: starting on sk1.
Feb 4 13:36:07 	check_reload_status: rc.newwanip starting sk1
Feb 4 13:36:07 	php-fpm[26356]: /rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.1.254 )
Feb 4 13:36:06 	kernel: sk1: link state changed to UP
Feb 4 13:36:06 	check_reload_status: Linkup starting sk1
Feb 4 13:36:01 	php-fpm[26356]: /rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.1.254 )
Feb 4 13:36:00 	kernel: sk1: link state changed to DOWN

                Firewall Logs

                
block/1000000104
	Feb 4 13:40:18 	Direction=OUT lo0 	Default deny rule IPv4 (1000000104)		Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 74.125.24.139:80		Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 84.192.215.xxx:46001		TCP:FA
block/1000000104
	Feb 4 13:40:18 	Direction=OUT lo0 	Default deny rule IPv4 (1000000104)		Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 74.125.24.139:80		Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 84.192.215.xxx:46001		TCP:FA
block/1000000104
	Feb 4 13:40:17 	Direction=OUT lo0 	Default deny rule IPv4 (1000000104)		Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 74.125.24.139:80		Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 84.192.215.xxx:46001		TCP:FA
pass/1422181121
	Feb 4 13:24:22 	ovpns1 	USER_RULE OpenVPN OpenVPN Server wizard (1422181121)		Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 192.168.10.10		Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 192.168.1.120		ICMP
pass/1422181121
	Feb 4 13:24:11 	ovpns1 	USER_RULE OpenVPN OpenVPN Server wizard (1422181121)		Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 192.168.10.10:55720		Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 192.168.1.254:443		TCP:S
                1 Reply Last reply Reply Quote 0
                • T
                  TieT
                  last edited by

                  I don't know if there is a relation , but tonight i noticed something strange in the logs.

                  My WAN ip changed to a private range… (twice)
                  I'm also seeing openvpn and LCDProc errors...

                  wtf !

                  
Feb 11 01:10:30 fw1 snort[39066]: invalid appid in appStatRecord (186)
Feb 11 01:28:21 fw1 check_reload_status: updating dyndns WAN_DHCP
Feb 11 01:28:21 fw1 check_reload_status: Restarting ipsec tunnels
Feb 11 01:28:21 fw1 check_reload_status: Restarting OpenVPN tunnels/interfaces
Feb 11 01:28:21 fw1 check_reload_status: Reloading filter
Feb 11 01:28:22 fw1 php-fpm[89141]: /rc.dyndns.update: phpDynDNS (***-ip.biz): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Feb 11 01:28:22 fw1 php-fpm[76014]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Feb 11 01:28:22 fw1 php-fpm[76014]: /rc.openvpn: OpenVPN: Resync server1 OpenVPN Server
Feb 11 01:28:22 fw1 kernel: ovpns1: link state changed to DOWN
Feb 11 01:28:22 fw1 check_reload_status: Reloading filter
Feb 11 01:28:23 fw1 kernel: ovpns1: link state changed to UP
Feb 11 01:28:23 fw1 check_reload_status: rc.newwanip starting ovpns1
Feb 11 01:28:24 fw1 php-fpm[89141]: /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
Feb 11 01:28:24 fw1 php-fpm[89141]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.10.1) (interface: []) (real interface: ovpns1).
Feb 11 01:28:24 fw1 check_reload_status: Reloading filter
Feb 11 01:28:24 fw1 php-fpm[89141]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  192.168.10.1 - Restarting packages.
Feb 11 01:28:24 fw1 check_reload_status: Starting packages
Feb 11 01:28:24 fw1 php-fpm[76014]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 01:28:25 fw1 php-fpm[89141]: /rc.start_packages: Restarting/Starting all packages.
Feb 11 01:28:25 fw1 php-fpm[89141]: /rc.start_packages: Reloading Squid for configuration sync
Feb 11 01:28:26 fw1 check_reload_status: Syncing firewall
Feb 11 01:28:26 fw1 check_reload_status: Syncing firewall
Feb 11 01:28:27 fw1 php-fpm[79907]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 01:28:28 fw1 php: lcdproc: Start client procedure. Error counter: (0)
Feb 11 01:28:39 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 01:28:39 fw1 php: lcdproc: Start client procedure. Error counter: (1)
Feb 11 01:28:50 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 01:28:50 fw1 php: lcdproc: Start client procedure. Error counter: (2)
Feb 11 01:29:01 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 01:29:01 fw1 php: lcdproc: Start client procedure. Error counter: (3)
Feb 11 01:29:12 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 01:29:12 fw1 php: lcdproc: Too many errors, the client ends.
Feb 11 01:33:20 fw1 kernel: pid 71053 (ntpd), uid 0: exited on signal 11 (core dumped)
Feb 11 01:55:12 fw1 snort[39066]: invalid appid in appStatRecord (498)
Feb 11 02:00:31 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30622 milliseconds
Feb 11 02:00:31 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:01:17 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30630 milliseconds
Feb 11 02:01:17 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:02:03 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30797 milliseconds
Feb 11 02:02:03 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:02:49 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30628 milliseconds
Feb 11 02:02:49 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:03:04 fw1 php: snort_check_for_rule_updates.php: File 'snortrules-snapshot-2970.tar.gz.md5' download attempts: 4 ...
Feb 11 02:03:04 fw1 php: snort_check_for_rule_updates.php: [Snort] Snort VRT rules md5 download failed...
Feb 11 02:03:04 fw1 php: snort_check_for_rule_updates.php: [Snort] Server returned error code 0...
Feb 11 02:03:34 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30759 milliseconds
Feb 11 02:03:34 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:04:20 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30773 milliseconds
Feb 11 02:04:20 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:05:06 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30740 milliseconds
Feb 11 02:05:06 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:05:52 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30696 milliseconds
Feb 11 02:05:52 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:06:07 fw1 php: snort_check_for_rule_updates.php: File 'snort-openappid.tar.gz.md5' download attempts: 4 ...
Feb 11 02:06:07 fw1 php: snort_check_for_rule_updates.php: [Snort] Snort OpenAppID detectors md5 download failed...
Feb 11 02:06:07 fw1 php: snort_check_for_rule_updates.php: [Snort] Server returned error code 0...
Feb 11 02:06:37 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30597 milliseconds
Feb 11 02:06:37 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:07:23 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30771 milliseconds
Feb 11 02:07:23 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:08:09 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30889 milliseconds
Feb 11 02:08:09 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:08:54 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30633 milliseconds
Feb 11 02:08:54 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:09:09 fw1 php: snort_check_for_rule_updates.php: File 'community-rules.tar.gz.md5' download attempts: 4 ...
Feb 11 02:09:09 fw1 php: snort_check_for_rule_updates.php: [Snort] Snort GPLv2 Community Rules md5 download failed...
Feb 11 02:09:09 fw1 php: snort_check_for_rule_updates.php: [Snort] Server returned error code 0...
Feb 11 02:09:40 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30721 milliseconds
Feb 11 02:09:40 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:10:26 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30805 milliseconds
Feb 11 02:10:26 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:11:12 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30806 milliseconds
Feb 11 02:11:12 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:11:58 fw1 php: snort_check_for_rule_updates.php: [Snort] Rules download error: Resolving timed out after 30717 milliseconds
Feb 11 02:11:58 fw1 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds...
Feb 11 02:12:13 fw1 php: snort_check_for_rule_updates.php: File 'emerging.rules.tar.gz.md5' download attempts: 4 ...
Feb 11 02:12:13 fw1 php: snort_check_for_rule_updates.php: [Snort] Emerging Threats Open rules md5 download failed...
Feb 11 02:12:13 fw1 php: snort_check_for_rule_updates.php: [Snort] Server returned error code 0...
Feb 11 02:12:13 fw1 php: snort_check_for_rule_updates.php: [Snort] The Rules update has finished.
Feb 11 02:12:13 fw1 check_reload_status: Syncing firewall
Feb 11 02:12:14 fw1 kernel: pid 65763 (php), uid 0: exited on signal 11 (core dumped)
Feb 11 02:13:09 fw1 check_reload_status: rc.newwanip starting sk0
Feb 11 02:13:10 fw1 php-fpm[87333]: /rc.newwanip: rc.newwanip: Info: starting on sk0.
Feb 11 02:13:10 fw1 php-fpm[87333]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.100.10) (interface: WAN[wan]) (real interface: sk0).
Feb 11 02:13:10 fw1 php-fpm[87333]: /rc.newwanip: IP has changed, killing states on former IP 84.192.***.***.
Feb 11 02:13:11 fw1 php-fpm[87333]: /rc.newwanip: Could not find IPv6 gateway for interface (wan).
Feb 11 02:13:12 fw1 php-fpm[87333]: /rc.newwanip: ROUTING: setting default route to 192.168.100.1
Feb 11 02:13:12 fw1 php-fpm[87333]: /rc.newwanip: Removing static route for monitor 84.192.***.***and adding a new route through 192.168.100.1
Feb 11 02:13:32 fw1 check_reload_status: updating dyndns WAN_DHCP
Feb 11 02:13:32 fw1 check_reload_status: Restarting ipsec tunnels
Feb 11 02:13:32 fw1 check_reload_status: Restarting OpenVPN tunnels/interfaces
Feb 11 02:13:32 fw1 check_reload_status: Reloading filter
Feb 11 02:13:33 fw1 php-fpm[15216]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Feb 11 02:13:33 fw1 php-fpm[15216]: /rc.openvpn: OpenVPN: Resync server1 OpenVPN Server
Feb 11 02:13:33 fw1 kernel: ovpns1: link state changed to DOWN
Feb 11 02:13:33 fw1 check_reload_status: Reloading filter
Feb 11 02:13:34 fw1 kernel: ovpns1: link state changed to UP
Feb 11 02:13:34 fw1 check_reload_status: rc.newwanip starting ovpns1
Feb 11 02:13:35 fw1 php-fpm[15216]: /rc.filter_configure_sync: Could not find IPv6 

Feb 11 02:13:39 fw1 check_reload_status: Syncing firewall
Feb 11 02:13:39 fw1 php-fpm[19772]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.10.1) (interface: []) (real interface: ovpns1).
Feb 11 02:13:39 fw1 check_reload_status: Reloading filter
Feb 11 02:13:39 fw1 php-fpm[19772]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  192.168.10.1 - Restarting packages.
Feb 11 02:13:39 fw1 check_reload_status: Starting packages
Feb 11 02:13:39 fw1 check_reload_status: Syncing firewall
Feb 11 02:13:39 fw1 php-fpm[87333]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 84.192.***.***->  192.168.100.10 - Restarting packages.
Feb 11 02:13:40 fw1 php-fpm[70546]: /rc.start_packages: Restarting/Starting all packages.
Feb 11 02:13:40 fw1 php-fpm[70546]: /rc.start_packages: Reloading Squid for configuration sync
Feb 11 02:13:41 fw1 check_reload_status: Reloading filter
Feb 11 02:13:41 fw1 php: lcdproc: Start client procedure. Error counter: (0)
Feb 11 02:13:41 fw1 check_reload_status: Syncing firewall
Feb 11 02:13:42 fw1 php-fpm[19772]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:13:44 fw1 php-fpm[87333]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:13:44 fw1 php: lcdproc: Start client procedure. Error counter: (0)
Feb 11 02:13:55 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:13:55 fw1 php: lcdproc: Start client procedure. Error counter: (1)
Feb 11 02:14:06 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:14:06 fw1 php: lcdproc: Start client procedure. Error counter: (2)
Feb 11 02:14:11 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:14:12 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:14:13 fw1 check_reload_status: rc.newwanip starting sk0
Feb 11 02:14:14 fw1 php-fpm[80275]: /rc.newwanip: rc.newwanip: Info: starting on sk0.
Feb 11 02:14:14 fw1 php-fpm[80275]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.100.10) (interface: WAN[wan]) (real interface: sk0).
Feb 11 02:14:15 fw1 php-fpm[80275]: /rc.newwanip: Could not find IPv6 gateway for interface (wan).
Feb 11 02:14:16 fw1 php-fpm[80275]: /rc.newwanip: ROUTING: setting default route to 192.168.100.1
Feb 11 02:14:16 fw1 php-fpm[80275]: /rc.newwanip: Removing static route for monitor 84.192.***.*** and adding a new route through 192.168.100.1
Feb 11 02:14:17 fw1 php-fpm[80275]: /rc.newwanip: Dyndns debug information (tiet.no-ip.biz): Could not resolve checkip.dyndns.org to IP using interface IP 192.168.100.10.
Feb 11 02:14:17 fw1 php-fpm[80275]: /rc.newwanip: DynDNS (*****-ip.biz) There was an error trying to determine the public IP for interface - wan(sk0). Probably interface is not a WAN interface.
Feb 11 02:14:17 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:14:17 fw1 php: lcdproc: Start client procedure. Error counter: (3)
Feb 11 02:14:18 fw1 php-fpm[80275]: /rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Feb 11 02:14:18 fw1 kernel: ovpns1: link state changed to DOWN
Feb 11 02:14:18 fw1 check_reload_status: Reloading filter
Feb 11 02:14:18 fw1 check_reload_status: Reloading filter
Feb 11 02:14:18 fw1 php-fpm[80275]: /rc.newwanip: Creating rrd update script
Feb 11 02:14:18 fw1 kernel: ovpns1: link state changed to UP
Feb 11 02:14:18 fw1 check_reload_status: rc.newwanip starting ovpns1
Feb 11 02:14:20 fw1 php-fpm[35317]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:14:20 fw1 php-fpm[80275]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 192.168.100.10 ->  192.168.100.10 - Restarting packages.
Feb 11 02:14:20 fw1 check_reload_status: Starting packages
Feb 11 02:14:20 fw1 php-fpm[80275]: /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
Feb 11 02:14:20 fw1 php-fpm[80275]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.10.1) (interface: []) (real interface: ovpns1).
Feb 11 02:14:20 fw1 check_reload_status: Reloading filter
Feb 11 02:14:20 fw1 php-fpm[80275]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  192.168.10.1 - Restarting packages.
Feb 11 02:14:20 fw1 check_reload_status: Starting packages
Feb 11 02:14:22 fw1 php-fpm[80275]: /rc.start_packages: Restarting/Starting all packages.
Feb 11 02:14:22 fw1 php-fpm[35317]: /rc.start_packages: Skipping STARTing packages process because previous/another instance is already running
Feb 11 02:14:22 fw1 php-fpm[80275]: /rc.start_packages: Reloading Squid for configuration sync
Feb 11 02:14:23 fw1 php-fpm[67206]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:14:23 fw1 check_reload_status: Syncing firewall
Feb 11 02:14:23 fw1 check_reload_status: Syncing firewall
Feb 11 02:14:25 fw1 php: lcdproc: Start client procedure. Error counter: (0)
Feb 11 02:14:36 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:14:36 fw1 php: lcdproc: Start client procedure. Error counter: (1)
Feb 11 02:14:47 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:14:47 fw1 php: lcdproc: Start client procedure. Error counter: (2)
Feb 11 02:14:58 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:14:58 fw1 php: lcdproc: Start client procedure. Error counter: (3)
Feb 11 02:15:09 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:15:09 fw1 php: lcdproc: Too many errors, the client ends.
Feb 11 02:15:14 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:15 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:16 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:17 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:18 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:19 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:20 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:20 fw1 check_reload_status: rc.newwanip starting sk0
Feb 11 02:15:21 fw1 kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on sk0
Feb 11 02:15:21 fw1 php-fpm[67206]: /rc.newwanip: rc.newwanip: Info: starting on sk0.
Feb 11 02:15:21 fw1 php-fpm[67206]: /rc.newwanip: rc.newwanip: on (IP address: 84.192.***.***) (interface: WAN[wan]) (real interface: sk0).
Feb 11 02:15:21 fw1 php-fpm[67206]: /rc.newwanip: IP has changed, killing states on former IP 192.168.100.10.
Feb 11 02:15:23 fw1 php-fpm[67206]: /rc.newwanip: Could not find IPv6 gateway for interface (wan).
Feb 11 02:15:23 fw1 php-fpm[67206]: /rc.newwanip: ROUTING: setting default route to 84.192.***.***
Feb 11 02:15:25 fw1 php-fpm[67206]: /rc.newwanip: phpDynDNS (*****-ip.biz): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Feb 11 02:15:26 fw1 php-fpm[67206]: /rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Feb 11 02:15:26 fw1 kernel: ovpns1: link state changed to DOWN
Feb 11 02:15:26 fw1 check_reload_status: Reloading filter
Feb 11 02:15:26 fw1 check_reload_status: Reloading filter
Feb 11 02:15:26 fw1 php-fpm[67206]: /rc.newwanip: Creating rrd update script
Feb 11 02:15:26 fw1 kernel: ovpns1: link state changed to UP
Feb 11 02:15:26 fw1 check_reload_status: rc.newwanip starting ovpns1
Feb 11 02:15:28 fw1 php-fpm[56235]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:15:28 fw1 php-fpm[67206]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 192.168.100.10 ->  84.192.***.*** - Restarting packages.
Feb 11 02:15:28 fw1 check_reload_status: Starting packages
Feb 11 02:15:28 fw1 php-fpm[67206]: /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
Feb 11 02:15:28 fw1 php-fpm[67206]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.10.1) (interface: []) (real interface: ovpns1).
Feb 11 02:15:28 fw1 check_reload_status: Reloading filter
Feb 11 02:15:28 fw1 php-fpm[67206]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  192.168.10.1 - Restarting packages.
Feb 11 02:15:28 fw1 check_reload_status: Starting packages
Feb 11 02:15:29 fw1 php-fpm[67206]: /rc.start_packages: Restarting/Starting all packages.
Feb 11 02:15:29 fw1 php-fpm[56235]: /rc.start_packages: Skipping STARTing packages process because previous/another instance is already running
Feb 11 02:15:30 fw1 php-fpm[67206]: /rc.start_packages: Reloading Squid for configuration sync
Feb 11 02:15:30 fw1 php-fpm[86166]: /rc.filter_configure_sync: Could not find IPv6 gateway for interface (wan).
Feb 11 02:15:31 fw1 check_reload_status: Syncing firewall
Feb 11 02:15:31 fw1 check_reload_status: Syncing firewall
Feb 11 02:15:32 fw1 php: lcdproc: Start client procedure. Error counter: (0)
Feb 11 02:15:43 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:15:43 fw1 php: lcdproc: Start client procedure. Error counter: (1)
Feb 11 02:15:54 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:15:54 fw1 php: lcdproc: Start client procedure. Error counter: (2)
Feb 11 02:16:05 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:16:05 fw1 php: lcdproc: Start client procedure. Error counter: (3)
Feb 11 02:16:16 fw1 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Feb 11 02:16:16 fw1 php: lcdproc: Too many errors, the client ends.
Feb 11 07:04:06 fw1 php-fpm[73586]: /index.php: Session timed out for user 'admin'
                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    A private IP on your WAN is usually caused by a cable modem that's lost its upstream connection.  Could that be happening here. Is the private address being assigned in any of your internal subnets?

                    Steve

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

                      Is your modem rebooting?  That might explain both symptoms.

                      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
                      • T
                        TieT
                        last edited by

                        Don't know , but that makes sense in a way…  :)
                        On the other hand it's giving me 2 different IP's.

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

                          You mean 192.168.10.1 and 192.168.100.10?
                          You aren't using either of those subnets (/24) internally?

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • T
                            TieT
                            last edited by

                            Nope :-)

                            The 192.168.10.0/24 range is used by openvpn for vpn access

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

                              Ok, so you could have something handing out address in that subnet. The 100.1 address is totally spurious, not used as a tunnel address etc?

                              Steve

                              1 Reply Last reply Reply Quote 0
                              • T
                                TieT
                                last edited by

                                Nope not used.

                                But the WAN link seems stable for now.
                                I made some changes in the System general settings and they seem to work.

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

                                  What did you change?

                                  Steve

                                  1 Reply Last reply Reply Quote 0
                                  • Q
                                    q54e3w
                                    last edited by

                                    I have the same issue and posted some logs in another thread yesterday. I've seen a few posts like this recently do possibly something needs tweaking. I'll add a link to my logs tomorrow when I get back to my desk. I've tried setting static address, disabling monitoring but every 3-7 days my line drops and needs s reboot of wan or box to resolve.

                                    Edit: here's the link to my logs… https://forum.pfsense.org/index.php?topic=88236.msg491251#msg491251

                                    1 Reply Last reply Reply Quote 0
                                    • T
                                      TieT
                                      last edited by

                                      In System -> general settings i added 127.0.0.1 as first dns server without any gateway
                                      then on the second line:
                                      8.8.8.8 with the gateway from my provider 84.192.192.1
                                      on the third:
                                      8.8.4.4 with 84.192.192.1

                                      the option to automatically find the gateway seems to f*ck the wan link sometimes…

                                      I didn't make any changes otherwise to the network config.

                                      Only updated LCDProc and used your guide to set it up because it kept crashing badly.

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

                                        Interesting, thanks.

                                        1 Reply Last reply Reply Quote 0
                                        • X
                                          xtofh
                                          last edited by

                                          Hi,

                                          Are you sure this is resolved? I find it strange that changing dns settings solves this.

                                          Looking at your IP gateway, we're using the same internet provider and I'm having the same issue. (only updated yesterday, noticed the link going down today)

                                          I had a similar issue a few years back: https://forum.pfsense.org/index.php?topic=51420.0

                                          It was solved by using the 2.1 release. But now the problem returned after updating to 2.2.

                                          I'll keep an eye on it (it only happened once now) and will collect logs in case it returns.

                                          Regards,
                                          Kristof.

                                          1 Reply Last reply Reply Quote 0
                                          • X
                                            xtofh
                                            last edited by

                                            Okay, just had this happen again, here's the logs from that time.

                                            All VPNs going down..

                                            Feb 25 13:53:01 pfsense kernel: ovpns23: link state changed to DOWN
Feb 25 13:53:01 pfsense php-fpm[89891]: /rc.newwanip: rc.newwanip: Info: starting on ovpns19.
Feb 25 13:53:01 pfsense php-fpm[89891]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.250.17) (interface: []) (real interface: ovpns19).
Feb 25 13:53:01 pfsense php-fpm[89891]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  192.168.250.17 - Restarting packages.
Feb 25 13:53:01 pfsense check_reload_status: Starting packages
Feb 25 13:53:02 pfsense php-fpm[21603]: /rc.openvpn: OpenVPN: Resync server24 [CUST26] S2S
Feb 25 13:53:02 pfsense kernel: ovpns23: link state changed to UP
Feb 25 13:53:02 pfsense check_reload_status: rc.newwanip starting ovpns23
Feb 25 13:53:02 pfsense kernel: ovpns24: link state changed to DOWN
Feb 25 13:53:02 pfsense check_reload_status: Reloading filter

                                            Our WAN interface.. (em1)

                                            Feb 25 13:53:02 pfsense kernel: em1: Watchdog timeout -- resetting
Feb 25 13:53:02 pfsense kernel: em1: Queue(0) tdh = 801, hw tdt = 770
Feb 25 13:53:02 pfsense kernel: em1: TX(0) desc avail = 31,Next TX to Clean = 801

                                            The rest of the VPNs going down. (we've got 30 or so)

                                            Feb 25 13:53:02 pfsense php-fpm[21603]: /rc.openvpn: OpenVPN: Resync server25 [CUST25] S2S
Feb 25 13:53:02 pfsense kernel: ovpns24: link state changed to UP
Feb 25 13:53:02 pfsense check_reload_status: rc.newwanip starting ovpns24
Feb 25 13:53:02 pfsense kernel: ovpns25: link state changed to DOWN
Feb 25 13:53:02 pfsense kernel: em1: link state changed to DOWN
Feb 25 13:53:02 pfsense check_reload_status: Linkup starting em1
Feb 25 13:53:02 pfsense php-fpm[21603]: /rc.openvpn: OpenVPN: Resync server26 [CUST26] S2S
Feb 25 13:53:02 pfsense kernel: ovpns25: link state changed to UP
Feb 25 13:53:02 pfsense check_reload_status: rc.newwanip starting ovpns25
Feb 25 13:53:02 pfsense kernel: ovpns26: link state changed to DOWN
Feb 25 13:53:03 pfsense php-fpm[21603]: /rc.linkup: DEVD Ethernet detached event for wan
Feb 25 13:53:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1
Feb 25 13:53:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1
Feb 25 13:53:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1
Feb 25 13:53:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1

                                            And then it continues with the can't allocate llinfo.

                                            I tried disconnecting and re-connecting the network cable: no result.
                                            I tried rebooting the cable modem: no result.

                                            It did try getting a new DHCP address:

                                            
$ tcpdump -i em1 -n
14:04:25.808903 IP 81.82.209.44.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:27.003202 IP 81.82.209.44.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:31.003925 IP 81.82.209.44.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:40.009358 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:41.009469 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:42.000206 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300
14:04:44.001156 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:88:cc:fa:2f, length 300

                                            But that's it, never got any.

                                            Final step we took (because it was taking us +5 minutes already) was reboot the pfsense. After the reboot connection was good..

                                            I will probably take a 2.1.5 to temporarily switch this one out (luckily it's in our building) but will leave the 2.2 in place so I can switch easily.

                                            So I there's anything I can/should try, let me know, no problem.

                                            Regards,
                                            Kristof

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