Troubleshooting DHCP with the NMAP Broadcast-DHCP-Discover script

The NMAP DHCP Broadcast script sends a DCHP Discover request to the broadcast address (255.255.255.255) and returns the results. It can be very useful for trouble shooting DHCP issues.

The NMAP man page for the script is here - broadcast-dhcp-discover. In these examples I am running the script on a Linux box but NMAP works on Windows/Linux/Mac.

Does the Switch have the DHCP service running?

I set up a new (recycled from another site) core switch and DHCP wasn't working. I double checked the "ip helper-address" on the switch, pinged the DHCP server from the switch using the DHCP server as the destination and  the Vlan interface IP as the source and it worked.

I gave a client a static IP address and could ping the DHCP server. Wireshark showed that the client was sending a DHCP Discover but not getting an answer. So I ran nmap in broadcast discover mode:

C:\Windows\System32>nmap -sU -p67 --script broadcast-dhcp-discover

Starting Nmap 6.47 ( http://nmap.org ) at 2016-05-15 22:26 Pacific Daylight Time
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 11.20 seconds

That was the expected result since DHCP was working. Next I ran nmap with directed discover mode which uses unicast instead of a broadcast:
C:\Windows\System32>nmap -sU -p67 --script dhcp-discover 10.46.1.53

Starting Nmap 6.47 ( http://nmap.org ) at 2016-05-15 22:27 Pacific Daylight Time
Nmap scan report for 10.46.1.53
Host is up (0.00s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover:
|   DHCP Message Type: DHCPACK
|   Server Identifier: 10.46.1.53
|   Subnet Mask: 255.255.255.0
|   Vendor Specific Information: \xDC\x03NAP
|   Router: 10.40.109.1
|   Domain Name Server: 192.168.10.221
|_  Domain Name: pu.pri

So the Layer 3 networking was correct, it looked like relay wasn't working. I wasn't able to put Wireshark on the customer's server so I couldn't verify that the DHCP Discover was getting to the server. I double checked the ip helper-address again to make sure that I hadn't fat fingered it and it was correct.

Next I ran:

sh run all | i service dhc

no service dhcp

Turns out the switch had the DHCP service disabled since it wasn't needed in the last deployment and Cisco best practice says to disable unused services.

Decommissioning a DHCP server

I have found this script to be useful when decommissioning a DHCP server and bringing up a new one. You can run a scan before and after the change and compare the scope options that are returned.

I was moving DHCP from a Cisco Router to a windows server recently. The customer set up the Windows server and I shut down the DHCP server on the router. But when we rebooted a couple clients got an address from another site!

I assigned the switch port that I was connected to the correct vlan, assigned a static IP and ran the script. It found the server and the scope options were wrong. It turned out to be a problem with the server that required a reboot. But the script was useful because it quickly showed that the correct server was replying with incorrect scope options.

Is there a Rogue DHCP sever on the network?

In my lab I set up two DHCP servers to simulate a rogue DHCP server. I had Wireshark running during the test to see what the script was doing. Unfortunately, even though each server sent back an offer, the script terminated on the first one. I was able to run the script two times in a row and it did find the second server but it was hit or miss.

Then I opened a second terminal session, hit Enter on the first one then immediately hit Enter on the second. That seemed pretty reliable for finding both DHCP servers.

Is the DHCP Scope out of Addresses to Assign?

Another use case is to see whether a server is offering a DHCP address. I have been trouble shooting wireless issues lately where the problem wasn't wireless but a depletion of IP addresses in the DHCP scope.

I typically don't have a log in to the customer's Windows Server but I do have access to the switches. To use the script in this situation you will need to connect to a port with an Ethernet cable and set the port to the correct vlan.

In this example I ran the script with a Windows Server that had an available IP address in the scope:

root@kali:~# nmap -sU -p67 --script broadcast-dhcp-discover
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-15 17:25 PDT
Pre-scan script results:
| broadcast-dhcp-discover:
|   IP Offered: 192.168.10.200
|   DHCP Message Type: DHCPOFFER
|   Subnet Mask: 255.255.255.0
|   Renewal Time Value: 0 days, 0:30:00
|   Rebinding Time Value: 0 days, 0:52:30
|   IP Address Lease Time: 0 days, 1:00:00
|   Server Identifier: 192.168.10.221
|   Router: 192.168.10.254
|   Domain Name Server: 127.0.0.1, 8.8.8.8, 208.67.222.222, 208.67.220.220
|_  Domain Name: pu.pri
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.22 seconds

In this example the Windows server doesn't have an available address in the scope:

root@kali:~# nmap -sU -p67 --script broadcast-dhcp-discover
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-15 20:35 PDT
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.27 seconds

No IP address was offered. But is it a wireless or a DHCP issue? Next we will run the NMAP DHCP-Discover script. This script doesn't use a DHCP Discover in a broadcast, it sends a DHCPINFORM in a unicast. Here are the results right after the broadcast script failed:

root@kali:~# nmap -sU -p67 --script dhcp-discover 192.168.10.221
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-15 21:40 PDT
Nmap scan report for 192.168.10.221
Host is up (0.00048s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover:
|   DHCP Message Type: DHCPACK
|   Server Identifier: 192.168.10.221
|   Subnet Mask: 255.255.255.0
|   Vendor Specific Information: \xDC\x03NAP
|   Router: 192.168.10.254
|   Domain Name Server: 127.0.0.1, 8.8.8.8, 208.67.222.222
|_  Domain Name: pu.pri
MAC Address: 00:0C:29:2C:23:E0 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds

So the DHCP server is up but no addresses are being offered. The NMAP man page for the script is here - dhcp-discover