Two days, one ER605: when the router claims your traffic as its own

Ever had a router decide it knows better than you? Mine did it twice, two days in a row.

Two outages on two consecutive days, on the same TP-Link Omada ER605 v2, looked completely unrelated. On day one a single wired laptop could not reach its own gateway. On day two the whole network lost 1.1.1.1 and 8.8.8.8, while every other address worked.

Both had the same shape underneath: the router treated something as its own and quietly took traffic away from the LAN because of it. Neither was a vendor bug in the usual sense, and neither showed up in any status page. This post is the debugging log, with the tests that actually split the problem in half.

The setup

A homelab-sized network, all managed from a self-hosted Omada Controller. Addresses, MACs and hostnames below are anonymized.

WAN2 is meant to be a pure failover link. When I set it up, the controller would not let me save Link Backup without also filling in load-balancing weights, so it got 100000 : 0 with WAN1 as primary. Day 2 suggests those weights did not keep all traffic off WAN2.

Day 1: one laptop can't see its gateway

Right after a firmware update on the ER605, the laptop lost the gateway on its wired connection. Everything else on the network was fine, including the same laptop over Wi-Fi.

The symptoms were oddly specific:

• Link up at 1 Gb/s, and pings to other LAN hosts (the DNS server, the controller) worked.
• Ping to 192.168.10.1 timed out, and the ARP entry for the gateway stayed Incomplete.
• ipconfig /renew failed with "unable to contact your DHCP server".
• Plugging the laptop straight into a LAN port on the router, skipping the switch, changed nothing.
• The controller listed the laptop as a connected wired client.

That last point is a trap. "Connected" in Omada means the switch sees the MAC on a port. It says nothing about whether the router answers it.

Looking at the wire

Windows ships a packet capture tool, pktmon, so no Wireshark install was needed. With Wi-Fi off, I captured ARP and DHCP during a ping and a renew:

pktmon filter add ARP -d ARP
pktmon filter add DHCP -t UDP -p 67 68
pktmon start --capture --pkt-size 0 --file-name eth.etl
ping -n 4 192.168.10.1
ipconfig /renew "Ethernet 3"
pktmon stop
pktmon etl2txt eth.etl --out eth.txt

In 34 seconds the laptop sent 37 ARP requests for the gateway and got zero replies. Its DHCP broadcasts got no offer either. Broadcast ARP requests from the router did reach the laptop, and ARP with other hosts worked both ways, so the cable, the hub and the driver were fine.

The other direction was covered by the controller: it kept logging DHCP allocations for the laptop's MAC during the outage. The router was receiving the requests. Its answers never arrived.

Dead ends

• Omada's Blocked clients list was empty, the gateway ACL was empty, and ARP inspection (DAI) was off.
• Blocking and unblocking the client in the controller, to force a fresh block list onto the router, did nothing.
• A different static IP on the same adapter still could not reach the gateway.

Then the cheap test that settled it: give the adapter a different MAC.

Set-NetAdapterAdvancedProperty -Name "Ethernet 3" -RegistryKeyword NetworkAddress -RegistryValue "020000000001"
Restart-NetAdapter -Name "Ethernet 3"
ipconfig /renew "Ethernet 3"

Instant DHCP lease, gateway ping at 1 ms. Same cable, same port, same IP range. An evening of packet captures, fixed by changing twelve hex digits. The router had a problem with that one MAC address.

Root cause: the WAN port was wearing the laptop's MAC

The answer was in Network Config → Internet → WAN1. The MAC address there was set to "Customize", and the custom value was the MAC of the laptop's USB Ethernet adapter.

That had been done long ago on purpose. My ISP binds the connection to a registered device MAC, and at some point the registered device became this adapter. I honestly don't remember how. My best guess is that it was the first thing plugged into the line when the connection was set up. The router has been impersonating it on the WAN side ever since. Identity theft, except I signed the paperwork myself.

So the router considered that MAC address its own. My best explanation is the direction of the replies. An ARP reply or a DHCP offer for the laptop is addressed to the laptop's MAC, which on this router is also its own WAN MAC, so the answer most likely never leaves through a LAN port.

That fits everything observed: requests logged, answers never seen. Every other device, and the laptop's Wi-Fi card with its different MAC, worked normally.

I don't know why this only broke after the firmware update. The clone had been there for a long time. My best guess is that newer firmware handles the duplicate address differently, but I have not confirmed that. TP-Link, if this changed on purpose, one line in the release notes would have saved me an evening.

