NAT Traversal for VPNs: Practical Concepts

Most people never think about NAT until a connection refuses to work. Your home router, your phone's mobile network and your office all share a small number of public addresses among many devices, and they do it with network address translation. That arrangement is invisible when you browse the web. It becomes very visible when you try to create a direct tunnel between two devices, host something from home, or find out why a VPN reaches the internet but cannot reach your own storage box.

This article explains the practical concepts behind vpn nat traversal: what NAT does, why it blocks direct connections, the techniques that get around it for legitimate tunnels, and how to troubleshoot. It is about ordinary networking. It does not cover bypassing anyone's network rules. If you are not yet sure what a public address is, start with what a public IP address is.

What NAT actually does

IPv4 addresses are scarce, so households and offices use private addresses internally, of the kind described in RFC 1918 (for example addresses starting 192.168). Those addresses are not usable on the open internet. The router sits between the two worlds and translates.

When your laptop at 192.168.1.20 opens a connection to a website, the router:

1. Replaces the source address with its own public address.
2. Picks a free public port for this conversation.
3. Writes a line in a table: "private address and port X is public port Y, talking to that website".
4. Rewrites the reply packets so they reach your laptop.

That table is the NAT mapping, and it is the heart of the matter. A mapping exists only because your laptop spoke first. If a stranger sends a packet to your public address and no matching line exists, the router has no idea which device it is meant for, so it drops it. This is why NAT often feels like protection, although it was designed to save addresses rather than to keep attackers out.

Why NAT blocks direct tunnels

A simple client-to-gateway VPN has no problem with NAT. Your phone sends the first packet outwards to the gateway, the router creates a mapping and the gateway's replies pass back through it. The gateway has a public address and a listening port, so it never needs to be found.

Trouble appears when neither side is publicly reachable:

• Two laptops in different homes each want a direct encrypted link.
• A remote worker wants to reach a machine at home that sits behind the home router.
• A game or call app wants a direct path between two players.

Each side can send outwards, but neither can receive an unprompted first packet. Both are waiting for the other to speak first. NAT traversal is the toolbox for breaking that deadlock.

The main techniques

Discovery

First, a device needs to know how it looks from outside. A helper on the public internet answers a simple question: "what address and port did this packet come from?" The device learns, for instance, that its router presents it as one particular public address and port. This is the purpose of protocols such as STUN, and many tunnel tools do something similar through their coordination service.

Hole punching

With each side's public address and port known, both devices send a packet to each other at about the same moment. The outgoing packet from A creates a mapping on A's router that expects a reply from B. B does the same. When A's packet reaches B's router, a mapping already exists that was made by B's own outgoing packet, so it is let in. The "hole" is a pair of matching mappings opened from inside.

A short example with times: at 14:00:00 both laptops learn each other's public address. At 14:00:01 each sends a small packet. The first packets may be dropped because the opposite mapping is not ready yet, but a second or third attempt a moment later is accepted. By 14:00:03 the encrypted tunnel can start its handshake.

Keepalives

Mappings do not last forever. Routers delete idle lines after anywhere from about half a minute to a few minutes, depending on the device and the protocol. A small packet sent every 15 to 30 seconds keeps the mapping alive. This is the reason tunnel tools offer a keepalive setting, and it matters most for devices that must be reachable while otherwise silent.

Relays

When hole punching fails, a relay is the fallback. The relay is a public machine both sides can reach outwards. It forwards the already-encrypted packets between them. This works almost anywhere, at the cost of an extra hop, higher latency and the relay's capacity. The relay should not be able to read the content, but it can see the amount and timing of traffic.

Port mapping on your own router

If you control the router, you can create a mapping by hand, called port forwarding, or ask the router to do it automatically with UPnP or similar. This opens a fixed door from the internet to a device. It is simple but exposes a service to everyone who knows the address, so it needs care; our article on VPN port forwarding explained lays out the uses and risks.

Types of NAT and what they allow

NAT behaviour differs between devices. The names vary, but the idea is how the router reuses its mappings.

