What Source Address Does STUN See With a Router VPN?
Route, source selection and translation decide the address a reflector reports. Three facts to write down, then one query to confirm which path wins.
The question sounds like one lookup and it is really three decisions. Which route the binding request takes, which source the kernel selects for that route, and whether anything on the way rewrites that source. Change any one of them and the address a STUN server reports changes with it. That is why saying the VPN sits on the router tells you almost nothing by itself.
The Decision Rests on Three Facts
First the route: policy rules and the routing table decide whether the request leaves through the tunnel or through the ordinary WAN, and an excluded destination takes the second path even while a tunnel is up. Second the source: the kernel picks a source for the chosen route, and that pick depends on the route's preferred source and on any rule that matched. Third the translation: NAT along the way replaces whatever source was chosen. The reflected address is the product of all three, not a property of the tunnel.
Change one of the three and the answer changes while every component still looks healthy in its own log. That is the usual reason this diagnosis stalls.
Write the three facts down for the flow you are testing before starting. Interface, route and translation rule are enough to predict the result, and predicting it first is what makes a surprise informative. If you cannot fill one of the three in, that gap is the actual finding.
Follow One Binding Request Through the Path
A STUN Binding request asks a server to report the source transport address it observed. The reply describes the path the request took, not an inventory of interfaces on the client machine. Two requests over two paths will honestly report two different addresses.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Read that table as a set of conditions rather than a menu of providers. The middle row requires the private reflector to be reachable under the tunnel's own routing and peer policy, which is a configuration fact you can verify and not something an account tier implies. The bottom row is usually the one that matters for policy, because that traffic was supposed to stay inside the tunnel. Between them sits the ordinary case, where the exit translates and the reflector sees only the exit.
Host candidates and server-reflexive candidates come from different mechanisms, so a candidate list is not a statement about which path the media actually used. Read the selected pair, not the gathering log, when you want to know where the session went.
What the Router's Tunnel Address Is Not
A tunnel address assigned to the router belongs to an interface on the router. A browser on a LAN host has its own interface addresses and no direct view of the router's tunnel interface. Treating the two as interchangeable produces confident wrong answers about what a web page can learn.
Forwarding is what connects them. The request crosses the router as routed traffic, and its source is whatever routing and translation produced.
If the tunnel path preserves the LAN source, a private reflector can learn that LAN address, which is a genuine disclosure and a different one from the tunnel address. If the path translates to the tunnel address, the reflector learns the tunnel address instead. Both outcomes are consistent with the same browser on the same host, which is why an observation has to be tied to a specific flow. Ask the kernel which source it would use before blaming the application.
Disclosure Versus Bypass: Two Findings, Two Repairs
A reflected tunnel address discloses an internal identifier over a path you permitted. A direct-WAN request bypasses a path you meant to require. The first is an information question, the second is an enforcement question, and they get fixed in different places. Collapsing them into one word produces a repair that addresses neither.
WebRTC makes this more visible without making it wrong, since gathering a candidate is not the same as selecting it.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showRun the route query for every reflector address you allow, with the source you expect that flow to carry, then run it again for the excluded ranges to see what the fallback selects. Compare the two answers against the policy you wrote down. When they differ in a way you did not intend, you have found the repair point without needing to interpret a browser's candidate list at all.