Symmetric NAT and VPNs: Test the Mapping, Not the Label
Endpoint-dependent mapping affects peer-to-peer discovery, not a normal client-to-server tunnel. Measure the port, then relay if the direct path fails.
A support thread ends with the verdict "symmetric NAT, the VPN will not work here", and the client is then reinstalled three times for no reason. The label is doing damage because it answers a question nobody asked. A client connecting outward to a fixed server creates a mapping the moment it sends the first packet, and the reply is allowed back under rules that almost every network implements. What endpoint-dependent mapping actually complicates is two peers trying to reach each other at the same time, and that is a different test.
Two questions hide behind one label
The first question is whether a host behind this network can open a session to a known public address and port. For a tunnel client that is the normal case, and the answer is almost always yes. The router records the internal source, allocates an external port, and lets the reply through because it belongs to a session that started from inside.
The second question is whether two hosts behind different networks can discover a shared path and send to each other without a server in the middle. That depends on how each network allocates those external ports, and it is the only place where the mapping behaviour matters.
Confusing the two produces the classic misdiagnosis: a peer-to-peer feature fails, someone runs a NAT-type test, sees the worst category, and concludes the ordinary tunnel cannot work either. The tunnel was never the thing that failed.
Mapping and filtering are separate properties
The RFC terminology is more precise than the names vendors use, and it is worth carrying into a ticket because it settles arguments. Mapping is how the external port is allocated. Filtering is which inbound packets are allowed to pass. A network can be strict in one and liberal in the other, and the combination is what a peer-to-peer protocol has to survive.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
The third row is what most consumer routers and mobile carriers mean by symmetric. Note that the label describes allocation only. A network with that mapping and liberal filtering can still accept inbound packets to the port it just allocated, which is why hole-punching succeeds on some of them and fails on others.
Filtering has its own three cases and its own name for each. Writing "symmetric NAT" in a ticket when you mean "address-and-port-dependent filtering" sends the next person to the wrong chapter of the manual. The two behave differently under test, so the mistake is not academic.
Measure the mapping instead of naming it
You can observe the allocated port directly from the server side of any UDP service you control. Start a capture on the public host, send from the client, and read the source port the packet arrived with:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820The endpoint line is the most useful of the three, because WireGuard records the last address and port it received from for each peer. Compare that port with the one the client believes it is using. They will differ whenever any translation is happening, and the important question is whether the value stays stable.
Repeat the observation against a second destination port or a second server and compare again. If the external port changes per destination, the mapping is address-and-port-dependent. If it stays the same, the network gives you one mapping and discovery has a chance.
STUN-based tools report the same classification in one step, and they are fine to use when the network permits outbound UDP to a public STUN server. When it does not, the capture method above still works and requires nothing but a host you already control.
Pick a fix that matches the failure
If the failing feature is peer-to-peer, the supported answers are a relay, a rendezvous service that both peers can reach, or a different topology. TURN exists for exactly this, and a product that ships its own relay is telling you it expects some networks to be hostile.
If the failing feature is an ordinary tunnel, mapping behaviour is not your problem and none of the above applies. Check that the client is actually sending, that the server sees the packet, and that the reply gets back. That sequence is three observations and it does not require knowing anything about the router's NAT category.
What does not work is scattering local port changes until something connects. Changing the client's source port does not change how the network allocates mappings. A coincidental success on a fifth attempt is a false positive, and it will be quoted as a fix for months.
Record the architecture, not the verdict
A useful note says which protocol, which direction the session starts in, whether a relay is in the path, and what was observed on the wire. "Symmetric NAT, does not work" is unusable, because it is simultaneously wrong about the tunnel and uninformative about the peer path.
Include the measured port stability and the filtering behaviour if you tested them. Those two facts let someone else predict whether a new feature will work on that network without repeating the whole investigation. They also age better than a vendor category that means something slightly different on each help page.
Finally, keep the RFC 4787 terminology to hand when you write it up. Using the precise terms costs one sentence and prevents the next reader from repeating the same misdiagnosis, which is the entire point of writing the note at all.