IPsec VPN
Virtual Private Networks using IPsec: AH, ESP, and tunnel protocols.
The Internet: A Public Space Full of Private Conversations
Imagine the internet as a global network of interconnected public roads. It is an incredible infrastructure that allows data packets, like delivery trucks, to travel from any point on Earth to any other. However, just like public roads, the internet is an inherently untrusted environment. Anyone with the right tools can potentially watch the trucks, see where they are coming from and going to, and even try to look inside them.
For everyday browsing, this might not seem like a major issue. But what if the trucks are carrying sensitive company documents, personal financial information, or confidential medical records? Sending such information over the public internet is like sending cash or trade secrets through the regular mail in a clear envelope. This is where the need for a private, secure communication channel arises. This need is fulfilled by a technology called a Virtual Private Network, or VPN.
What is a Virtual Private Network (VPN)?
A creates a secure, private "tunnel" for your data through the public internet. Let's break down the name:
- Virtual: The network is "virtual" because it doesn't rely on its own dedicated physical wires. Instead, it uses the existing public internet infrastructure. It creates a logical, software-defined network on top of the physical one.
- Private: The "private" aspect is achieved through strong security protocols. All data sent through the VPN tunnel is encrypted, making it unreadable to anyone who might intercept it. It also authenticates the communicating parties, ensuring you are talking to who you think you are talking to.
Common uses for VPNs include an employee working from home securely accessing the company's internal network, or two company offices in different cities (e.g., New York and London) securely connecting their local networks together over the internet, making them behave as one single, private network.
IPsec: The Foundation of Modern VPNs
To build these secure tunnels, we need a robust and standardized set of rules and protocols. The most widely used framework for this purpose is , which stands for Internet Protocol Security.
IPsec is not a single protocol but a suite of protocols that work together to provide a comprehensive security solution. A key feature of IPsec is that it operates at the Network Layer (Layer 3) of the OSI model. In simple terms, this means it can secure virtually any type of traffic that uses the Internet Protocol (IP), such as web traffic (HTTP/TCP), file transfers (FTP/TCP), video streaming (UDP), and even network pings (ICMP). Applications don't need to be specially designed to use an IPsec VPN; the security is applied transparently at a lower level.
IPsec provides security through two primary protocols: the Authentication Header (AH) and the Encapsulating Security Payload (ESP).
IPsec Core Protocol 1: Authentication Header (AH)
The primary purpose of the protocol is to guarantee the integrity and authenticity of data packets.
- Data Integrity: AH acts like a sophisticated, digital tamper-proof seal. It calculates a cryptographic checksum (called an integrity check value or hash) of the data packet. The receiver performs the same calculation. If the results match, the receiver knows the data has not been altered in any way during its journey across the internet. If even a single bit was changed, the checksums would not match.
- Data Origin Authentication: AH verifies the identity of the sender, ensuring the packet truly came from the claimed source and is not a forgery from an attacker.
An important characteristic of AH is that it does not provide confidentiality. It does not encrypt the data. Anyone who intercepts a packet protected only by AH can read its contents. Its sole purpose is to ensure the data is authentic and unchanged.
IPsec Core Protocol 2: Encapsulating Security Payload (ESP)
While AH provides a tamper-proof seal, the protocol provides the locked, armored box. Its primary function is to ensure confidentiality through encryption.
ESP takes the data payload of a packet and encrypts it using a strong encryption algorithm (like AES), turning it into unreadable ciphertext. Only the intended recipient, who has the correct decryption key, can unlock the data and read its contents.
In addition to encryption, ESP can optionally provide the same integrity and authentication services as AH. Because it can do both (encryption and authentication) in one package, ESP is the more commonly used protocol in modern VPN implementations. When you use a VPN, it is almost certainly using ESP to protect your data.
IPsec Modes of Operation: Transport vs. Tunnel
IPsec can operate in one of two distinct modes, depending on what parts of the IP packet need to be protected. The choice of mode dictates the type of VPN being created.
Transport Mode
Transport mode is used to secure communications between two specific endpoints (hosts). In this mode, IPsec protects only the payload of the original IP packet. The original IP header remains intact and unencrypted.
This means that while the actual data (e.g., the contents of your email) is secure, an eavesdropper can still see the original source and destination IP addresses, revealing who is talking to whom. This mode is typically used for host-to-host security within a trusted network.
Tunnel Mode
Tunnel mode is the powerhouse behind most VPNs. It is used to create a secure tunnel between two gateways (like routers or firewalls), or between a remote host and a gateway. In this mode, IPsec takes the entire original IP packet (both header and payload), encrypts it, and then encapsulates it inside a new IP packet.
This new outer IP packet uses the IP addresses of the VPN gateways as its source and destination. The original, internal IP addresses are completely hidden and encrypted. An eavesdropper on the internet can only see that the New York gateway is communicating with the London gateway; they have no visibility into which specific computers inside those networks are talking to each other. This is why tunnel mode is the standard for both site-to-site and remote-access VPNs.
The "Security Contract": Security Associations (SA)
Before two devices can start communicating securely using AH or ESP, they must first agree on a set of rules. This agreement is called a . An SA is essentially a security contract that defines every aspect of the secure connection.
The key parameters defined within an SA include:
- The security protocol to be used (AH or ESP).
- The specific encryption algorithm (e.g., AES-256) and authentication algorithm (e.g., SHA-256).
- The secret keys used for encryption and authentication.
- The lifetime of the keys (how long they are valid before new keys must be generated).
- The operational mode (Transport or Tunnel).
An essential property of SAs is that they are unidirectional, meaning they only define the rules for traffic flowing in one direction. For a typical two-way conversation, two separate SAs are required: one for traffic from A to B, and another for traffic from B to A.
The Handshake: Internet Key Exchange (IKE)
A critical question remains: How do two devices, communicating over the insecure internet, securely agree on the parameters for an SA and generate the shared secret keys without an attacker listening in and stealing them? This is the "chicken-and-egg" problem of security.
The solution is the protocol. IKE automates the entire process of SA negotiation and key management. It works in two distinct phases:
IKE Phase 1
The goal of Phase 1 is to establish a secure and authenticated channel between the two VPN gateways themselves. During this phase, the peers authenticate each other (typically using a pre-shared secret key or digital certificates) and negotiate a set of parameters to protect their own management traffic. The outcome of Phase 1 is a secure management tunnel (known as the IKE SA or ISAKMP SA). All subsequent negotiations can now take place within this protected channel.
IKE Phase 2
Once the secure IKE SA is established, the peers proceed to Phase 2. The purpose of this phase is to use the secure channel from Phase 1 to quickly negotiate the IPsec SAs that will be used to protect the actual user data. The peers agree on the protocol (ESP or AH), algorithms, and generate the keys for the data tunnels. This two-phase approach is efficient because the computationally expensive Phase 1 is performed only once to set up the management channel. Afterward, multiple, faster Phase 2 negotiations can take place to create or refresh SAs for different data flows as needed.
IPsec VPN interactive tunnel
Adjust authentication, cipher suites and tunnel mode to watch how IKE brings an IPsec VPN online.
Topology
10.1.0.0/24
10.2.0.0/24
Encapsulating Security Payload protects confidentiality and integrity.
Wraps entire IP packets; ideal for site-to-site VPNs.
Simplest to deploy; both peers share the same secret string.
Strong default choice for modern VPNs.
Modern default for integrity and HMAC.
Enable Perfect Forward Secrecy (PFS)
New Diffie-Hellman key for every rekey; improves security with slight overhead.
Negotiation timeline
Ready to start
IKE_SA_INIT proposals
Site A advertises AES-256/GCM with SHA-256 and plans pre-shared-key authentication, requesting PFS.
Proposals include Diffie-Hellman groups, crypto algorithms and lifetimes; PFS flag forces fresh keys later.
IKE_SA_INIT response
Site B selects AES-256/GCM with SHA-256 and returns key material to finish the exchange.
The Diffie-Hellman exchange builds the shared secret for the IKE SA.
IKE_AUTH and identity verification
Peers authenticate using the shared secret, proving who they are.
ID and AUTH payloads travel inside the encrypted IKE SA so credentials stay private.
CHILD_SA negotiation
Both sides agree on ESP (encryption + integrity) in tunnel mode to protect 10.1.0.0/24 <-> 10.2.0.0/24.
Traffic selectors and lifetimes are exchanged (CREATE_CHILD_SA / Quick Mode).
Protected traffic
ESP now encrypts and authenticates user data across the tunnel.
ESP encapsulates packets with confidentiality, integrity and anti-replay.