What a STUN Reply Reveals When the VPN Runs on the Router
A router tunnel address is not a browser's local address. Trace how each request is routed and translated before reading what a reflector reports.
When the tunnel lives on the router, the machine running the browser has no tunnel interface at all. Ask that machine for its local addresses and you get a private LAN address and a loopback, nothing that resembles a VPN address. Yet a STUN server on the far side can still report something meaningful about the path, and what it reports depends entirely on how that particular request was routed and translated.
That is the part worth slowing down for. "The browser does not own the VPN address" answers a question about interfaces, while a reflected address is an answer about a path through translation. Conflating the two produces confident conclusions about disclosure that the evidence does not support.
Two devices, two sets of interfaces
In a router-based setup the tunnel terminates on the router and the LAN client sends ordinary traffic to its default gateway. The client's interface list stays short: one private address, maybe a second for another network, and loopback. The risk is not that one of those happens to be the tunnel address; it is that the request leaves through a path you did not choose.
Ask the client which route a specific destination would take instead of asking which interfaces exist. The answer names a gateway and the source address the kernel would use, which is already more informative than any inventory of addresses.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDocumentation ranges make good test destinations because they never resolve to a real service. Compare what the client says with what the router says, and treat any disagreement as evidence that policy routing, a split-tunnel rule or a second default route is doing something you have not accounted for.
What a Binding response is allowed to say
RFC 8489 defines the Binding request and response, where the server reports the source transport address it observed for that request. It is a statement about one five-tuple at one moment, not a census of the client's interfaces. Everything interesting therefore happens between the client and the point of observation.
That gap is filled by routing and translation. A router that source-NATs outbound traffic replaces the client's private source with its own address on the outgoing interface. If that interface is the tunnel, the reflector sees the tunnel address. If the packet was excluded from the tunnel, the reflector sees whatever the WAN translation produced. Same client, same reflector, different answer.
Three cases that look alike and are not
The useful distinction is not public versus private but which enforcement point handled the packet. Work the cases with the router's own tables open, because one browser can produce all three depending on a rule you forgot you wrote.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Only the second case breaks a requirement that some traffic never leave directly, and only the first and third disclose a tunnel-side identifier. None of the three rows is a claim about a particular provider's behaviour: whether a private reflector is reachable at all depends on routing, peer allowed-ips and firewall policy at both ends.
Holding an account with the same provider establishes none of that. It is also worth remembering that a routed request can keep the client's LAN source if nothing translates it, so the source field has to be traced rather than assumed from the topology diagram.
Gathering is not selecting
WebRTC collects candidate addresses to try, and a candidate that appears in a diagnostic list may never carry media. Reading the list as "this is what the peer learned" overstates the evidence. The selected pair is what actually carried the session, and it lives in a different field.
An HTTPS exit checker answers yet another question: the source address a web server saw for that request. It is a useful cross-check precisely because it uses a different protocol and often a different destination than a UDP reflector, and disagreement between the two usually points at a routing rule rather than at a bug.
Decide the policy, then read the answer
Write down the intent before testing: which traffic must use the tunnel, which may leave directly, which address families are in scope, and what should happen when the tunnel is down. Without that baseline every observation is ambiguous, because you cannot separate a leak from a path you deliberately allowed.
Then ask one question at a time. Which route does this destination take. What address does this reflector report. Which candidate pair did the session select. Keep the answers next to the policy and date them, since a firmware update can change default behaviour in ways that quietly invalidate last year's conclusion.
The router is still a strong enforcement point, because it sees traffic a client cannot bypass without reconfiguring the client itself. It is not a promise that every field in every application protocol reveals nothing, and it is no substitute for writing down the paths you chose to allow.