Dhclient question
-
Howdy folks–
Got a question about DHCP client configuration...I'm running this version of code (nanobsd build):
2.1-BETA0 (i386)
built on Thu Sep 27 09:20:43 EDT 2012
FreeBSD 8.3-RELEASE-p4on a Soekris net5501 (this is the gateway for my network at home, the WAN port goes to my cable ISP, getting an IPv4 address via DHCP). Things generally are working well.
However, sometimes my cable ISP hiccups and the cable modem (Motorola SB6120) loses link on its HFC interface. When this happens, the cable modem resets and, for the time that it's trying to re-establish its link, it acts as a DHCP server, presumably so a technician in the field could access the cable modem to do diagnostics. I'm not sure of the exact sequence of events here, but I know the end result is that pfSense winds up getting a DHCP lease from the cable modem itself, not from the DHCP server at the ISP. This lease is only useful for communicating with the cable modem itself; it basically knocks the pfSense box (and therefore my house network) off the Internet.
Clearly a long-term solution involves getting the cable link fixed. But in the meantime...
If this was a basic FreeBSD system, I could (I think) add an /etc/dhclient.conf file with a "reject" directive in it to have it, well, reject the cable modem's DHCPOFFER. I don't see any knobs in the pfSense UI for tweaking this; have I missed something?
While I was writing the above, I thought of another way to handle this; I could just add a firewall rule to reject DHCP packets from the cable modem (I presume I could do this, I haven't done a packet trace to see what I should look for). Is this a better approach?
I couldn't find anything in old forum posts that quite fit this problem. Clearly I need to do a little more homework, but has anyone run into this problem before and if so how did you solve it?
Thanks for any insights, and as always, thanks to the developers for an incredibly useful system.
Bruce.
PS. I'm not sure if this is the right forum for this topic, apologies if not.
-
I thought of another way to handle this; I could just add a firewall rule to reject DHCP packets from the cable modem (I presume I could do this, I haven't done a packet trace to see what I should look for). Is this a better approach?
Better in that it doesn't involve doing any tweaks that pfSense is likely to undo on reboot or firmware upgrade.
Presumably the cable modem's DHCP server has a different (and fixed) IP address than the ISP's DHCP server. You should be able to determine the addresses from the dhclient reports in the pfSense system log (for example, shell command```
clog /var/log/system | grep dhclient
-
I thought of another way to handle this; I could just add a firewall rule to reject DHCP packets from the cable modem (I presume I could do this, I haven't done a packet trace to see what I should look for). Is this a better approach?
Better in that it doesn't involve doing any tweaks that pfSense is likely to undo on reboot or firmware upgrade.
Excellent point.
Presumably the cable modem's DHCP server has a different (and fixed) IP address than the ISP's DHCP server. You should be able to determine the addresses from the dhclient reports in the pfSense system log (for example, shell command```
clog /var/log/system | grep dhclient
Thanks, I did get some useful data from that. I need to investigate this some more, perhaps this weekend, because there's something else odd happening…the cable modem's address is 192.168.100.1, which should have been blocked by the "no RFC 1918" rule. I'll report back when I learn something new.
Bruce.
-
the cable modem's address is 192.168.100.1, which should have been blocked by the "no RFC 1918" rule.
Only for traffic initiated by the modem, which isn't the case for a DHCP reply, the request's state lets that back in.
-
there's something else odd happening…the cable modem's address is 192.168.100.1, which should have been blocked by the "no RFC 1918" rule.
Important detail here: If a system on your LAN starts talking to 192.168.100.1 then there is temporary firewall rule created that allows responses from 192.168.100.1 through.
A DHCP request from cold starts with a DHCPDISCOVER sent to the IP broadcast address. I presume that creates a temporary firewall rule that allows the server's response back. The DHCP client then attempts to communicate with the server by specific IP address. So, now that I have thought about this a bit more, I don't think you can block this by firewall rule.
Can you turn off DHCP server in the modem? Or can you tweak the DHCP lease time down?
Maybe you need help from ISP's tech support to resolve this problem.
-
I guess the line "reject 192.168.100.1" should be in /var/etc/dhclient_wan.conf
-
Just wanted to say thanks for the replies. I need to replenish my supply of round tuits before I can investigate more (and in this in fact is part of why I haven't called the cable company yet to fix their link), but I appreciate the responses. I'll report back when I have something significant to say.
Bruce.
-
My cable modem (a motorola surfboard) behaves exactly in this same way.
I've been poking at the dhclient-script code lately on 2.1 to make it behave better during the switching between subnets, but it can still be problematic.
I hadn't thought about rejecting the DHCP from the modem itself outright… I may need to run some more tests to find a good way to do that, but there should be some combination of "$new_*" variables passed in the environment from dhclient to dhclient-script that would make this easy to identify and skip.
For the time being, to reduce ill side effects, make sure you're on a current snapshot and set a monitor IP for that gateway that is on the internet (e.g. 8.8.8.8) and it should keep that wan from being used when it's really down.
-
Is there a fix for this I currently am having the same issue on my 2.1 box?
version
2.1-BETA0 (amd64)
built on Wed Oct 3 13:18:44 EDT 2012
FreeBSD 8.3-RELEASE-p4 -
On a related subject, there were some fixes committed to FreeBSD's dhclient a few weeks ago:
http://redmine.pfsense.org/issues/2615
-
For the time being, to reduce ill side effects, make sure you're on a current snapshot and set a monitor IP for that gateway that is on the internet (e.g. 8.8.8.8) and it should keep that wan from being used when it's really down.
I got bit by this multiple times again today…I've set up a monitor IP address as you described (I'm using the one of ISP's nameserver's address), now need to see how this works.
For reference for anybody else following this, somebody else ran into this too in another thread:
http://forum.pfsense.org/index.php?topic=56330.0
Thanks again to all for the suggestions...
Bruce.
-
I'm thinking the reject method mentioned in that other thread (and http://redmine.pfsense.org/issues/2704 ) are a good long-term solution for this, even if it's not a general solution.
My cable modem makes multi-wan pretty useless even with an alternate monitor IP when it's down that way because it renews the private IP every 30 seconds which then restarts apinger every 30 seconds which isn't long enough for it to realize the WAN is down and to stop using it. Even with another monitor IP it will still fail in many cases, but it has a better chance of working with the alternate monitor IP. It just depends on how your modem handles the lease.
I'm not sure that rejecting the lease will actually help but I haven't had a chance to try it just yet.