The fix

Asking the ISP to register the router's own MAC would be cleaner, but whenever I swap hardware, cloning a MAC takes a minute, while the ISP route means writing in and waiting. The WAN MAC stays as it is, so the laptop gives way instead:

1. Keep a locally administered MAC on the adapter permanently (the 02: prefix marks it as locally assigned).
2. Move the DHCP reservation in Omada from the old MAC to the new one, so the laptop keeps its usual address.
3. Write the clone down in the WAN1 description in the controller, so the next person (me, in a year) knows that adapter must never come back with its factory MAC.

The setting lives in this Windows install. If the hub moves to another machine or the OS is reinstalled, the adapter falls back to its factory MAC and the problem returns.

Day 2: 1.1.1.1 and 8.8.8.8 vanish

The next day my uptime monitor reported Cloudflare and Google as down. Both of them, at the same time. Sure. The internet itself worked. Name resolution worked. But two specific public addresses were unreachable from everything on the LAN:

Since these were raw IPs, DNS could not be the culprit. The obvious suspects were the ISP's routing or something on the Proxmox side. Then a default ping from the router, sourced from the LAN, also failed, which ruled out Proxmox.

The test that split it

Omada's Network Tools let you ping from the gateway and pick the source interface. That turned out to be the key, because the two choices take different paths:

• Source = a WAN interface forces the packet out of that link and skips the load-balancing and policy decision.
• Source = the LAN interface makes the router route the packet like any client's traffic.

The fiber line was healthy. Traffic from the LAN was, at least partly, being sent out the LTE link, and the LTE link was not passing anything at that moment.

Root cause: the backup WAN's DNS servers

WAN2 had a valid IP. Its DNS server fields, set manually long ago, said 1.1.1.1 and 8.8.8.8. WAN1 used different resolvers.

Multi-WAN routers commonly route each link's DNS servers out of that same link, so queries to one ISP's resolver never leave through the other ISP. The side effect: those two addresses are reachable only through WAN2, for every device on the network, whether WAN2 is the active link or not. With the LTE modem not passing traffic, 1.1.1.1 and 8.8.8.8 were simply gone.

The router did notice the LTE link was down. The day before, Omada had raised a "WAN Online Detection" alert saying WAN2 was offline. That changed nothing, because the routes to WAN2's DNS servers apparently stay in place whether the link is up or not.

I confirmed it by experiment, not by reading the routing table. I changed WAN2's DNS servers to DNS4EU's public resolvers, which nothing else on my network uses (a stopgap: the LTE operator's own resolvers go in once the modem works again), and ran the same pings from the LAN interface again:

The uptime monitor went green within a minute.

It also explains an older symptom. Right after I first added the LTE backup, pings to 1.1.1.1 failed now and then while the gateway stayed reachable. Most likely that was the same pinned route, failing whenever the LTE link wobbled.

One thing I can't fully explain is the 50% loss to 9.9.9.9. Every other packet failing looks like round-robin across both WANs, which would mean the 100000 : 0 weights were not doing what I set them for. It disappeared with the DNS change, so I left the load-balancing settings alone for now. If it comes back, unticking "Application Optimized Routing" is my next test.

The LTE link itself still isn't passing traffic as I write this. The next step is mounting the modem outdoors, and only then a real failover test. Until that happens, the backup is a backup in name only. Right now it's a modem with a SIM card, doing an excellent impression of a paperweight.

What I'd check first next time

Both bugs were configuration I had set myself, years apart, and both only bit when something else changed. A short list for anyone running a dual-WAN Omada gateway:

Symptom, then first check

General habits

• Don't trust "Connected" in the controller. It reflects the switch's view, not the router's.
• Capture before guessing. On Windows, pktmon is built in and is enough to see whether ARP replies ever arrive.
• Ping from the router with an explicit source interface. A WAN-sourced ping tests the line; a LAN-sourced ping tests the routing decision.
• Give the backup WAN resolvers nothing else uses. The LTE operator's own resolvers fit best, since they only make sense over that link anyway.
• Test the failover for real. Unplug the primary link for a minute, watch traffic move to the backup, then plug it back in.

So, whose fault was it?

Mine, both times. The router did exactly what I had told it, years earlier, and I had forgotten I ever told it. Neither fix took more than five minutes. Finding them took two days.

If you've been bitten by something similar on Omada, or you know why that firmware update changed how the ER605 treats its own MAC, let me know in the comments :)