PfSense not recovering from WAN failure
-
I just got bit by this one myself. I've got it set to reject DHCP leases from the cable modem and when I came home I had no IPv4 address listed in the interface status. A quick renew fixed it but I would love to have something that retry DHCP lease every so often.
-
I may be having the same problem as FreeMinded
Manually Saving Interfaces/WAN brings the connection back.
My modem is part of a satellite service which in Australia means the connection (upstream of modem) is sometimes intermittent. (ie all too frequent need for manual intervention to restore service).
Has anyone succeeded in working around this problem?I am on latest release:
2.3.4-RELEASE (amd64) -
I also have the same issue with UPC.
But in my case the UPC DHCP server does not answer and pfSense then uses the recorded lease which does not work and just goes offline without trying to get a new lease. Is there a way to keep trying to get a new lease without a timeout?Even though the logs says that it is using the recorded IP, pfSense actually does not. In Status => Interfaces WAN Interface (wan, em0) the Status is up, but the interface has no IP.
Jul 21 02:41:18 pfs dhclient[38369]: em0 link state up -> down Jul 21 02:41:19 pfs dhclient[32644]: connection closed Jul 21 02:41:19 pfs dhclient[32644]: exiting. Jul 21 02:41:57 pfs dhclient: PREINIT Jul 21 02:41:57 pfs dhclient[54351]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Jul 21 02:41:59 pfs dhclient[54351]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Jul 21 02:42:03 pfs dhclient[54351]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Jul 21 02:42:08 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2 Jul 21 02:42:10 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3 Jul 21 02:42:13 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8 Jul 21 02:42:21 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8 Jul 21 02:42:29 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 15 Jul 21 02:42:44 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 9 Jul 21 02:42:53 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 13 Jul 21 02:43:06 pfs dhclient[54351]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3 Jul 21 02:43:09 pfs dhclient[54351]: No DHCPOFFERS received. Jul 21 02:43:09 pfs dhclient[54351]: Trying recorded lease 84.112.2X4.XX Jul 21 02:43:09 pfs dhclient: TIMEOUT Jul 21 02:43:09 pfs dhclient: Starting add_new_address() Jul 21 02:43:09 pfs dhclient: ifconfig em0 inet 84.112.2X4.XX netmask 255.255.255.0 broadcast 255.255.255.255 Jul 21 02:43:09 pfs dhclient: New IP Address (em0): 84.112.2X4.XX Jul 21 02:43:09 pfs dhclient: New Subnet Mask (em0): 255.255.255.0 Jul 21 02:43:09 pfs dhclient: New Broadcast Address (em0): 255.255.255.255 Jul 21 02:43:09 pfs dhclient: New Routers (em0): 84.112.2X4.1 Jul 21 02:43:10 pfs dhclient: New Routers (em0): 84.112.2X4.1 Jul 21 02:43:11 pfs dhclient: Deleting old routes
Also the protocol timing does not seem to work if the documentation is correct because it should retry every 5 minutes: https://www.freebsd.org/cgi/man.cgi?query=dhclient.conf&sektion=5#PROTOCOL_TIMING
Thanks!
-
on actual isp outages pfsense has been fine for me (when it hasnt I believed it to be an isp issue).
However yesterday I was testing failover by pulling the wan cable for about 30 seconds and then replacing it.
After the test my ipv6 traffic was working fine, the wan ipv4 gateway continued to show 100% loss tho, and no action was taken by pfsense to recover the connection, so there was nothing in the logs for it to reinitialise the wan, was very odd. Otherwise tho in normal use I havent had problems.
I might play with the settings shown in this thread, I think wont work, but never know. :)
-
Hi I have the same or similar problem. My pfsense box keep dropping the wan ip e.g it set it to 0.0.0.0 and never gets out of this state until I reboot. I have two other devices connected to the same fiber switch and thy have nerver failed for the last 3 years (Dlink router and a alarm box).
-
I also have the same issue with UPC.
But in my case the UPC DHCP server does not answer and pfSense then uses the recorded lease which does not work and just goes offline without trying to get a new lease. Is there a way to keep trying to get a new lease without a timeout?Dear all,
I have the same problem :-[
What i figured out is, if I unplug the WAN-cable from pfSense / cable-modem and plug it in again, than the gateway is „green“ and the Internet works again …Has someone solved the problem finally ?
Is it a pfSense bug ?Thanks a lot in advance !!
-
Dear all,
I have found a solution for my WAN failure problem with UPC and pfSense.
Symptoms:
WAN would randomly lose its connection and not recover.
Status > System Logs > System > Gateways Log ist full of sendto error: 65
Status > System Logs > System > DHCP Log shows:
No DHCPOFFERS received.
Trying recorded lease XXX.XXX.XXX.XXX
Deleting old routesExplanation:
The UPC router goes down for an unknown reason and might restart. (Not sure what the router is doing)
When the links to the router comes back up PFS tries to get a lease, but by default times out after 60 seconds and then tries the recorded lease.
That would in my case even work since I always have the same IP.
Unfortunately at the end PFS deletes the old routes including the default route.
This causes the sendto error: 65.
You can check this by going to: Diagnostics > Routes and check if you still have a default route when WAN is down.
In my opinion this is a bug.Solution:
In my case it always takes about 3 minutes until the UPC dhcp server starts to respond again.
So all you have to do is go to: Interfaces > WAN
DHCP Client Configuration section
check Options Advanced Configuration
Set the Protocol timing Timeout higher.
I chose 1800 which is 30 minutes, but I wanted to be on the safe side.Since then my WAN has recovered every time.
I also attached a screenshot.![Bildschirmfoto 2017-08-24 um 12.10.17.png](/public/imported_attachments/1/Bildschirmfoto 2017-08-24 um 12.10.17.png)
![Bildschirmfoto 2017-08-24 um 12.10.17.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2017-08-24 um 12.10.17.png_thumb) -
@bunzilein, thank you very much for sharing your experience and solution :)
Is there any possibility to inform the pf-Team on this issue to check whether it is a bug or not ?
As newbie, may I ask you to explain or to share to me some link where I can study what each of the "Protocol timing" options mean and what the values are doing (causing), if you don't mind, please ?
Thanks again a lot !!
-
The link is actually on the bottom of the DHCP client configuration section: https://www.freebsd.org/cgi/man.cgi?query=dhclient.conf&sektion=5#PROTOCOL_TIMING
If this also solves your problem and you have the same behavior with default route being deleted then maybe it is a bug.
Test it and if you find it to be a bug as well report it like this: https://doc.pfsense.org/index.php/Bug_reporting -
thanks bunzilein will try your solution.
I had an actual isp outage a couple of nights ago, the ipv6 came back up by itself but the ipv4 didnt, the unit just sat there not even showing activity in logs trying to reconnect. When I manually disabled the WAN and reenabled it again it came back up fine.
Also my isp is dhcp also, so is possibly perhaps a default settings issue.
-
@bunzilein, belated thanks for your posted tentative solution.
I have set my porotocol timing timeout to 1800 seconds and will run with that from here on or until further indications arise. Unfortunately it can be a month or more between the observed incidents so it will take a while to draw subjective conclusions. -
Hi
I have seen several fellows having the same issue
Suddenly we loose internet connectionIn my case after almost exactly 8 hrs of use, pfsense kicks me out of the internet, and I do need to restart my pfsense
I am trying the following:
Set up my modem to use a smaller DHCP range of IPs, and on pfsense I set up WAN interface with a static IP, outside of that rangeI will see if that solves the problem, I am posting it before confirming that, if maybe it helps someone
Have a good time