You walk in Monday morning. Coffee in hand. Users are already in the ticket queue screaming:
«Internet is down», «My PC got a weird IP address», «The gateway is 192.168.0.1 instead of our 10.10.0.1».
Congratulations — you have a rogue DHCP server on your network.
It could be an employee’s home router plugged into the office switch, a forgotten dev VM, a misconfigured access point, or even a printer with DHCP accidentally enabled.
One rogue device is enough to trigger a full-blown network apocalypse — faster than you can finish your coffee.
In this guide we’ll cover:
- What a rogue DHCP server actually is and why it’s so dangerous
- How DHCP options work and which ones matter most
- What DHCP Option 43 and DHCP Option 82 are
- How to deploy DHCP Snooping to prevent rogue servers at the switch level
- How to instantly detect any rogue server using the free DHCPScan utility
After reading this article, you’ll have a practical toolkit to find and eliminate rogue DHCP servers before your users even notice something is wrong.
What Is a Rogue DHCP Server?
A rogue DHCP server is any DHCP server operating on your network that you didn’t authorize.
It’s not necessarily malicious — in most cases it’s just an accident. But the damage it causes is very real.
Typical sources of rogue DHCP servers:
- An employee’s home router accidentally connected to the corporate LAN
- A developer’s virtual machine with a DHCP server role enabled by default (VMware, VirtualBox, Hyper-V)
- A misconfigured server or network appliance
- A test lab or staging environment left running
- A Wi-Fi access point in AP+Router mode
- A network printer or IP camera with an embedded DHCP server
The core problem is how DHCP works: the client takes the first DHCP Offer it receives.
If the rogue server responds faster than your legitimate one — every new device on the network gets the wrong IP, wrong gateway, wrong DNS.
Everything breaks. And the logs look completely clean.
How DHCP Works (In Two Minutes)
When a device connects to a network and needs an IP address, it broadcasts a DHCP Discover packet.
Every DHCP server on the network receives it and responds with a DHCP Offer — here’s your address, gateway, DNS, and lease time.
The client accepts the first offer and sends a DHCP Request. The server confirms with a DHCP Ack.
This four-step process (Discover → Offer → Request → Ack) is called DORA.
The problem: there is no built-in authentication. Any device on the same broadcast domain can pretend to be a DHCP server.
DHCP Options: What the Server Sends Along With the IP
The IP address is just the beginning. DHCP servers pass a lot of additional configuration through DHCP options — numbered parameters embedded in the DHCP packet.
Most common DHCP options:
| Option | Name | Description |
|---|---|---|
| 1 | Subnet Mask | Network mask |
| 3 | Router (Gateway) | Default gateway IP |
| 6 | DNS Servers | DNS resolver addresses |
| 15 | Domain Name | Domain suffix for host lookup |
| 42 | NTP Servers | Time synchronization servers |
| 43 | Vendor-Specific Info | Vendor-specific parameters (Cisco, VoIP, AP) |
| 51 | Lease Time | How long the IP assignment is valid |
| 82 | Relay Agent Info | Switch port and VLAN info added by relay agent |
When a rogue server appears, it doesn’t just hand out wrong IP addresses — it can also push wrong DNS servers (hello, DNS poisoning), a wrong gateway (hello, traffic interception), or garbage vendor options that break your VoIP phones and Wi-Fi access points.
DHCP Option 43: The Cisco Option (and Why It Matters)
DHCP Option 43 is the vendor-specific information option.
It’s most heavily used in enterprise environments by:
- Cisco Wi-Fi access points (to find their wireless controller)
- VoIP phones (to find the call manager)
- IP cameras and other managed devices
For example, a Cisco Access Point uses Cisco DHCP Option 43 to automatically discover the IP address of the Wireless LAN Controller (WLC).
If a rogue DHCP server sends a wrong or missing Option 43 — the AP simply won’t connect to the controller. Your entire Wi-Fi goes dark.
Example: Cisco DHCP Option 43 configuration (IOS)
ip dhcp pool WIFI
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server 8.8.8.8
option 43 hex f1040a0a0a0a
Decoding the hex value:
- f1 — Cisco sub-option code (type 241)
- 04 — length (4 bytes = one IPv4 address)
- 0a0a0a0a — controller IP address (10.10.10.10 in hex)
If you’ve ever had Access Points randomly drop off the controller for no apparent reason — check what Option 43 is being delivered to them.
A rogue server sending garbage here is a classic culprit.
DHCP Option 82: Relay Agent Information
DHCP Option 82 is added by the network switch (specifically, by the DHCP relay agent) when forwarding DHCP requests to the server.
It’s formally called Relay Agent Information.
What Option 82 contains:
- The switch port the DHCP request arrived on
- The VLAN ID
- The switch identifier (MAC or hostname)
Why this is useful:
- Track exactly which physical port a device is plugged into
- Apply per-port or per-VLAN DHCP policies
- Detect anomalies: if Option 82 says «port 12» but the device claims to be a server — something is wrong
- Essential for forensic investigation after a rogue DHCP incident
If your DHCP server logs show Option 82 data pointing to an unexpected port or VLAN — that’s your first clue that something unauthorized is running.
DHCP Snooping: How to Block Rogue DHCP Servers at the Switch Level
The right long-term fix for rogue DHCP is not just detection — it’s prevention.
And the industry-standard tool for this is DHCP Snooping.
DHCP Snooping is a Layer 2 security feature available on most managed switches (Cisco, HP/Aruba, Juniper, MikroTik, etc.).
The switch inspects all DHCP traffic and enforces a simple rule:
DHCP Offer packets are only allowed from trusted ports. Any DHCP Offer arriving on an untrusted port is silently dropped.
How it works:
- Trusted ports — uplinks to your core network, ports where legitimate DHCP servers or relay agents are connected
- Untrusted ports — all end-user device ports (workstations, printers, phones)
An employee plugs in their home TP-Link? The switch sees a DHCP Offer on an untrusted port and drops it immediately.
The employee’s devices get the correct IP. Nobody notices. Problem solved before it started.
Configuring DHCP Snooping on Cisco IOS
! Enable DHCP Snooping globally
ip dhcp snooping
! Enable on specific VLAN
ip dhcp snooping vlan 10
! Mark uplink/server port as trusted
interface GigabitEthernet0/1
ip dhcp snooping trust
! All other ports are untrusted by default
! Optional: limit DHCP request rate on untrusted ports
interface GigabitEthernet0/2
ip dhcp snooping limit rate 15
Verifying DHCP Snooping Status
show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping statistics
The show ip dhcp snooping binding command shows every IP-to-MAC-to-port binding the switch has learned — an invaluable table for tracking down any device on your network.
MikroTik DHCP Options Configuration
MikroTik RouterOS gives you very granular control over DHCP options.
Here’s how to configure the most common ones:
Option 42 — NTP Server
/ip dhcp-server option
add name=ntp-server option=42 value=0xC0A80101
# 0xC0A80101 = 192.168.1.1 in hex
/ip dhcp-server network
set [find] dhcp-option=ntp-server
Option 43 — VoIP / Vendor Specific
/ip dhcp-server option
add name=voip-server option=43 value=0x0104C0A8010A
# Points VoIP phones to 192.168.1.10
/ip dhcp-server network
set [find] dhcp-option=voip-server
Option 66 — TFTP Boot Server (for IP phones and thin clients)
/ip dhcp-server option
add name=tftp-server option=66 value="'192.168.1.50'"
/ip dhcp-server network
set [find] dhcp-option=tftp-server
MikroTik also supports DHCP Snooping-equivalent functionality through its bridge firewall — you can block DHCP server packets on specific bridge ports to achieve the same effect as Cisco DHCP Snooping.
DHCPScan: Find a Rogue DHCP Server in 10 Seconds
Theory is great. But when the network is on fire at 9 AM, you need a tool.
To solve this exact problem, we built a small utility called DHCPScan.
What DHCPScan does:
- Sends a DHCP Discover broadcast
- Collects all DHCP Offer responses (not just the first one)
- Displays all responding DHCP servers
- Parses and decodes all received DHCP options
- Flags any unexpected server as a potential rogue DHCP server
For each responding server, DHCPScan shows:
- DHCP server IP address
- Offered client IP address
- DNS servers (Option 6)
- Gateway (Option 3)
- Lease time (Option 51)
- NTP server (Option 42)
- Vendor class identifier (Option 60)
- Boot server (Option 66/67)
- Raw DHCP options dump
This turns «rogue DHCP hunting» from a 2-hour network detective story into a 10-second task.
⬇ Download DHCPScan
5 Real-World Rogue DHCP Cases (Solved with DHCPScan)
Case 1: The Employee’s Home Router
A user brought in their TP-Link home router and plugged it into the office network to «boost the signal».
Within minutes, half the floor had IP addresses in the 192.168.0.x range with a 192.168.0.1 gateway.
DHCPScan revealed the second DHCP server in under 30 seconds.
Culprit found. Router unplugged. Network restored.
Case 2: The Developer’s VMware VM
A developer spun up a test environment in VMware. VMware’s default network configuration automatically enables a DHCP server on the virtual network adapter.
DHCPScan caught it immediately — the vendor class identifier field gave it away as a VMware virtual NIC.
The VM was isolated to a host-only network within minutes.
Case 3: Wrong Cisco DHCP Option 43
Access Points across one floor suddenly stopped connecting to the Wireless LAN Controller.
DHCPScan showed that Option 43 was being delivered with an incorrect controller IP — someone had modified the DHCP pool on a test switch.
Corrected the option. Wi-Fi came back up.
Case 4: Misconfigured DHCP Relay
DHCP Option 82 in the server logs was showing the wrong switch port — devices on VLAN 20 were being identified as coming from VLAN 10.
Investigation revealed the DHCP relay was configured on the wrong interface.
Fixed the relay configuration. Option 82 data normalized.
Case 5: The Admin’s «Test» Server
A classic. A senior admin spun up a test DHCP server to try a new configuration. Then got pulled into a meeting. Then forgot about it entirely.
DHCPScan instantly showed two servers responding to DHCP Discover.
When confronted, the admin confidently described it as «planned infrastructure testing».
Sure. We’ve all been there.
Possible Side Effects: Common Mistakes to Avoid
Mistake 1: Trusting the Wrong Port
If you mark an end-user port as «trusted» in DHCP Snooping, any device on that port can act as a DHCP server.
Always double-check your trusted port assignments. Only uplinks and known server ports should be trusted.
Mistake 2: Forgetting to Enable DHCP Snooping on All VLANs
ip dhcp snooping vlan 10 only protects VLAN 10. If your network has VLANs 10, 20, 30, 40 — you need to enable it on all of them.
Use a range: ip dhcp snooping vlan 10-40.
Mistake 3: Option 82 Causing DHCP Failures
Some DHCP servers drop requests with Option 82 if they’re not configured to handle it.
If enabling DHCP Snooping breaks your DHCP, check whether your server is rejecting Option 82.
On Cisco IOS, you can disable Option 82 insertion: no ip dhcp snooping information option.
Mistake 4: Running DHCPScan Without Proper Permissions
DHCPScan needs to send and receive raw packets at Layer 2. On Linux, this typically requires root or CAP_NET_RAW capability.
On Windows, you may need to run as Administrator. Don’t run it from inside a VM without bridged networking — you won’t see the full picture.
Mistake 5: Only Checking Once
Rogue DHCP servers can appear and disappear — especially in environments with laptops and mobile devices.
Consider scheduling periodic automated checks, or configure DHCP Snooping as a permanent control.
Prevention and Best Practices
Once you’ve dealt with a rogue DHCP incident, take these steps to prevent the next one:
- Enable DHCP Snooping on all managed switches — this is the single most effective preventive measure.
If your switches support it (Cisco, Aruba, Juniper, Huawei — they all do), there’s no excuse not to use it. - Audit DHCP server logs regularly — look for unexpected MAC addresses receiving leases, or unusual lease patterns.
- Use 802.1X port authentication — prevents unauthorized devices from connecting to the network in the first place.
No connection = no rogue DHCP. - Document your DHCP architecture — know exactly which servers should be responding in each VLAN.
When DHCPScan shows two servers, you need to know which one is wrong. - Train your team — most rogue DHCP incidents are accidental.
Make sure developers know not to bridge their test VMs to the production network.
Make sure the helpdesk knows not to plug in random networking gear. - Run DHCPScan as part of your network onboarding checklist — whenever you add a new network segment or bring up a new switch, run a scan.
Quick Reference: DHCP Security Checklist
| Action | Priority | Tool / Method |
|---|---|---|
| Enable DHCP Snooping on all switches | 🔴 Critical | Cisco IOS / Aruba / Juniper CLI |
| Verify trusted port assignments | 🔴 Critical | show ip dhcp snooping |
| Scan for rogue DHCP servers | 🟠 High | DHCPScan utility |
| Audit DHCP Option 43 delivery | 🟠 High | DHCPScan, Wireshark |
| Monitor DHCP Option 82 data | 🟡 Medium | DHCP server logs |
| Implement 802.1X authentication | 🟡 Medium | RADIUS + managed switches |
| Schedule periodic DHCPScan sweeps | 🟢 Recommended | Cron / Task Scheduler |
Conclusion: Your Network Deserves Better Than DHCP Roulette
A rogue DHCP server is one of those problems that looks completely mysterious until you have the right tools —
and completely obvious once you do.
Wrong gateways, weird IPs, broken Wi-Fi, VoIP phones that won’t register —
all of this can trace back to a single unauthorized DHCP response from a home router someone plugged in without thinking.
The fix isn’t complicated:
- Deploy DHCP Snooping — block rogue servers at the switch level, permanently
- Understand your DHCP options — especially Option 43 and Option 82 in enterprise environments
- Use DHCPScan to get an instant picture of who’s answering DHCP requests on your network
With these three things in place, rogue DHCP servers get caught before users even open a support ticket.
And you get to finish your coffee in peace.
⬇ Download DHCPScan — free utility for detecting rogue DHCP servers
Found a rogue server with an interesting story? Drop it in the comments — we read every one.
And if this saved your network today, share it with your team. Someone out there is dealing with the same problem right now.
Subscribe to our Telegram channel for more hands-on sysadmin guides and network tools.
Author: over_dude
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
