How to Check If a Mesh Wi-Fi Satellite Uses the VPN Router
Trace the default gateway, the node's forwarding mode and the router's state table to prove whether a mesh satellite's clients ride the VPN.
A satellite that answers to the same Wi-Fi name as the base router tells you almost nothing about where its clients' packets go. The node is a radio and a bridge until proven otherwise. What decides the exit is the default gateway each client receives and the forwarding mode of the node in front of it. Run these five checks from the client outward and you will have an answer you can defend, rather than an impression from a speed test.
Read the gateway the client actually got
On the client, print the route table and the neighbor table. The default route names the address that forwards traffic; the neighbor entry names the MAC that owns that address. Use the client, not the router's device list, because a device list shows associations rather than paths.
ip route show default
ip -6 route show default
ip neigh showWindows prints the same facts in a different shape: ipconfig /all gives the default gateway and arp -a gives the MAC. On macOS, route -n get default and arp -an cover the same ground.
Compare that gateway with two addresses you already know: the base router's LAN address and the satellite's management address. If the gateway is the router's LAN address, the client is bridged to the router and the router's policy for that LAN applies unchanged. If the gateway is the satellite's address, the satellite is routing, and the router never sees the client's packets as LAN traffic; the decision has to happen on the node or it does not happen.
Confirm which mode the node is really in
Mesh products reuse three words for different behaviour, so trust the packet path over the label in the app. Bridge or access-point mode forwards frames. Router mode terminates a subnet and runs DHCP. Guest mode usually parks clients on a separate VLAN with its own rules. A node in router mode behind another router is a double NAT, and its clients arrive at the VPN router already translated, which defeats policy that matches on source address.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
To pin the MAC, read the label on the node and compare it with ip neigh. Vendors print the base MAC and derive the per-radio MACs by incrementing a byte, so the last hex digit differs; match the prefix rather than the whole address. If the gateway MAC belongs to the router's LAN interface, the node is not routing for that client.
Prove the exit on the router, not with a speed test
Router-side state is the only place that shows the translation. On OpenWrt, list the policy rules and routing tables, then confirm the tunnel has a recent handshake:
ip rule show
ip route show table all | grep default
wg showOn pfSense or OPNsense the same evidence lives in pfctl -sr for rules, pfctl -ss for live states, and the WireGuard status page for peer counters, following the WireGuard client documentation. Filter the state table by the client's address. If the state shows the client translated to the tunnel address, the traffic is inside the tunnel; if it shows the WAN address, it is not, whatever the dashboard badge says.
A traceroute from the client adds one fact the state table cannot: the first hop. If the first hop is the router's LAN address, the client reached the router directly. If it is the node's address followed by another private hop, you are on a routed segment, and that second hop is the device that must hold the policy.
Check what the node hands out besides an address
DHCP options travel with the lease, so a node that serves its own DHCP can also serve its own DNS and its own IPv6 router advertisements. A client can therefore egress through the tunnel and still send queries to a resolver on the node, or pick up a global IPv6 address the tunnel policy never covers. Print both on the client:
cat /etc/resolv.conf
ip -6 addr show scope globalIf the resolver is the node and the node forwards to the router, DNS follows the tunnel. If the node resolves locally or points at the ISP resolver, queries leave outside the tunnel even when HTTP does not. IPv6 deserves the same test: a global address plus a default route that bypasses the tunnel is a leak, and mesh firmware often leaves IPv6 on while the VPN policy only covers IPv4.
Break the tunnel on purpose, then write the result down
Take the tunnel down and watch a client associated with that node, not a client sitting next to the router. ping and a short-timeout curl are enough; the question is whether traffic stops or falls back to the WAN. Stop the tunnel with the router's own service command, for example wg-quick down wg0 or the OpenVPN service stop, and keep the test short.
If the client keeps working, the node or the router is failing open for that segment, and the mesh has quietly undone the kill switch. Bring the tunnel back, confirm the handshake counter moved, and repeat the state-table check from the third step.
Record one row per node: label, SSID, gateway address, MAC prefix, exit confirmed yes or no, IPv6 covered, and behaviour with the tunnel down. Roaming is where the answer changes, so test the rooms you actually use. When one row disagrees with the rest, that node is the one to investigate, and the fix belongs on whichever device owns that row's gateway.