Connections slow to a crawl, the odd TLS certificate warning appears, and traffic that should go to the router is quietly flowing through a laptop in the corner. Nothing is “down.” A device on the LAN has simply announced — with no proof required — that it is the default gateway, and everyone believed it. This is ARP spoofing, and the same mechanism causes the accidental version: the duplicate IP.
ARP is how a device turns an IP address into the MAC address it actually sends frames to. It works on trust: a host asks “who has 10.0.0.1?”, something answers “I do, at this MAC”, and the asker caches it — with no authentication whatsoever. Worse, most stacks accept an unsolicited (“gratuitous”) ARP reply and overwrite their cache with it, no question asked.
So any device on the segment can announce that it holds the gateway’s IP, and every host that hears it will send its off-subnet traffic to that device instead of the router. Done maliciously, that is a man-in-the-middle: the attacker relays (and reads, or alters) everything. Done by accident — two devices with the same IP, a mis-cloned VM — it is a duplicate-IP black hole where traffic flips between two MACs. Same unauthenticated mechanism, two faces.
01
The attacker announces “the gateway is at my MAC.” The victim’s ARP cache updates, and its traffic now flows to the attacker — who relays it on so nothing looks broken.
Because the attacker relays the traffic onward to the real gateway, connectivity still works — just slower, through an extra hop that can read or tamper with everything not independently encrypted. The accidental version (duplicate IP) is messier: two devices answer for the same address, switches learn the MAC on different ports in turn, and traffic flaps between them — intermittent for everyone, not a clean MITM.
02
Three ARP facts combine: no authentication, caches accept unsolicited replies, and the most recent answer wins.
| ARP behaviour | Why it enables this |
|---|---|
| No authentication | Any host can answer for any IP. Nothing proves the claim. |
| Gratuitous ARP accepted | Most stacks update the cache from an unsolicited reply — the attacker does not even need to be asked. |
| Last answer wins | The attacker just has to answer more often than the gateway; the newest mapping overwrites the real one. |
| One flat broadcast domain | Everyone hears everyone’s ARP. A big flat LAN is a big blast radius — another reason to segment. |
03
Subtle for the MITM, noisy for the duplicate IP — both show up in the ARP table.
| What you see | What it tells you |
|---|---|
| The gateway’s MAC in your ARP table changed | Something else is answering for .1 — spoof or misconfig. |
| Intermittent slowness, odd TLS warnings | Traffic detouring through a MITM that is re-terminating or tampering. |
| OS “duplicate IP address” warnings | Two devices claim one IP — the accidental black hole. |
| Two IPs mapping to the same MAC | A device impersonating several hosts (classic spoofing tool behaviour). |
04
Dynamic ARP Inspection validates every ARP against the DHCP-snooping database and drops the lies at the port they enter.
Dynamic ARP Inspection (DAI) builds on DHCP snooping: the switch knows which IP legitimately belongs to which MAC on which port (from the snooping database), and drops any ARP that contradicts it — before it ever reaches a victim. For the handful of static servers that do not use DHCP, add explicit ARP-to-port bindings. On the hosts that matter most, a static ARP entry for the gateway is cheap insurance.
! Cisco: DAI on the user VLAN, trusting only the uplink ip dhcp snooping ip dhcp snooping vlan 20 ip arp inspection vlan 20 interface Gi1/0/48 ip dhcp snooping trust ip arp inspection trust # RouterOS: pin the gateway ARP and reply only from static on sensitive bridges /ip arp add address=10.20.20.1 mac-address=AA:BB:CC:DD:EE:01 interface=v20-guest /interface bridge set v20-bridge arp=reply-only
DAI is only as good as the DHCP-snooping bindings behind it. If snooping is not configured, or static hosts are not bound, DAI either drops legitimate traffic or has nothing to validate against. And arp=reply-only on RouterOS means every legitimate host on that bridge needs a static ARP entry — powerful for a server VLAN, maintenance-heavy for a user one. Match the control to the segment.
05
The ARP table is the witness: watch the gateway’s MAC, and watch for one MAC claiming many IPs.
# RouterOS: has the gateway MAC changed? is one MAC claiming many IPs? /ip arp print # host side: note the gateway MAC when healthy, compare when it misbehaves ip neigh show | grep -w 10.20.20.1 # watch for changes over time (the spoof is a moving target) sudo arpwatch -i eth0 # logs “flip flop” / changed ethernet address
If the gateway’s MAC does not match the router’s real MAC — or one MAC is suddenly answering for several IPs — you have a spoof or a duplicate. Turn on DHCP snooping and DAI, and the switch stops believing anyone but the real owner.
Takeaways
reply-only on server bridges, are cheap insurance.ARP has no authentication, so one device can speak for the whole subnet. I lock the LAN down with DHCP snooping and Dynamic ARP Inspection so only the real gateway can claim to be the gateway.
Book a Discovery Call →