WAN link going down
-
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' -
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
-
Is your modem rebooting? That might explain both symptoms.
-
Don't know , but that makes sense in a way… :)
On the other hand it's giving me 2 different IP's. -
You mean 192.168.10.1 and 192.168.100.10?
You aren't using either of those subnets (/24) internally?Steve
-
Nope :-)
The 192.168.10.0/24 range is used by openvpn for vpn access
-
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
-
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. -
What did you change?
Steve
-
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
-
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.1the 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.
-
Interesting, thanks.
-
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. -
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 filterOur 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 = 801The 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 em1And 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 300But 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 -
Id love to share with you a solution but Im seeing exactly the same thing here and can confirm its not fixed for me by manipulating DNS as TieT suggested fixed his. My issue is triggered by my ISP WAN dhcp address expiring every seven days. Rebooting the firewall is the easiest way to fix it, I spent a couple of hours last time it went down capturing packets and what not and it appears in my situation to be related to DHCP queries not syncing. It could be specific to my ISP and I'll keep capturing and investigating if/when it continues. Thanks for sharing your logs.
-
I've put my 2.1.5 back in place. let's see how this goes. (I'm pretty sure this will stay up)
I also suspect it has something to do with the dhcp renewal.
2.1 solved it in 2012 for me :-) - https://forum.pfsense.org/index.php?topic=51420.0
-
Feb 25 13:53:02 pfsense kernel: em1: Watchdog timeout -- resettingThat is a pretty bad sign.
You might try looking at sysctl dev.em.1
There may be some error couters there that show something nasty happened.Steve
-
Ok, put a switch in between modem<->pfsense , recorded the current state of sysctl dev.em.1 (attached)
Currently it's good :o (lol) but if the problem returns I'll redo the sysctl dev.em.1 and won't reboot. (I'll just use a 2.1.5 device so can grab any logs needed of the 2.2)
Thanks, I'll keep you posted.
Kristof
-
I'm getting the same issue.
Seems my external IPv4, which is set by DHCP, is randomly disconnecting while the IPv6 address is fine.
No clue what's the cause, but I'm running the latest version on a Nano USB.
-
Ok, not resolved yet :(
My current configuration is Modem <-> Switch <-> pfsense.
I did see some bad things in the sysctl.em.1 :
dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 4294967295 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.missed_packets: 28403My log was already full (I will make it bigger or use remote syslog) but I did see this:
.. first a ton of these messages: Feb 28 11:21:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:04 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:05 pfsense kernel: em1: Watchdog timeout -- resetting Feb 28 11:21:05 pfsense kernel: em1: Queue(0) tdh = 0, hw tdt = 993 Feb 28 11:21:05 pfsense kernel: em1: TX(0) desc avail = 31,Next TX to Clean = 0 Feb 28 11:21:05 pfsense kernel: em1: link state changed to DOWN Feb 28 11:21:05 pfsense check_reload_status: Linkup starting em1 Feb 28 11:21:06 pfsense php-fpm[43360]: /rc.linkup: DEVD Ethernet detached event for wan Feb 28 11:21:06 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:06 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:09 pfsense check_reload_status: Linkup starting em1 Feb 28 11:21:09 pfsense kernel: em1: link state changed to UP Feb 28 11:21:10 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:10 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:11 pfsense php-fpm[43360]: /rc.linkup: Shutting down Router Advertisment daemon cleanly Feb 28 11:21:11 pfsense php-fpm[54180]: /rc.linkup: DEVD Ethernet attached event for wan Feb 28 11:21:11 pfsense php-fpm[54180]: /rc.linkup: HOTPLUG: Configuring interface wan Feb 28 11:21:13 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:13 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 Feb 28 11:21:14 pfsense kernel: arpresolve: can't allocate llinfo for 81.82.192.1 on em1 .. and then more of theseThis only happens on 2.2, the same configuration with 2.1.5, no problem. It took about 30 hours before it occured the first time.
Anything else I might try to resolve/further pinpoint this?
Regards,
Kristof.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.