VPN Tunnel Setup: Mermaid Sequence Diagram

About Source

A VPN (Virtual Private Network) tunnel is an encrypted, authenticated network connection that creates a private communications channel over a public network, allowing a client to securely access resources as if directly connected to a private network.

VPNs serve two primary use cases: remote access (employees connecting to corporate networks) and site-to-site (connecting two networks, e.g., branch offices or cloud VPCs to on-premises).

IKEv2/IPsec is the most common enterprise VPN protocol stack. WireGuard is a modern alternative with a significantly simpler codebase and faster performance. OpenVPN uses TLS-based tunneling.

IKE Phase 1 (SA Negotiation): The client and VPN gateway negotiate a secure channel (the IKE Security Association) for key exchange. They authenticate each other using certificates or pre-shared keys and agree on encryption parameters (cipher, hash algorithm, DH group).

IKE Phase 2 (IPsec Tunnel): Using the Phase 1 channel, the two sides negotiate the IPsec Security Associations (SAs) — one for each direction of traffic. The SAs define how traffic is encrypted (ESP: Encapsulating Security Payload) and authenticated.

Traffic Flow: Once the tunnel is established, traffic from the client destined for the corporate network is encapsulated in ESP packets. The ESP header includes a Security Parameter Index (SPI) that identifies the SA, and the payload (the original IP packet) is encrypted.

Split Tunneling: Many VPN configurations use split tunneling, where only traffic to corporate subnets goes through the VPN; internet traffic goes directly. Full-tunnel VPNs route all traffic through the VPN gateway.

NAT Traversal: IPsec has issues traversing NAT because NAT changes the IP header that IPsec integrity-protects. NAT-T (RFC 3947) addresses this by encapsulating ESP inside UDP port 4500.

Frequently asked questions

A VPN (Virtual Private Network) tunnel creates an encrypted, authenticated network connection over a public network, allowing a client to securely access resources as if directly connected to a private network. Traffic is encapsulated inside the tunnel protocol, hiding both the content and often the original source and destination addresses from anyone observing the public network.

IKE Phase 1 negotiates a secure channel (the IKE SA) between client and gateway using certificates or pre-shared keys, agreeing on encryption parameters and authenticating both parties. IKE Phase 2 uses that secure channel to negotiate the IPsec Security Associations (SAs) — one per direction — that define how data traffic is encrypted using ESP (Encapsulating Security Payload). Once both phases complete, traffic flows through the encrypted tunnel.

Split tunneling routes only traffic destined for the corporate network through the VPN, while internet-bound traffic goes directly from the client. Full-tunnel VPNs route all traffic through the VPN gateway, providing greater visibility and control for enterprise security but adding latency to all internet traffic and increasing gateway load.

IKEv2/IPsec is the enterprise standard — mature, widely supported by hardware appliances, and operates at the IP layer. WireGuard is a modern alternative with a significantly smaller codebase, faster handshake, and better performance on mobile (it uses connection IDs similar to QUIC). OpenVPN uses TLS-based tunneling over UDP or TCP, making it firewall-friendly but with higher overhead than the other two.

IPsec integrity-protects the IP header, but NAT rewrites it, breaking verification. NAT-T (RFC 3947) solves this by wrapping ESP packets in UDP port 4500, which NAT can forward without modifying the protected payload. The receiving gateway strips the UDP wrapper before processing the ESP packet. Most modern VPN clients detect NAT automatically and enable NAT-T without user configuration.

mermaid

sequenceDiagram
    participant Client as VPN Client
    participant Gateway as VPN Gateway

    note">Note over Client,Gateway: IKEv2 Phase 1 — IKE SA Setup
    Client->&gt;Gateway: IKE_SA_INIT\n(DH key exchange, nonce, proposed algos)
    Gateway-->&gt;Client: IKE_SA_INIT response\n(DH key share, nonce, selected algo)

    note">Note over Client,Gateway: Both derive IKE encryption keys
    Client->&gt;Gateway: IKE_AUTH\n(identity, certificate, AUTH payload) [encrypted]
    Gateway-->&gt;Client: IKE_AUTH response\n(identity, certificate, AUTH payload) [encrypted]

    note">Note over Client,Gateway: Mutual authentication complete\nIKE SA established

    note">Note over Client,Gateway: IKEv2 Phase 2 — IPsec Child SA
    Client->&gt;Gateway: CREATE_CHILD_SA\n(traffic selectors, ESP proposal)
    Gateway-->&gt;Client: CREATE_CHILD_SA response\n(SPI values, keying material)

    note">Note over Client,Gateway: IPsec tunnel established\nESP SAs in both directions

    note">Note over Client,Gateway: Encrypted traffic flow
    Client->&gt;Gateway: ESP packet\n(encrypted original IP packet\ndst: 10.0.0.0/8 corporate subnet)
    Gateway-->&gt;Client: ESP packet\n(encrypted response from server)

    note">Note over Client,Gateway: IKE keepalives maintain tunnel
    Client->&gt;Gateway: IKE_INFORMATIONAL (DPD)
    Gateway-->&gt;Client: IKE_INFORMATIONAL response