skip to content

How do IPsec, WireGuard and TLS-based VPNs each get through a NAT, and which of them still connects when a hotel network blocks UDP?

level: middleimportance: must knowfreq 35%

answer

  1. three answers to one translator
  2. give the NAT ports to rewrite
  3. UDP 4500 versus UDP from birth
  4. a timed packet from the inside
  5. TCP as the last rung

basics

~20 s

Tunnels answer a NAT three ways: ride UDP (IPsec wraps ESP in UDP 4500; WireGuard is UDP already), send keepalives so the mapping stays, or hide inside TCP or TLS on 443. Only the TCP rung survives dropped UDP.

solid answer

~50 s

A port-translating NAT multiplexes on ports, so a tunnel that must cross one reliably ends up on UDP or TCP. IPsec's ESP has no ports, so when IKEv2 detects a translator it moves IKE and ESP into UDP port 4500 (RFC 3948). WireGuard needs no switch: its whitepaper defines only UDP carriage. Many TLS-based VPNs also carry data over UDP. The second answer is time: an idle UDP mapping expires, so the peer behind the NAT sends small keepalives - 20 seconds by default in RFC 3948, an optional persistent keepalive in WireGuard. The third answer is camouflage: on a hotel network that drops UDP, only TCP gets through - a TLS-based VPN on TCP 443, or IKE and ESP over TCP per RFC 9329 - at the price of TCP-in-TCP. A WireGuard-only design has no TCP rung at all.

go deeper

for a junior

Recall the three answers by name: put the tunnel on UDP, send keepalives so the translator remembers it, or hide inside TCP or TLS on 443 when UDP is blocked.

for a middle

Explain why ESP needs UDP 4500 while WireGuard does not, what a keepalive refreshes, and which designs have a TCP fallback at all. Name RFC 3948 and RFC 9329 correctly.

for a senior

Separate the two hotel failures: a mapping that expires while idle versus a network that never passes UDP. Show how you would tell them apart from the symptoms before changing any setting.

for a principal

Frame the trade: UDP first for performance, TCP as a fallback for reach, and the cost of a design with no TCP rung. Tie the choice to where your users actually connect from.

## The problem every tunnel meets A **network address and port translator** (NAPT) lets many private hosts share one public address by rewriting the source address *and the source port* of outgoing packets, then using the port to send replies back to the right host. That works cleanly for protocols that carry ports, which for tunnels means UDP and TCP. RFC 3715 records that many translators discard other protocols, or translate the address only and so serve just one inside host. A VPN tunnel is just packets between two endpoints, so every tunnel protocol has to answer the same question: what does the translator see, and does it keep seeing it? There are three answers, and real designs combine them: 1. **Ride UDP** so the translator has ports to rewrite. 2. **Keep the mapping alive** with a periodic packet from the inside, so an idle tunnel does not lose its translation. 3. **Hide in TCP (often TLS on port 443)** when the network will not carry UDP at all. ## Answer 1: ride UDP - **IPsec.** ESP is its own IP protocol with no port fields, so a NAPT has nothing to multiplex on. When IKEv2 detects a translator during its first exchange, both peers move IKE and ESP into **UDP port 4500** - ESP-in-UDP, specified in **RFC 3948**. How that detection and the port move work belongs to the IPsec NAT traversal topic; what matters here is the outcome: IPsec becomes a UDP flow. - **WireGuard.** The WireGuard whitepaper (not an RFC) defines only **UDP carriage**, and a peer's listening port and the source port of its packets are always the same. There is nothing to detect and nothing to switch. - **TLS-based VPNs.** Many of these designs carry their data channel over UDP when it is allowed. No RFC defines this family, so the details are each implementation's. UDP is preferred because a tunnel should behave like a link: it may lose packets, and the TCP connections *inside* it recover on their own. ## Answer 2: keep the mapping alive A translator forgets an idle UDP mapping. **RFC 4787** (a Best Current Practice) says a NAT's UDP mapping timer must not expire in under two minutes and recommends five minutes or more, but it also notes great variation among real translators. So the peer *behind* the NAT sends small packets while the tunnel is otherwise idle: - **RFC 3948 NAT-keepalives**: a one-octet packet sent when nothing else has gone to the peer for `M` seconds, **20 seconds by default**. - **WireGuard's persistent keepalive**: optional and off unless configured; the paper gives no interval, and the common **25-second** value comes from implementation documentation. - **TLS-based VPNs**: an in-tunnel ping whose interval is the implementation's choice. Keepalives fix *expiry*. They do nothing for a network that drops UDP outright. ## Answer 3: hide in TCP or TLS on 443 Some hotel, guest and corporate networks pass little more than web traffic. There, the only rung that works is a tunnel inside a TCP connection: - **TLS-based VPNs** fall back to their TLS connection, typically on **TCP 443**, which such networks rarely block. - **IPsec** can carry IKE and ESP over TCP per **RFC 9329** (which obsoletes RFC 8229). Every implementation must support **TCP port 4500**; other ports such as 443 are an optional configured alternative, and Appendix A adds an optional TLS layer and HTTP `CONNECT` through a web proxy. TCP encapsulation is configured on both peers, not negotiated. - **WireGuard** has no answer in its own specification: the paper defines no TCP carriage. The price is **TCP-in-TCP**: loss on the outer connection becomes delay for every inner flow, and stacked retransmission timers can make throughput collapse. That is why RFC 9329 says to prefer direct or UDP-encapsulated ESP whenever possible. ## Side by side | Design | How it crosses a NAT | Idle mapping | Network that drops UDP | |---|---|---|---| | IPsec (IKEv2 + ESP) | ESP-in-UDP on 4500 after NAT detection | RFC 3948 keepalive, 20 s default | Only if both ends are configured for RFC 9329 TCP encapsulation | | WireGuard | UDP from the start | Optional persistent keepalive | Fails: no TCP carriage in the paper | | TLS-based VPN | UDP data channel in many designs | Implementation's ping | Falls back to TLS on TCP 443 | ## Which one survives the hotel The hotel problem is really two different failures. If the tunnel connects but dies after a quiet coffee break, the translator's UDP mapping expired and a **keepalive from the inside** is the fix. If the tunnel never connects at all while web browsing works, the network is dropping UDP, and only a design with a **TCP rung** - a TLS-based VPN, or IPsec configured for RFC 9329 - will connect. Telling the two apart is the first diagnostic step.

  • If TCP 443 passes nearly every network, why not carry every tunnel over it by default?
    Because TCP turns a lossy link into a reliable one. A lost outer segment stalls every inner flow until it is retransmitted, inner TCP connections see that as delay and may retransmit spuriously, and real-time traffic arrives late instead of being dropped. RFC 9329 therefore says implementations should prefer direct or UDP-encapsulated ESP and use TCP only when UDP fails.
  • What can a WireGuard-only deployment do on a network that drops all UDP?
    Nothing inside the protocol. The WireGuard whitepaper defines only UDP carriage, so the tunnel cannot come up there. Operators either wrap WireGuard in some other transport, which is outside its specification and carries the same TCP-in-TCP costs, or keep a second VPN with a TCP rung for those networks.

saying these in an interview costs you the question

  • IPsec can never cross a NAT, so remote access must use a TLS-based VPN.
  • WireGuard switches to TCP on its own when UDP is blocked.
  • Keepalives are what get a tunnel through a network that drops UDP.
  • RFC 9329 requires IKE and ESP over TCP to use port 443.
  • Running every tunnel over TCP 443 costs nothing, so it should be the default.