Refuse RFC1918 offers on DHCP WAN
-
I have what may be something of an unusual problem and am looking for a solution.
My ISP recently updated the firmware of my cable modem such that during a reboot or lack of RF connectivity, even when in bridge mode, it hands out leases in the RFC1918 reserved space using its own RFC1918 address for the gateway. I suspect that this change was made to enable their users to continue to access the modem interface pages in the event of an RF outage, but it causes undesirable behavior for me. Specifically, I have two WAN connections for redundancy–the secondary being from a different provider and using a different technology (VDSL2). By default, pfSense will use the gateway address as the monitor address, meaning that when the modem reboots and the ethernet link cycles, pfSense will request a new lease, and receive an RFC1918 address with the modem's address as the gateway. Accordingly, apinger sees the monitor address online and will attempt to revert to the primary connection--even though the RF interface may still down.
The obvious workaround is to statically assign a monitor address further upstream, and I've done that. However, that's not ideal for multiple reasons--it's possible that address could be inaccessible outside of a failover of my own connection, causing unintentional failovers to the backup circuit, and it also adds more variability to the quality monitoring, as I'm not really monitoring the latency of my first hop anymore.
The modem does not have any ability to define the leases during this mode, and the RFC1918 WAN block rule doesn't do anything to stop dhclient from using the lease offer. My initial thought is that it would be nice to be able to tell dhclient to refuse lease offers that are in the RFC1918 address space, but I'm open to other solutions.
-
It's significantly preferable to monitor not your gateway, but something upstream of it, ideally out on the Internet. Something anycasted so you're not just pinging one box somewhere (like Google DNS, OpenDNS, etc.).
Denying private leases would be a nice option to have at some point since this scenario is getting more common and is entirely undesirable IMO. Not sure if that's doable at all with dhclient today.
-
The dhcp issue has come up before, and the ideas suggested included using L2-MAC-filtering (ipfw) or using the "reject x.y.z.w" keyword (check http://zhigang.org/wiki/DHCP "How to Prevent DHCP Client from Receiving IP from a Specific Server?").
However AFAIK neither of these two methods are doable from pfSense webGUI …
-
Thank you–that put me on the right path. I modified the function interface_dhcp_configure in /etc/inc/interfaces.inc to include the reject statement for the modem's IP with the other dhclient options, and now its leases are refused:
dhclient[61041]: DHCPOFFER from [x.y.z].1 rejected. -
-
Yes. The behavior now is that the interface has no address until the CM syncs and the ISP's DHCP servers respond, meaning that there's no concern with pfSense trying to use that gateway–regardless of the monitor address.
-
Thank you–that put me on the right path. I modified the function interface_dhcp_configure in /etc/inc/interfaces.inc to include the reject statement for the modem's IP with the other dhclient options, and now its leases are refused:
dhclient[61041]: DHCPOFFER from [x.y.z].1 rejected.This file is on a r/o filesystem on my CF card booted system. I see what needs to be changed, but how can I do it? I have never looked at the inner workings of pfsense before.
-
From the shell, run /etc/rc.conf_mount_rw to go into read/write mode.
Then run /etc/rc.conf_mount_ro to go back to read-only.
Or if you're on 2.1, there is a button to switch on Diagnostics > NanoBSD.
-
From the shell, run /etc/rc.conf_mount_rw to go into read/write mode.
Then run /etc/rc.conf_mount_ro to go back to read-only.
Or if you're on 2.1, there is a button to switch on Diagnostics > NanoBSD.
Thanks this worked great.
The only glitch was that "reject" to me implies rejecting something given to me, rather than ignoring another entity. So, I was putting the IP address I didn't want. Once I change that for the IP of the server the pieces of the puzzle fell into place.
-
For the record this is the end of the function interface_dhcp_configure in /etc/inc/interfaces.inc
My reject statement is included. Releasing and renewing the interface creates /var/etc/dhclient_wan.conf from this template
$dhclientconf .= <<<eod<br>interface "{$wanif}" {
timeout 60;
retry 1;
select-timeout 0;
initial-interval 1;
{$dhclientconf_hostname}
script "/sbin/dhclient-script";
reject 192.168.100.1;
}</eod<br> -
Here ya go:
https://github.com/pfsense/pfsense/commit/850324a23e45b3a11231f910290f8ff9b774d9bc
