DHCP Client Issue

xero9 · Nov 10, 2019, 10:35 PM

Hi all,

So I have a VERY frustrating issue that makes me want to leave pfSense as it’s such basic core functionality that is messing up.

The firewall gets its IP using DHCP from my cable provider, which is all fine and dandy except I was having power outages and what was happening was everything was coming back up but the firewall would come back up before the modem and would not obtain an IP. Logically if the firewall doesn’t have an IP one would think it would try to renew periodically but it will go hours and take no action on its own and I have to log in and renew the lease.

I’ve heard it’s because the Hiltron modems give a 192.168.100.0 IP before fully booting up and I even changed a setting a few months ago to delay 120 seconds or so before trying to obtain an IP but that still doesn’t work.

My solution was to get a UPS, which of course is not a fix but a bandaid solution and of course the next power failure lasted longer than the UPS!

Gertjan · Nov 11, 2019, 12:21 AM

Hi,

On the Interfaces / WAN page, check "Advanced configuration".

Then read https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html -you'll be recognizing your issue right away, and close to a solution ;)

xero9 · Nov 11, 2019, 12:36 AM

@Gertjan
Hi there,

Thank you for the prompt reply :)

So I did as you said and I see there are several protocol timing settings I can set, which is fine and maybe solve my problem, however when reading the document linked it has values such as 60 seconds and 5 minutes by default. To me, it seems it’s just simply not doing these.


retry time;
	     The retry statement determines the	time that must pass after the
	     client has	determined that	there is no DHCP server	present	before
	     it	tries again to contact a DHCP server.  By default, this	is
	     five minutes.

I would think after 5 minutes (after everything is back online 100%) pfSense would get its IP and be back in business. If it missed that mark, then 10 minutes, 15, 20, etc. after 8 hours it still doesn’t work and I simply reboot the firewall and it works makes me think something isn’t functioning the way it should.

Am I missing something? I do appreciate your help!

johnpoz · Nov 11, 2019, 1:03 AM

Just reject your modems dhcp server 192.168.100 address... In the 10 some years been using pfsense, and cable modems I have never run into this issue.. The lease time that your modem should hand out from its 192.168.100 address pool should be really short.. So once it gets say a 192.168.100 address that should expire shortly and then it would get an IP from your ISP..

nkaminski · Nov 11, 2019, 2:46 PM

@xero9
From the symptoms you describe it sounds like you are hitting this bug https://redmine.pfsense.org/issues/9267

Specifically, what happens is that if the DHCP client times out and there is any cached lease, pfSense will use said IP regardless of if it is valid or not for the remaining lease time.

However, if you are willing to compile dhclient and apply a patch using the pfSense system patch tool, it's pretty straightforward to fix this.

Rejecting the lease from the modem as mentioned earlier will also likely work. However the caveat to be aware of is if your modem loses upstream link when pfSense tries to renew the DHCP lease (small chance but not zero) you may lose your connection.

xero9 · Nov 12, 2019, 9:27 PM

@nkaminski This sounds like my issue exactly!

So I'm no stranger to applying patches to file and re-compiling in say a Linux environment, but are there instructions on how I do this under pfSense? Is there a site with some documentation I can read? Thanks!

e4ch · Nov 16, 2019, 10:36 PM

fyi: see also this thread for a workaround
https://forum.netgate.com/topic/127403/auto-renew-dhcp-after-outage

nkaminski · Nov 19, 2019, 12:02 AM

@xero9

My recommendation if you are new to building FreeBSD would be to prepare a "vanilla" FreeBSD 11.2 system/VM and then follow https://www.freebsd.org/doc/handbook/makeworld.html to verify you can build FreeBSD from source successfully. You don't need to actually install, just make sure you can successfully complete the process leading up to such.

Once you confident with building the unmodified source, apply the dhclient patch with arguments '-p1' from the referenced pfSense bug ticket to /usr/src and rerun make on your build host.

Then all you will need to do is copy the dhclient binary across to your pfSense host, reboot, apply the dhclient-script patch using the pfSense "system patches" package and you should be good.

Do also keep in mind that pfSense updates overwrite /sbin, therefore in my case I created a /patch folder containing a copy of the patched dhclient so that I can copy it into place after updates.

timboau 0 · Feb 23, 2020, 10:54 PM

@johnpoz The specific problem we have here in Australia with NBN in particular is as follows:

After a power outage both the modem and pfsense reboot. (modem is a VDSL type)
pfsense is much faster at rebooting than the Modem is to sync up and allow pass through for the DHCP request:
NBN / FTTN Modem in passthrough mode. (so in this case its not the modem giving out a local DHCP addresss)

Pfsense sees the ethernet WAN port come up - then requests a DHCP doesnt get it (modem stull doesnt have sync) and seems to give up and marks the port N/A and stops trying.

if at this stage you reboot pfsense its often OK
unplug/replug the WAN ethernet cable its often OK
WAN - release / reacquire a DHCP lease sometimes works.

Gertjan · Feb 24, 2020, 8:13 AM

@timboau-0 said in DHCP Client Issue:

the specific problem we have here in Australia

Bad news, and good news : this problem is known all over the planet.
Instead of using Interfaces > WAN > "Reject leases from", go one line lower, check out what "Protocol timing" can do for you, add a 'delay' that works for you.

timboau 0 · Feb 24, 2020, 8:13 AM

@Gertjan
Thanks, I'll investigate and see how that goes - although I don't think its really addressing the root cause of the problem.

While the delay function might work in this exact scenario I still don't feel a once of delay is the correct way to fix this problem. Sometime Sync can take longer than expected for example.

I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.

Gertjan · Feb 24, 2020, 9:09 AM

@timboau-0 said in DHCP Client Issue:

I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.

And thus hammering that WAN interface (network, because it's a broadcast) until the end of times ? That couldn't be the good default DHCP client behaviour neither.
It's a classic issue : on a network, the DHCP server should be running before clients are activated.

What often happens is that the modem, slower as pfSense to start up, is handing over a LAN type, aka RFC 1918, for local management. Not good neither.

e4ch · Feb 27, 2020, 11:26 PM

@timboau-0 Keep in mind that this is a bug (see links above). If you don't want to use the scripts, then wait for the release 2.5.0, which will likely include the fix.

nkaminski · Feb 27, 2020, 11:42 PM

@timboau-0 Exactly. The case you describe :"if the WAN has a 0.0.0.0 or N/A IP address and is set to DHCP it should be continually be trying to obtain a valid IP address" is exactly the behavior that this bug prevents.

Specifically, once dhclient times out, it will not retry for a potentially very long time; if you can share the dhclient logs (real IPs not necessary) from when you see the IP loss, we will be able to tell if this bug is indeed being triggered.

Hammering the WAN link with a large quantity of DHCP requests is also indeed bad, hence the implementation of an exponential backoff algorithm to mitigate this.