Understanding the Symptoms
When two DHCP servers operate on the same subnet, clients may receive conflicting lease information. The most common symptom is that devices obtain an IP address from the primary router but then lose connectivity shortly after. You might notice that some devices receive addresses outside the configured scope of your main server, or that lease times are inconsistent across different machines. In severe cases, devices will display "Limited or no connectivity" in their network status because they cannot reach the default gateway assigned by the secondary source.
This behavior occurs because DHCP clients accept the first offer they receive. If a rogue server responds faster than the legitimate one, the client binds to that incorrect configuration. Over time, this leads to fragmentation in your network where some devices are properly routed while others are isolated or misconfigured. Identifying which device is broadcasting these rogue offers is the critical first step in remediation.
Checking Connected Devices
The simplest method to find a duplicate server is to inspect every device currently connected to your network. Log into your primary DHCP server’s administrative interface and review the list of active leases. Compare the MAC addresses and hostnames against known hardware. If you see devices with unknown names or MAC addresses that do not correspond to any registered asset, investigate those specific endpoints. Often, a misconfigured access point, a home router plugged into a LAN port, or a developer machine running software like dnsmasq or IIS DHCP services can act as the rogue server.
Detecting Rogue Servers via Packet Capture
If physical inspection does not reveal the culprit, use packet analysis tools to trace the source of DHCP offers. On Linux systems, tcpdump or wireshark are effective utilities for this purpose. You need to filter for DHCP traffic specifically to reduce noise. Run the following command on a machine connected to the same broadcast domain:
sudo tcpdump -i any port 67 or port 68 -vLook for DHCPACK or DHCPOFFER packets. Examine the siaddr (Server Identifier) field in the captured packets. This IP address belongs to the server sending the response. Once you have identified the IP address of the rogue server, you can locate it on your network by pinging it or checking its ARP table on your primary router. If you are using Windows, Wireshark provides a graphical interface where you can apply the filter bootp to achieve similar results.
Resolving the Issue on Linux Systems
Many Linux distributions run lightweight DHCP servers for development or testing purposes. Services like isc-dhcp-server, dnsmasq, or systemd-networkd can inadvertently start if not properly disabled. Check for running services using systemctl:
systemctl list-units --type=service | grep dhcpIf you find an unexpected service, stop it immediately with sudo systemctl stop [service-name] and disable it from starting at boot with sudo systemctl disable [service-name]. Additionally, check for static configurations in files like /etc/dhcpcd.conf or /etc/network/interfaces that might be triggering local DHCP responses. Ensure that only the intended network interfaces are configured to listen for DHCP requests.
Resolving the Issue on Windows Systems
Windows Server environments include the DHCP Server role, which is powerful but often left enabled on workstations by mistake. Open the Server Manager and navigate to the DHCP section. If you see scopes defined on a non-server machine, this is likely the source of the conflict. Right-click the DHCP node and select "Deactivate" to stop the service. Alternatively, open the Services console (services.msc) and look for the DHCP Client or DHCP Server services. Set their startup type to Disabled if they are not required for your workflow.
For personal computers, ensure that no third-party networking tools are installed that might provide DHCP functionality. Some virtualization software, such as Hyper-V or VMware, creates virtual switches that can sometimes interfere with physical network DHCP processes. If you are managing a complex environment with multiple operating systems, consider implementing DHCP snooping on your managed switches to prevent unauthorized servers from responding to client requests. This feature ensures that only ports trusted by your network infrastructure can send DHCP replies.
After disabling the rogue service, renew the IP addresses on affected clients by releasing and renewing their leases. On Windows, use ipconfig /release followed by ipconfig /renew. On Linux, restart the network manager or use dhclient -r and dhclient. Verify that all devices now receive addresses from the correct subnet and that connectivity is stable.
Frequently Asked Questions
How can I tell if my router is the source of the conflict?
If your router’s IP address matches the siaddr seen in packet captures, it is the legitimate server. However, if you see two different IPs offering addresses, one is definitely rogue. Check if you have another router connected via LAN-to-LAN that is set to act as a DHCP server instead of an access point.
Can a smart TV or IoT device cause DHCP conflicts?
Yes, certain smart devices or media players may have built-in DHCP client bugs or misconfigurations that cause them to request addresses aggressively. While rare, some IoT hubs can act as mini-servers. Isolate these devices by disconnecting them one by one to see if the rogue offers cease.
What is DHCP snooping and do I need it?
DHCP snooping is a security feature on managed switches that blocks DHCP messages from untrusted ports. It is highly recommended for enterprise networks to prevent rogue server attacks. For small home or office networks, simply ensuring no unauthorized devices are plugged in is usually sufficient.
Why do some devices still get wrong IPs after I stopped the rogue server?
Clients cache their DHCP leases. Even after the rogue server is gone, existing leases remain valid until they expire. You must manually renew the leases on affected clients or wait for the lease timer to expire naturally for them to fetch new, correct addresses.
Is it safe to block DHCP ports on my firewall?
Blocking UDP ports 67 and 68 on your internal firewall is generally not recommended unless you are segmenting networks. Doing so will prevent all DHCP communication, leaving your devices unable to obtain IP addresses automatically. Instead, focus on identifying and disabling the rogue service.