Behaviour	What it does	Effect on traversal
Endpoint-independent mapping	Uses the same public port for all destinations	Hole punching works well
Address- or port-dependent mapping	Uses a different public port per destination	Hole punching often fails because the learned port is no longer valid
Open or full cone	Lets anyone reach a mapped port	Easy, but rare
Restricted	Only allows replies from addresses you contacted	Works with the hole-punch pattern
Carrier-grade NAT (CGNAT)	The provider shares one public address among many customers	Often no direct path and no port forwarding

Gaming consoles often show these as "Open", "Moderate" or "Strict". For the gamer's view and what a VPN changes, see VPN and NAT type.

Scenarios that make it concrete

A home server and a laptop on the road. Somsak runs a small storage box at home. His fixed home router has a normal public address, so he sets up one narrowly scoped route and a tunnel with a keepalive. His laptop connects from a hotel by sending outward, and the box answers through the same mapping. No unnecessary ports are exposed.

A house on a carrier-shared address. Alina's home internet provider uses CGNAT, so her router's "public" address is actually private from the provider. Port forwarding on her own router does nothing, because the provider's equipment sits in front of it. Her options are a relay-based tunnel, which works because the home device connects outward, or asking the provider about a public address. The explanation in VPN with CGNAT covers how to recognise this. Shared address ranges of this kind are reserved in RFC 6598.

Two devices behind strict routers. Two friends want a direct link between their laptops, and both routers use per-destination ports. Hole punching fails, so their tool falls back on a relay. They notice higher ping than they expected and accept it for file sharing. For a game session they would look at other options.

Troubleshooting a tunnel that will not connect

Work through these in order and change one thing at a time.

1. Confirm the basic path. Can the device reach the internet at all? A captive portal or a broken router blocks everything.
2. Check for double NAT. If your router's "WAN address" begins with 10, 192.168 or 100.64 to 100.127, there is another translator upstream. Putting the provider's box into bridge mode, if allowed, often fixes it.
3. Look at the protocol. Many tunnels use UDP. Some networks drop it. Try another network such as mobile data to test.
4. Add or shorten the keepalive. If the tunnel works for a minute and then goes quiet, a mapping is expiring.
5. Review port forwards. A forward to an old IP address or a changed device does nothing. Give the target a fixed local address.
6. Check the router's tunnel pass-through. Some older routers mishandle certain tunnel packets. See router VPN passthrough.
7. Test the packet size. A mismatch can make a tunnel look connected while large transfers hang. VPN MTU problems explains.
8. Restart in order. Power-cycle the modem, then the router, then the device. Mappings are cleared and rebuilt.

Where IPv6 fits in

IPv6 provides so many addresses that every device can have its own public one, which removes most of the reason for NAT. In theory, two IPv6 devices can reach each other directly. In practice, home routers still run a firewall that blocks unsolicited inbound packets by default, so a first packet from outside is dropped much as it would be with NAT. The traversal ideas above still apply: both sides send outward so that each firewall allows the other's replies, and keepalives keep those allowances alive.

The practical lesson is that "no NAT" does not mean "reachable". Check whether your provider hands out IPv6, whether your router firewall lets you allow a specific device, and whether your tunnel tool uses it. If you also use a VPN, test that IPv6 traffic goes through the tunnel and does not leak around it; the checks are described in what an IP leak is.

Limits and good habits

• Traversal does not guarantee a direct path. Strict NATs and CGNAT can force a relay, and you should plan for the extra latency.
• Port forwarding is a permanent door. Only forward what you need, to one device, and keep that device updated.
• NAT is not a security feature. A tunnel with authentication and encryption is the protection; the router's address table is not.
• A client VPN does not need most of this. If you only want to protect your phone on public Wi-Fi, an ordinary connection to a gateway works through NAT without special steps.
• Remove what you no longer use. Delete old forwards, old keys and old devices from your configuration.

Summary

NAT translates private addresses into a shared public one and only lets replies in for conversations that were started from inside. That is harmless for an ordinary VPN connection from a phone to a gateway, but it blocks direct links between two devices that are each hidden behind a router. Discovery, hole punching, keepalives, relays and careful port mapping solve it, and CGNAT or double NAT explain most of the stubborn cases. When a tunnel fails, check the basic path, look for double NAT, test another network and shorten the keepalive.

If you simply want to protect your own devices on shared networks, the pricing page shows how a prepaid pass works, and the download page lists the free app.