How to block unwanted DHCP servers
After the latest Internet fiasco at my place, I decided to restructure my network a bit. Previously, I was using Speakeasy as the sole Internet provider and leaving the ComCast connection unused. All of my main machines, including my server and workstation, were on the WAN interface of my router, while other clients, including wireless ones, were on the LAN interface.
This worked great except for a couple use cases. First, my XBox 360 can't see media on a computer unless it's on the LAN. This meant that my XBox either had to be on the WAN or it couldn't get media from my workstation (where I keep most of my media).
Second, I have lots of virtual machines that I boot up from time to time. Because the workstation that hosts them was on the WAN, this necessarily meant that the virtual machines could not communicate with other LAN hosts. Generally, this was not a problem, but it was undesirable.
To address this, I've made ComCast the only connection on the WAN, and moved the Speakeasy service (with multiple static addresses) to the LAN. This means that on the LAN now, there are unroutable private addresses (10.x.x.x) and real routable addresses. A host can be configured for either or both. In the case of my server and workstation, I've configured them for both. Then, by default, clients use the ComCast for internet connectivity, but a few select hosts get the Speakeasy service. This seems to work fairly well except for one annoying problem.
The Broadxent modem used by Speakeasy has a built-in DHCP server that can't be disabled. This DHCP server wreaks havoc on the standard DHCP server that exists on the LAN. This was much less of an issue when the modem was on the WAN (and probably for most people). Not only does it issue a useless IP address (usable only to configure the modem) to unsuspecting clients, but it also seems to cause the DHCP server on my router to disable itself; apparently my router is too polite.
The solution, I found, was to use ebtables to block the DHCP traffic from the modem. Since my router runs a linux variant (similar to OpenWRT), I have full access to the IP stack, including the link layer. Four simple commands prevent DHCP traffic from passing on the LAN.
ebtables -A INPUT --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
I get the feeling that these rules are a bit more than is absolutely necessary. Nevertheless, after issuing these commands, DHCP traffic no longer traverses the LAN except from the built-in DHCP daemon.
This worked great except for a couple use cases. First, my XBox 360 can't see media on a computer unless it's on the LAN. This meant that my XBox either had to be on the WAN or it couldn't get media from my workstation (where I keep most of my media).
Second, I have lots of virtual machines that I boot up from time to time. Because the workstation that hosts them was on the WAN, this necessarily meant that the virtual machines could not communicate with other LAN hosts. Generally, this was not a problem, but it was undesirable.
To address this, I've made ComCast the only connection on the WAN, and moved the Speakeasy service (with multiple static addresses) to the LAN. This means that on the LAN now, there are unroutable private addresses (10.x.x.x) and real routable addresses. A host can be configured for either or both. In the case of my server and workstation, I've configured them for both. Then, by default, clients use the ComCast for internet connectivity, but a few select hosts get the Speakeasy service. This seems to work fairly well except for one annoying problem.
The Broadxent modem used by Speakeasy has a built-in DHCP server that can't be disabled. This DHCP server wreaks havoc on the standard DHCP server that exists on the LAN. This was much less of an issue when the modem was on the WAN (and probably for most people). Not only does it issue a useless IP address (usable only to configure the modem) to unsuspecting clients, but it also seems to cause the DHCP server on my router to disable itself; apparently my router is too polite.
The solution, I found, was to use ebtables to block the DHCP traffic from the modem. Since my router runs a linux variant (similar to OpenWRT), I have full access to the IP stack, including the link layer. Four simple commands prevent DHCP traffic from passing on the LAN.
ebtables -A INPUT --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan1 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
I get the feeling that these rules are a bit more than is absolutely necessary. Nevertheless, after issuing these commands, DHCP traffic no longer traverses the LAN except from the built-in DHCP daemon.
Written on June 30, 2009