Dhclient question
-
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.
