Web down after power failure
-
In a very simple home installation (SG-1100), after each power failure we have to reboot the router to reestablish web access from our computers. I've searched the web for how to resolve this and the only solution given is to get a UPS. Isn't there a way to tell pfsense to talk to the modem and fix the connection automatically? Or at least do something in the GUI to tell it to do so without booting?
-
What sort of power failure? What loses power?
Do you have more than one gateway defined? Check in System > Routing > Gateways.
Steve
-
@stephenw10
WAN_DHCP WAN Interface WAN_DHCP Gateway
WAN_DHCP6 WAN Interface WAN_DHCP6 Gateway
But P6 is always pending on dashboard. -
Should be OK on the route then.
What loses power after the failure? Everything?
Can you still reach the pfSense webgui from the LAN?
Does the WAN have an IP address when it's in the failed state?
-
@stephenw10
This is the case of power failure to the house.
Yes I can reach the pfSense webgui from the LAN after power is restored.
How would I check if WAN has an IP address when in the failed state? -
The interfaces widget on the dashboard would show it. Status > Interfaces will also show it.
If you unplug the Ethernet from the WAN NIC and reconnected it does that restore the connection?
It sounds like this could be a timing issue when both the modem and pfSense are booted at the same time when the power comes back.
-
@stephenw10 After rebooting just the modem, web comes back with no problems. After rebooting modem and router at same time, pfsense WAN_DHCP shows a normal looking IP but Pending and computers have no internet. After disconnecting ethernet between router and modem for 10 sec and reconnecting, pfsense dashboard Gateways shows WAN_DHCP Online status but computer still shows "no internet". Reconnecting wifi in Windows did not help - same on phone. Ping 8.8.8.8 and google.com failed. CMD prompt ping amazon.com returns "Ping request could not find host amazon.com. Please check the name and try again." But ping via pfsense GUI succeeds:
Results
PING amazon.com (205.251.242.103): 56 data bytes
64 bytes from 205.251.242.103: icmp_seq=0 ttl=243 time=19.219 ms
64 bytes from 205.251.242.103: icmp_seq=1 ttl=243 time=17.778 ms
64 bytes from 205.251.242.103: icmp_seq=2 ttl=243 time=18.464 ms
--- amazon.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.778/18.487/19.219/0.589 msAfter rebooting router and reconnecting wifi in Windows all works.
Here is a recent DHCP logs:
Sep 16 11:08:12 dhclient 74961 New Broadcast Address (mvneta0.4090): 192.168.100.255
Sep 16 11:08:12 dhclient 75582 New Routers (mvneta0.4090):
Sep 16 11:08:12 dhclient 76451 Adding new routes to interface: mvneta0.4090
Sep 16 11:08:12 dhclient 78246 Creating resolv.conf
Sep 16 11:08:12 dhcpd 85282 DHCPREQUEST for 192.168.200.73 from ... (Pixel-3a) via mvneta0.4091
Sep 16 11:08:12 dhcpd 85282 DHCPACK on 192.168.200.73 to ... (Pixel-3a) via mvneta0.4091
Sep 16 11:08:12 dhclient 64455 bound to 192.168.100.20 -- renewal in 30 seconds.
Sep 16 11:08:15 dhcp6c 43748 failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Sep 16 11:08:15 dhcp6c 43748 failed initialize control message authentication
Sep 16 11:08:15 dhcp6c 43748 skip opening control port
Sep 16 11:08:15 dhcp6c 43748 Sending Solicit
Sep 16 11:08:17 dhcp6c 43748 Sending Solicit
Sep 16 11:08:19 dhcp6c 43748 Sending Solicit
Sep 16 11:08:23 dhcp6c 43748 Sending Solicit
Sep 16 11:08:31 dhcp6c 43748 Sending Solicit
Sep 16 11:08:42 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67
Sep 16 11:08:42 dhclient 64455 DHCPACK from 192.168.100.1
Sep 16 11:08:42 dhclient 42182 RENEW
Sep 16 11:08:42 dhclient 42575 Creating resolv.conf
Sep 16 11:08:42 dhclient 64455 bound to 192.168.100.20 -- renewal in 30 seconds.
Sep 16 11:08:47 dhcp6c 43748 Sending Solicit
Sep 16 11:09:12 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67
Sep 16 11:09:13 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67
Sep 16 11:09:15 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67
Sep 16 11:09:16 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67
Sep 16 11:09:18 dhclient 64455 DHCPREQUEST on mvneta0.4090 to 192.168.100.1 port 67 -
Does it have a default route in that state? Check Diag > Routes.
-
@stephenw10 When it's up normally it shows:
default normal ip UGS 7 1500 mvneta0.4090
But in the down state the default line is missing. -
Hmm, do you see anything in the logs where it fails to add a default route?
Try setting WAN_DHCP as the default IPv4 gateway in Sys > Routing rather than automatic.
-
@stephenw10 said in Web down after power failure:
WAN_DHCP as the default did not help. Don't know how to read the various logs. -
Well when the DHCP WAN comes up I expect the gateway to be reset as the default route. If that fails there would usually be an error in the System and/or gateways logs showing that failed and why.
Check the dhcp log for the dhclient entries. You should see something like:
Sep 17 22:11:51 dhclient 8480 Starting add_new_address() Sep 17 22:11:51 dhclient 8722 ifconfig ix3 inet 172.21.16.232 netmask 255.255.255.0 broadcast 172.21.16.255 Sep 17 22:11:51 dhclient 9400 New IP Address (ix3): 172.21.16.232 Sep 17 22:11:51 dhclient 10067 New Subnet Mask (ix3): 255.255.255.0 Sep 17 22:11:51 dhclient 10981 New Broadcast Address (ix3): 172.21.16.255 Sep 17 22:11:51 dhclient 11527 New Routers (ix3): 172.21.16.1 Sep 17 22:11:51 dhclient 12199 Adding new routes to interface: ix3 Sep 17 22:11:51 dhclient 13332 /sbin/route add -host 172.21.16.1 -iface ix3 Sep 17 22:11:51 dhclient 14251 /sbin/route add default 172.21.16.1If that route add default command fails it should show an error there and/or in the system log at that time.
-
@swisscheese said in Web down after power failure:
solution given is to get a UPS.
If you experience frequent power failure, investing in one is a must...
-
This post is deleted! -
@swisscheese said in Web down after power failure:
Sep 18 07:32:28 dhclient 80717 Adding new routes to interface: mvneta0.4090
Hmm, not trying to add a default route it looks like. I wonder if the dhcp server is sending it a default route. You might try capturing that dhcp sequence in a pcap and looking at what's actually being sent.
However I think I would try a simpler test. What happens if you manually boot the modem and then boot pfSense after, say, 30s?
If that works it's an easy workaround to add a longer boot delay to pfSense so that the modem has finished booting before pfSense requests a dhcp lease.
Steve
-
This post is deleted! -
@stephenw10 Good idea on the boot delay. I used 60 sec (did not try 30) and it seemed to work. Thank you!
