VPN concepts — tunnelling and encryption, and what a tunnel actually is

A VPN is two things bolted together: a tunnel that carries one packet inside another across an untrusted network, and encryption that makes the carried packet unreadable to anyone on the path. The tunnel is what reaches the other end; the encryption is what keeps the contents private. A firewall operator has to understand both — because the firewall is the endpoint for most VPNs, because every firewall rule that touches VPN traffic has to read the inner packet correctly, and because misconfigured VPN encryption does not produce a connection that fails, it produces a connection that silently leaks.

This lesson covers what a VPN actually is at the packet level, how encapsulation works, what encryption protects and does not protect, and the difference between transport and tunnel mode that the operator has to recognise in a packet capture.

What is a tunnel?

A tunnel is a virtual point-to-point link across an untrusted network. The sending endpoint takes the original (inner) packet, wraps it inside a new (outer) packet addressed to the receiving endpoint, and sends the wrapped packet across the untrusted network. The receiving endpoint strips the outer header, recovers the inner packet, and delivers it normally.

+-------------------+           untrusted network           +-------------------+
| Endpoint A        | -- outer header -> [inner packet] -> | Endpoint B        |
| 192.0.2.10/24     |   src=A.public  dst=B.public          | 203.0.113.5/24    |
+-------------------+           (the inner packet is         +-------------------+
                                  encrypted in transit)

The outer header is a normal IP header that any router on the untrusted path can read. The inner packet is what the endpoints see; to a router on the path, only the outer header exists. The encryption (when present) is applied to the inner packet before encapsulation, so what travels across the path is an outer header plus an opaque payload.

A tunnel without encryption is sometimes called a plain tunnel — the packet is wrapped but not protected. A tunnel with encryption is the typical production VPN: the firewall operator usually wants both, but the two are conceptually separate.

Encapsulation, byte by byte

Consider an IPv4 packet from a host behind endpoint A (10.0.0.50) to a host behind endpoint B (10.1.0.50), carried across a public network where endpoint A is at 198.51.100.1 and endpoint B is at 203.0.113.1. With IPsec tunnel mode and ESP, the on-the-wire structure looks like:

+-----------------------------+-----------------+-----------------+--------------------+----------+
| Outer IPv4 header           | ESP header      | [Inner IPv4 hdr] | [Inner payload]     | ESP      |
| src=198.51.100.1            | SPI, seq        | src=10.0.0.50    | TCP/UDP data        | trailer  |
| dst=203.0.113.1             |                 | dst=10.1.0.50    | (the actual traffic)| ICV      |
| proto=50 (ESP)              |                 | proto=6/17       |                     | (auth)   |
+-----------------------------+-----------------+-----------------+--------------------+----------+
       ^ routers on the path read this                ^ encrypted and authenticated, opaque to the path

The path between the endpoints sees an IPv4 packet from 198.51.100.1 to 203.0.113.1, protocol 50 (ESP). It has no way to read what is inside. Endpoint B receives the packet, recognises the SPI (Security Parameters Index — a 32-bit identifier for the security association) in the ESP header, decrypts the payload, validates the integrity check value, strips the ESP header, and delivers the inner IPv4 packet to 10.1.0.50 on its inside network.

This is the structure every IPsec tunnel-mode VPN follows. WireGuard looks different on the wire (UDP, no SPI, modern cryptography) but the principle is the same — outer header carrying an encrypted inner packet.

What encryption protects — and what it does not

Encryption on a VPN protects the payload of the inner packet: the TCP/UDP data, the application layer, the contents of any DNS query, the body of an HTTP request. An attacker on the path between the endpoints cannot read those bytes.

Encryption does not protect the outer header. The outer IP addresses are visible to every router on the path. The outer protocol (ESP, UDP for WireGuard) is visible. The length of the inner packet (within the precision of the cipher’s block/padding) is visible. The timing of the packets is visible. An attacker who can observe the path can therefore learn:

• That the two endpoints are communicating.
• How much traffic is flowing and when.
• The general pattern of activity (a burst at 09:00, a steady flow during the day, a quiet period overnight).
• The MTU and the approximate size distribution of the inner packets.

This is metadata. It is what most attackers actually need to map a network — who talks to whom, when, and how much — even without reading the contents.

Symmetric vs asymmetric encryption

VPNs use both, for different jobs:

• Asymmetric encryption (RSA, ECDSA, Curve25519) is used at the handshake to exchange a symmetric key without sending the key across the network. Both endpoints generate a key pair; the public keys are exchanged; a mathematical operation produces a shared secret that no observer can reconstruct. This is the Diffie-Hellman exchange. It is computationally expensive, so it is only used to establish the session.
• Symmetric encryption (AES-256, ChaCha20) is used for the bulk data. Both endpoints use the same key (derived from the handshake) to encrypt and decrypt. Symmetric encryption is much faster than asymmetric, and the bulk data path uses it.

WireGuard uses Curve25519 for the handshake (asymmetric) and ChaCha20-Poly1305 for the bulk data (symmetric). IPsec uses ECDH or RSA for the handshake and AES-GCM for the bulk data. OpenVPN uses RSA or ECDSA for the handshake and AES-GCM or ChaCha20-Poly1305 for the bulk data. The pattern is universal: handshake with asymmetric, bulk with symmetric.

Reading an encrypted packet

The firewall operator does not need to decrypt the VPN to read it — the capture shows the outer structure, and that is usually enough.

$ tcpdump -ni igb1 'proto 50 or udp port 51820' -c 4

12:34:56.789012 198.51.100.1 > 203.0.113.1: ESP(spi=0x6f8a3c12, seq=0x4e), length 152
12:34:56.901234 203.0.113.1 > 198.51.100.1: ESP(spi=0x9b2d7e44, seq=0x51), length 88
12:34:57.012345 198.51.100.1 > 203.0.113.1: ESP(spi=0x6f8a3c12, seq=0x4f), length 152
12:34:57.123456 203.0.113.1 > 198.51.100.1: ESP(spi=0x9b2d7e44, seq=0x52), length 1344

The capture tells the operator three things without any decryption: which two endpoints are communicating (the outer IPs), which security association is in use (the SPI), and the pattern of the traffic (packet sizes, inter-arrival times). That is enough to confirm the tunnel is alive, to detect an outage (sequence numbers stop advancing), and to spot asymmetry (one direction carries bulk traffic, the other carries only ACKs).

Summary

• A VPN is a tunnel (one packet wrapped inside another) plus encryption (the wrapped packet is unreadable on the path).
• Tunnel mode wraps the entire inner packet; transport mode leaves the original IP header visible. Use tunnel mode for site-to-site.
• Encryption protects the payload. The outer header, the packet length, and the timing are still visible to anyone on the path.
• VPNs use asymmetric encryption for the handshake and symmetric encryption for the bulk data. Configure only modern ciphers.
• The operator reads the outer structure — endpoints, SPI, sequence, length — to confirm the tunnel is alive and to detect outages.