Internet Protocol Security (IPsec) is a suite of open standard protocols that protect traffic at the IP layer by encrypting it, checking that it hasn’t been altered and confirming where it came from. It is the most common way to build site-to-site VPN tunnels between offices, data centers, cloud networks and partners over the public internet, and it is also used for some remote-access VPNs. Because it is standardized, equipment from different vendors can usually build IPsec tunnels to one another.
At a glance
- IPsec encrypts and authenticates IP packets so they can travel safely over untrusted networks such as the internet.
- Its main use is site-to-site VPN tunnels between offices, data centers and cloud providers.
- IKE (Internet Key Exchange) negotiates keys and settings; ESP (Encapsulating Security Payload) protects the data.
- Both ends of a tunnel must agree on matching settings, which is the most common cause of failures.
- SD-WAN and SASE products commonly use IPsec tunnels underneath.
What problem it solves
Companies need to connect sites and clouds privately, but dedicated private circuits are expensive and slow to install, especially for small or international locations. Ordinary internet connections are cheap and available almost everywhere, but traffic sent over them can be intercepted or tampered with.
IPsec solves this by building an encrypted tunnel over the internet, so traffic between two locations is protected as if it ran over a private line. It is also used as a backup path when a private circuit fails, to connect to public cloud networks, and to link with partners and suppliers.
How it works
Security associations. Two devices (often firewalls or routers) agree on how they will protect traffic: which encryption and integrity algorithms to use, which keys and for how long. That agreement is called a security association.
IKE. The Internet Key Exchange protocol sets up those associations. The two ends authenticate each other, using a pre-shared key or certificates, then agree on keys with a Diffie-Hellman exchange. IKEv2 is the current version and is recommended for new deployments; IKEv1 remains for older equipment. Perfect forward secrecy (PFS) can be enabled so that each new set of session keys comes from a fresh Diffie-Hellman exchange; if a long-term key such as the pre-shared key or a certificate’s private key is later compromised, previously recorded traffic still can’t be decrypted with it.
ESP and AH. Encapsulating Security Payload (ESP) encrypts and authenticates the data and is what almost all deployments use. Authentication Header (AH) authenticates without encrypting and is rarely used today.
Tunnel and transport mode. In tunnel mode, used for site-to-site VPNs, the whole original packet is encrypted and wrapped in a new one. Transport mode protects only the payload and is used mainly between individual hosts.
NAT traversal and resilience. When a device sits behind network address translation, NAT traversal wraps IPsec in UDP so it can get through. Dead peer detection notices when the other end has gone away, and many designs run two tunnels to different endpoints for redundancy.
Routing. Tunnels can carry fixed lists of subnets (policy-based) or act like a virtual interface that a routing protocol such as BGP runs over (route-based). Cloud providers commonly support route-based tunnels with BGP.
When it matters for buyers
- When opening an office or connecting a small site. An IPsec tunnel over business internet is often the fastest option.
- When connecting to AWS, Azure or Google Cloud. Cloud VPN gateways use IPsec; dedicated connections are the alternative for higher, more consistent throughput.
- When replacing or backing up MPLS. IPsec over internet links, often under SD-WAN, is the usual replacement.
- When adopting SASE. Offices often connect to the SASE provider with IPsec tunnels from existing firewalls.
- When international sites need connecting. Where private circuits are costly or slow to provision.
Questions to ask vendors
- What IPsec throughput does the device support with encryption on, and how many tunnels?
- Do you support IKEv2, route-based tunnels and BGP over the tunnel?
- Which encryption algorithms and Diffie-Hellman groups are supported, and are older weak options disabled by default?
- How is redundancy handled, with multiple tunnels, links or devices?
- Will you configure and monitor the tunnels as a managed service, including to our cloud and partners?
- How does IPsec fit with your SD-WAN or SASE service if we adopt one later?
How it differs from SSL/TLS VPNs and GRE
Secure Sockets Layer (SSL) and its successor TLS secure individual application connections, and TLS-based VPNs are common for remote users because they pass easily through firewalls. IPsec secures all IP traffic between two networks and is the usual choice for site-to-site links. Generic Routing Encapsulation (GRE) creates tunnels without encryption; it is often combined with IPsec when a tunnel needs to carry routing protocols or multicast and also be encrypted. For tunnel topologies and redundancy patterns, see our Private Networking guide.
Problems this helps with
- Connecting branch offices securely over ordinary internet circuits
- Linking our network to AWS, Azure or a partner's network
- Backup connectivity when a private circuit fails
- VPN tunnels that keep dropping between sites
