When a customer router steals static IPs: containing ARP hijacks on an ISP edge

In October 2026, customer-owned routers on our Naivasha network started behaving badly on our shared edge. Some leaked their home-network addresses into our hotspot. One went further and began answering ARP requests for addresses it did not own, effectively stealing static IPs from other devices on the same segment, including infrastructure radios.

We contained the problem from the ISP edge, without touching customer equipment and without a service-wide outage. This post covers what we saw, why it happened, what we changed, how we checked it worked, and what we would do differently. Every investigation step began read-only, and every change was preceded by a configuration backup.

Customer impact: a small number of customers saw intermittent connection drops, usually until their device was re-admitted or a port was reset. There was no wider outage.

1. Our setup

Our Naivasha edge is a single MikroTik router running RouterOS 7. It serves three kinds of subscribers from one bridge:

• Static-IP customers on a private static LAN, behind a shared NAT
• Hotspot users who receive addresses by DHCP
• PPPoE subscribers on a separate address pool

A small public block serves customers who need real public addresses. A handful of infrastructure radios, an access point and a point-to-point link, sit on the same static LAN. We also rate-limit per IP address, so a given address is tied to a specific plan.

This design is simple and economical, and it has one property that matters here: devices with different levels of trust share a layer-2 segment. That is common among small ISPs, and it is why ARP behaviour at the edge matters.

2. What we saw

2.1 Customer routers leaking their home networks

The first sign was ghost entries in the hotspot host table. Hosts appeared with source addresses outside every range we serve: typical home-network ranges, link-local addresses, and occasionally public addresses.

When we dug into it, the cause was ordinary. Consumer routers that are not NATing properly send traffic out with their inside addresses. Our hotspot counts every source address it sees as a separate host for that device, and it only allows a small number per device. Once a leaking router has used up its allowance, its real address is refused and the customer drops offline until the entry expires or the port is reset.

The same thing happened to us. Our own management server, whose container network leaked internal addresses, hit the same limit. Resetting the port made it work again, but only because that flushes the host and ARP tables, so the fix hid the cause.

The scale was visible in the router's ARP table during our 10 October review: roughly 2,800 entries, of which over 1,600 were stale and around 900 had failed. One customer router appeared against nearly a thousand public addresses, and another against about eight hundred home-network addresses. In related DNS-leak cases, our edge router was even seen ARPing for public resolver addresses toward a customer router.

None of this was malicious. It was misconfigured customer equipment making noise on a shared segment.

2.2 A router that claims other devices' addresses (28–30 October)

Then one consumer-grade router began claiming addresses on our static LAN that belonged to other devices, including our two infrastructure radios. The behaviour looked like this:

• The same hardware address appeared on the static LAN and, at the same time, on the hotspot range.
• ARP entries for static addresses flipped between the legitimate owner and this device.
• Infrastructure radios intermittently became unreachable on their own addresses, because the edge was sometimes resolving them to the wrong hardware address.

The device also moved between addresses on the static LAN, so blocking one address would not have helped. Because our rate limits are per address, a stolen address also inherits that address's plan, which is one more reason this behaviour matters.

3. Containment

We made two changes, in this order. Each was preceded by a full configuration backup so it could be undone in one step.

3.1 Source guards on the bridge (28 October)

We added bridge filter rules on the input path for IPv4 that accept only source addresses from the ranges we actually serve (the static LAN, the hotspot pool, the PPPoE pool, the public block, and the DHCP "unspecified" source). Everything else is dropped.

Result: ghost hosts with foreign source addresses stopped appearing as valid hotspot clients.

3.2 Blocking the offending device at layer 2 (30 October)

A single-address block would not have worked, because the device moved between addresses. We blocked it by hardware address instead, with a small set of bridge filter rules that match the device's MAC and drop its frames on the input path.

One detail is worth sharing. The matching rules on the forward path stayed at zero hits while the input path counters climbed. The hostile traffic was reaching the router itself first. Had we written only forward rules, the block would have looked correct and done nothing.

3.3 Why a one-MAC block is not enough

Blocking one device is a patch, not a defence. Consumer routers get replaced, reset, or have their MAC changed, and the next customer device can misbehave in the same way. We treat the block as a way to buy time and the source guard as the structural fix. We also built a known-clients allow-list in log-only mode, which shows what a stricter policy would drop before it drops anything.

4. How we checked it worked

We used signals that did not depend on the customer or on access to the customer's router:

1. Packet counters on the input-path drop rules climbed steadily over hours and days, confirming the device kept trying.
2. Contested ARP entries for that hardware address in the static range moved to a failed state.
3. Infrastructure radios became reachable again on their own hardware addresses.
4. No credentials involved: the containment did not require logging in to the customer's equipment.

5. Lessons

• Shared layer-2 segments need guards at the edge. If different trust levels share a bridge, assume some device will eventually answer for an address it does not own.
• A reset that "fixes" something may only hide it. Flushing ARP and host tables cleared our symptom each time, but the cause kept coming back until we addressed the leaking sources.
• Check which path your rule sits on. Input-path and forward-path counters tell different stories. Read both before concluding a block works.
• Block structurally, not by device. MAC blocks buy time. Source guards and allow-lists remove the whole class of problem.
• Back up, change, then verify with counters. Every change here had a one-line undo and an observable signal of success.
• Prefer log-only first. A stricter policy in log mode shows its effect before it affects a customer.
• Evidence is only as good as your logging. During our review, one misbehaving router retrying every couple of seconds had pushed everything older than about an hour out of the edge router's in-memory log. Persistent, off-box logging is on our list.

We are also tightening how critical infrastructure addresses are protected on this segment, and we will share the results in a follow-up once they are in place.