Constant rerooting
-
@RickyO said in Constant rerooting:
@keyser Thank you for responding.
I tried what you suggested. When the connection went down and stayed down I did the "Release WAN/Renew WAN" and the connection was restored.
The next time it went down I tried restarting unbound. That had no effect, so I doubt that it's a DNS issue. I am using Cloudflare instead of the ISP's DNS and have not allowed DNS Server Override.
This would seem to affirm what @Gertjan suggested: that's it's a problem with my ISP, not my network.
Excellent tests - now you know.
I’m 99.9% sure your ISP is running “DHCP Authentication” which means your ISP requires a full DHCP Discover/acknowledge process to actually “open” the line for a client. The client can only be the MAC address that completed the DHCP discover procedure.
It’s not at all uncommon to use that “lockdown” mechanism on the ISP side.What is uncommon is the fact that your authentication is not sticky with the ISP after a line outage. So the next thing I’m pretty sure of is that the line outtage is the ISP equipment or line that has a problem, because your authentication should stick unless the ISPs concentrator sensed a linkdown when you experience the line is down. (There is a difference between linkdown, and just no service). With a linkdown all authentications are invalidated a has to be done from scratch again. I have the exact same issue on a couple of ISP’s.
The problem is this: All standard equipment just follows DHCP procedure, and as long as there has been no sensed linkdown (possible change of network), the client will never do a new full DHCP discover/acknowledge procedure while the current DHCP lease is valid - it will only try a DHCP renew (Which is not enough for DHCP authentication).
THe ISPs router however is specifically configured to either never do renews (always full discover), or have a gateway monitor that triggers a full discover cycle. But most likely it also senses the “linkdown” and just does a full DHCP discover. But a bridgemode router might not relay the linkdown to the device behind it, and then you have the problem
@stephenw10 Can you think of some custom DHCP settings in pfSense that will have pfSense do a full dhcp discover cycle on a gateway action trigger?
But really: You should contact the ISP and have the look into the outages - as they are likely also seen/present on ports in their devices.
-
@stephenw10 Yes. When I do "Release WAN/Renew WAN" from Status/Interfaces the connection is restored.
I have tried to find things in the logs without success (or knowing where to look...)
For example, when I go to Status/System Logs/DHCP and filter for "WARN" in the message I get mostly stuff about multi-threading and queue size.
-
Hmm, so since the link never actually goes down the dhclient is never re-fired.
You could just set a much shorter DHCP lease. If it fails to renew it should eventually try discover. And you can set the number of times it tries that I believe.
-
@stephenw10 Yeah, that could be a “workaround”.
But the timers under DHCP advanced configuration is requested leasetimes. Does that mean pfSense will use those settings regardless of the DHCP servers returned leasetime (if it does not grant/honour the clients request)?
Setting the leasetime to fx. 10 minuttes should make sure that pfSense is never more than < 10min from coming back up automatically once the line comes back.
-
The requested time is what is sent to the server in the request. But it can ignore that and send you a much longer lease. Any many will do that.
-
@stephenw10 I will double check the next time the connection goes down, but I'm fairly certain that when I went to Status/Interfaces WAN Interface to do "Release WAN", Status and DHCP both said "up".
If I go to Interfaces/WAN DHCP Client Configuration these are my current settings:
-
You can put
dhcp-lease-time XXXin the Send Options field to request that from the server.You can put
supersede dhcp-lease-time XXXin the Option Modifiers field to ignore whatever lease time the server sends you and use that instead. Obviously that should always be less than the lease time the server sends. -
@Gertjan Thank you for your advice. My connection seems stable for now after some work by the leased line owner.
-
@stephenw10 Thank you for your help with this.
-
@keyser Thank you for your help with this.
