WAN is 0.0.0.0 after power loss, have to "renew" to get IP
-
I have noticed this a couple of times. I think it is happening when my pfSense is rebooted, but I noticed it the other day when the power went out at my house.
After the power came back up, I had my local network, but did not appear to have internet access. So I pulled up pfSense WebGUI and noticed the WAN interface was "up" but didn't have an IP. When I opened the Status > Interfaces page, I noticed that the IP of WAN was 0.0.0.0. So I clicked the Release/Renew button and my public IP showed up and I could access the internet.
How can I get pfSense to automatically fix this? I travel frequently and use services hosted at home (particularly Plex).
I did see Auto DHCP Renew not working on WAN (How to fix it). Is that the appropriate fix?
-
….
I did see Auto DHCP Renew not working on WAN (How to fix it). Is that the appropriate fix?Be ware that you cited a fix for a pfSense version that is more then ancient.
However, the issue "pfSense does not retrieve an IP WAN running DHCP client from modem device" is known. Typically, this can happen when both devices boot up at the same time and pfSense boots faster then the modem, it start to fire DHCP requests, but the modem can't reply yet. Restart the requests by hand or rebooting pfsense by hand will solve the issue (but impossible if your are away).
You should mention your region and ISP, so other can share their experiences.
-
As Gertjan has said, this can happen when pfsense boots quicker than the modem.
There is a pretty easy fix, you run a script that monitors the WAN connection by pinging an external address. If the ping fails to respond at all in given period then one of two things happens, firstly it will set the WAN port Down and then back UP again, this is often enough to re-trigger the DHCP process and everything will kick back into life. If that fails, the ping failure timeout will then trigger a reboot of pfSense.
Here's the script. extract and copy it to usr/local/bin, make sure it's set to executable ( 755 )
Now create a Cron event, install the Cron GUI if you wish to make it easy.
-
I don't think this is an issue with the modem as it is on a battery backup UPS. I have fiber optic internet service from Montana Opticom.
Also, I would need to test to confirm, but I am pretty sure I have seen this behavior after updating pfSense. I currently have 2.4.2 and 2.4.2_1 is available. I may try to update today and see if I can replicate.
-
It's not an issue with the modem, but I've seen the 0,0.0.0 issue before, taking the WAN interface down and back up again fixes it. The script I have posted not only helps that, but if pfSense for any reason has a problem then providing the it's not totally dead it will reboot pfsense, even when you are thousands of miles away, it happened to me once and the script saved a LOT of grief.
-
Now create a Cron event, install the Cron GUI if you wish to make it easy.
How often do you run it? I currently have it set for 10 minutes (*/6).
-
In the line ping -o -s 0 -c 10 8.8.8.8, what does the -o do? It's not listed in the man page. Also, why -s 0? That's setting the packet size to 0, which is smaller than the minimum allowed for a packet size. When I run the script as is, it kills my system.
-
Thanks marjohh, I will try this. Does this output to the logs somewhere? I would like to see that it is working…
@marjohh:
As Gertjan has said, this can happen when pfsense boots quicker than the modem.
There is a pretty easy fix, you run a script that monitors the WAN connection by pinging an external address. If the ping fails to respond at all in given period then one of two things happens, firstly it will set the WAN port Down and then back UP again, this is often enough to re-trigger the DHCP process and everything will kick back into life. If that fails, the ping failure timeout will then trigger a reboot of pfSense.
Here's the script. extract and copy it to usr/local/bin, make sure it's set to executable ( 755 )
Now create a Cron event, install the Cron GUI if you wish to make it easy.
-
Does this output to the logs somewhere? I would like to see that it is working…
Noop.
But find, as an example, this part in the script :# A message to the console (I like feedback) echo "Testing Connection at" `date +%Y-%m-%d.%H:%M:%S` "uptime:" $uptime "seconds" >> file.txt wall file.txt rm file.txtand run this from the command line :
/usr/sbin/logger -ip notice "This line goes to the system log file"and check your logs ;)
Now you have all the ingredients ;)
Good luck ! -
@Guest said in WAN is 0.0.0.0 after power loss, have to "renew" to get IP:
ping_check.zip
Hello, anybody can public the attachments?
-
From 2017 ?
-
Yup, no way to recover those as far as I know. There are scripts named the same available via Google though.
