DHCP Snooping – The Helpful Nosy Neighbor

It can turn into a nightmare scenario in a heartbeat. Your phone starts erupting with calls and incidents that people in a specific area simply “cannot connect to the network”. After you dust yourself off from coming to terms that you first have to determine what cannot connect actually means, you frantically get to work. You see no visible alarms, and your switches, routers, and DHCP servers all seem to be in order. You get a hold of the first customer, verify they have physical connectivity to the network, then walk them through the process to help you determine if they have an IP address. They do indeed have an IP address, but it is nowhere near valid for the segment of the network they are on currently. After validating from a few other folks that they too seem to have addresses in the same bogus subnet, you have your correlation. There is most likely a rogue DHCP server connected to that local network segment and when new workstations are coming onto the network or renewing their leases with DHCP, this server is receiving those local broadcasts of the DHCP Discover messages and responding by handing out a bogus IP address.

As you can see, this can be a serious problem, but never fear. A solution exists and it’s name is DHCP snooping. DHCP snooping can stop these issues from happening altogether. Just to note, something like the scenario above does not have to be an event that is malicious in nature. There could be a new system being installed that has DHCP server capabilities and if it is misconfigured or the DHCP services are left enabled by default, it could absolutely interfere as a rogue DHCP server if DHCP snooping is not enabled on the network switches.

How does DHCP snooping save the day? At a very high level, when configured, DHCP snooping will block DHCP offer messages as they enter switchports. The result is that if a rogue DHCP server gets plugged in and starts trying to hand out IP addresses to unsuspecting clients, those DHCP offers will get knocked down at the point of entry; right at the port in which the rogue server connects. Since we’re talking about DHCP offer messages, let’s do a breakdown of the different DHCP messages and why blocking the offers from rogue servers entering the network is important. There are four DHCP messages to consider in the process of clients requesting and receiving IP addresses. This is the DORA process, as some of us are taught.

• Discover
  • source: client (0.0.0.0 because it does not have an IP yet) – UDP port 68
  • destination: Broadcast – 255.255.255.255 (UDP port 67) – to be received by an available local DHCP server or DHCP relay agent.
  • general message: “Hi! Would you please assign me an IP address so that I can communicate on the network? Watching cat videos on YouTube is important to me!”
• Offer
  • source: DHCP server – UDP port 67
  • destination: Either broadcast – 255.255.255.255 or the unicast address of the DHCP relay agent (router) if the client is on a different subnet from the DHCP server. Either way, the destination port is UDP 68.
  • general message: “Welcome! I do have an available IP for you! How does 192.168.100.50 sound?”
  • note: Although the destination is broadcast, the client’s source MAC is in the actual DHCP message so that when the client processes the DHCP Offer broadcast message, it knows that it is for that specific client.
• Request
  • source: client (0.0.0.0 because it does not have an IP yet) – UDP port 68
  • destination: Broadcast – 255.255.255.255 (UDP port 67) – to be received by an available local DHCP server or DHCP relay agent.
  • general message: “Yes, I would love to have 192.168.100.50. Would you please allocate it to me?”
• Ack (acknowledgement)
  • source: DHCP server
  • destination: Either broadcast – 255.255.255.255 or the unicast address of the DHCP relay agent (router) if the client is on a different subnet from the DHCP server. Either way, the destination port is UDP 68.
  • general message: “Sure thing, buddy! 192.168.100.50 is all yours (for the specified lease time, that is). Enjoy those internet kittens!”

Now that we have a baseline understanding of the DHCP process, why is it important to block those offer messages? Due to the nature of DHCP Discover messages being sent to a destination of 255.255.255.255, any local DHCP server (including potentially rogue servers) will hear and process the message. The server will then respond with an offer message that the client will process and try to then respond with a request. Well, if the offer message from the rogue server is stopped as it enters the switchport, the client will never receive it and only receive an offer message from a legitimate DHCP server.

Wait, well how do we determine which DHCP servers are legitimate and which are rogue, if DHCP snooping is applied to all switchports? DHCP snooping relies on a concept of trusted and untrusted switch ports. When DHCP snooping is enabled on a switch, by default all ports are in an untrusted state. This means that if a DHCP offer message is received on any port, it will be blocked. To allow the DHCP process to function properly, you need to explicitly configure ports that connect to DHCP servers as trusted ports. These ports would be either be switch ports that connect directly to local DHCP servers, or (probably more commonly) uplink ports. This process will allow you to inherently thwart the threat of rogue DHCP servers wreaking havoc on your network, while still allowing legitimate DHCP servers to “do their thing” by providing IP addresses to clients on the network.

Sample Configuration
I’m familiar with Cisco products, so this configuration will be a sample from Cisco IOS/IOS-XE software. What is nice is that there really is not a whole lot of effort involved in setting up and enabling DHCP snooping on a switch. You’ll want to configure any necessary trusted ports where DHCP offer messages are expected, define the VLANs on the switch that are in scope for DHCP snooping, then enable the DHCP snooping process. Here is an example:

config terminal
interface gi1/1/1
  ip dhcp snooping trust
exit
ip dhcp snooping vlan 10
ip dhcp snooping

Wrapping It Up
While DHCP snooping solves a problem that we hope would be infrequent and rare, if a rogue server does pop up either maliciously or accidentally, it can cause major problems if the mitigation is not in place. Having DHCP snooping enabled is a really low-lift way to protect your network from rogue DHCP servers causing what ends up being network connectivity issues for clients. DHCP snooping is also used in fabric/overlay technologies to ensure that DHCP messages get to the proper switch, and ultimately onto the proper clients. But, that’s a whole other blog, for a whole other post. Thanks for reading, and if I got any of this wrong, please leave a comment so I can correct it!