Home & lab · Jan 2026, later fix · with Delivered A−

Whole-home mesh Wi-Fi and the double NAT trap

Picking a mesh system for a house with no wired backhaul, and the later bug where the network looked healthy while every connection timed out.

The problem

A roughly 1,900 sq ft house, no Ethernet runs, limited outlets, and a car in the garage that needs a decent signal to take updates. The ISP gateway's own Wi-Fi was fine in the room it sat in and nowhere else. I wanted whole-house coverage without drilling anything.

Choosing the mesh

With no wired backhaul, the mesh has to talk to itself over radio, and that is where most cheap kits fall down: if the same radio serves your devices and the link between units, throughput roughly halves with every hop. The deciding feature was a dedicated backhaul band. I went with the TP-Link Deco XE70, a tri-band Wi-Fi 6E system that reserves the 6 GHz band for the units to talk to each other, leaving 2.4 and 5 GHz for phones and laptops. I bought it, placed the units, and checked coverage against my targets, including the garage.

The sequel: two routers, one house

Because the gateway's Wi-Fi doesn't reach the house, the mesh took over wireless, and I plugged its main unit into the gateway. That quietly created a double NAT: the gateway was a router doing address translation, and so was the mesh behind it.

BEFORE                                   AFTER
Internet                                 Internet
  |                                        |
ISP gateway  <- router + NAT #1          ISP gateway  <- passthrough only
  |                                        |
Mesh main unit <- router + NAT #2        Mesh main unit <- the only router
  |                                        |
house devices                            house devices

It worked, mostly. Then one evening a VPN client wouldn't connect on a Mac or an iPhone. It looked like a certificate or VPN-service problem, and it wasn't.

The signature worth memorizing

Layer	Result
DNS lookups	work
Ping, any packet size	works
Traceroute	completes, normal latency
TCP connections to anything	time out

# is it really NAT? three quick tests
ping -c 3 1.1.1.1                        # works
traceroute -m 8 1.1.1.1                  # works
curl -m 8 -sI https://example.com        # times out

Pings fine but every TCP connection dead means a full NAT connection table. The usual symptom is an app that “can't connect” while the network looks healthy. Rebooting the router clears it. The VPN logs agreed: the client had died fetching an ordinary HTTPS credential, long before any tunnel negotiation started. Two NAT layers meant two tables that could fill, and the gateway's was the one that filled.

The fix: IP passthrough

Keep the mesh as the house's router and turn the gateway into a pipe. On the gateway:

Open its firewall settings and enable IP Passthrough, with the allocation mode set to passthrough and the DHCP-fixed mode.
Choose the mesh's main unit by its WAN MAC address, not a satellite and not the LAN-side address.
Save, then reboot the gateway first and wait for it to sync, then reboot the mesh.
Turn off the gateway's Wi-Fi radios so nothing competes with the mesh.

The mesh keeps its old private address until the lease expires, so it only picks up the public one after a reboot. If it still shows a private address after that, the wrong MAC was selected.

curl -s https://api.ipify.org; echo     # your public address
traceroute -w1 -q1 -m5 8.8.8.8           # the old gateway should NOT appear as hop 1

A reminder that tripped me up: only 10.x, 172.16–172.31 and 192.168.x are private. An address starting 172.2 is public, so don't dismiss it as internal.

Result

The mesh is the only router, the second NAT layer is gone, and coverage met the targets. I'm still keeping an eye on the router for the occasional restart, but the double NAT was a real, fixable cause and passthrough fixed it.

This is entry 01 of AI Lab Work.