Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The VPN I use on my home Windows computer to connect to my company's servers is a Cisco client. The client is configured to use "IPSec over UDP (NAT/PAT)".

Why would you use UDP, an "unreliable" protocol, for a secure tunnel? Wouldn't the unreliability of the protocol cause problems when UDP packets are dropped?

Or is the protocol using UDP but adding reliability at the application layer?

share|improve this question
IP is also an "unreliable" protocol. – Michael Hampton Oct 5 '12 at 16:23
up vote 6 down vote accepted

It uses UDP to get through stupid NAT devices. What's happening here is that the actual IPSec traffic is being encapsulated in UDP (IP protocol 17). The native IPSec packet would have an IP protocol header-value of 50. Since 50 is neither UDP (17) or TCP (6), stupid NAT gateways will drop the packet rather than pass it.

Secondly, since IPSec is neither TCP or UDP, it doesn't have a port-number. So if you're at a very large conference and eight of your coworkers are also going, only one of you could have your VPN up at any time as the VPN Concentrator only does IP-level disambiguation. By encapsulating inside of a UDP packet, it allows multiple VPN end-points behind a NAT device.

As for why UDP? That's described in RFC 3715. Section 2.1.b:

Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.

As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.

This can happen since the IPSec stack itself has integrity checking, so using an 'unreliable' protocol to transit networks does not present a critical breakage in functionality. If a packet gets scrambled in-transit, it won't de-encapsulate right, and the IPSec protocol will correctly handle that case.

Some clients do support TCP mode, but Cisco isn't one of them.

share|improve this answer
Also, TCP Over TCP Is A Bad Idea – omribahumi May 24 at 9:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.