What is VPN tunneling

Tunneling is the technique of carrying one network protocol inside another. A VPN tunnel takes the IP packets your device would normally send to the open internet, wraps them in a second protocol, and forwards them to a VPN server that unwraps them on the other side. Nothing about the inner packets reaches the local network — only the outer wrapper does.

The word "tunnel" is a metaphor. There is no physical pipe and no dedicated path. The packets travel the same routers, switches, and undersea cables as everything else. What changes is what those routers can see: only the outer wrapper.

How encapsulation actually works

Every IP packet has a header (where it is going, where it came from, what protocol it carries) and a payload (the data). Tunneling treats the entire original packet — header and payload — as opaque bytes, then builds a brand-new packet around it.

A WireGuard tunnel works like this: your device wants to send a TCP packet to 1.1.1.1. WireGuard encrypts that whole packet with ChaCha20-Poly1305, prepends its own header, wraps the result in a UDP datagram, and sends that datagram to the VPN server's public IP on port 51820. To the local network, the only visible packet is "UDP from your device to the VPN server." The TCP packet inside is unreadable.

The VPN server reverses the process: receive UDP, strip the WireGuard header, decrypt, and forward the inner packet to its real destination.

What different protocols tunnel

Each VPN protocol is defined largely by what it tunnels inside what.

• WireGuard tunnels IP packets inside UDP. The header is fixed-size and minimal. Defined in Donenfeld 2017.
• OpenVPN tunnels IP packets inside TLS, which itself runs over TCP or UDP. The TLS handshake establishes session keys; data packets are encrypted with AES-GCM or ChaCha20. See RFC for the underlying TLS.
• IPsec tunnels IP packets inside an Encapsulating Security Payload (ESP) header, defined in RFC 4303. ESP runs directly over IP (protocol 50) or, for NAT traversal, over UDP port 4500.
• VLESS Reality tunnels IP packets inside a custom VLESS frame, inside TLS 1.3, inside TCP. The TLS handshake forwards a real third-party certificate so the connection is statistically indistinguishable from ordinary HTTPS. See Reality.

The common thread is that the inner packets never appear on the public network in their original form.

Tunneling vs encryption

The two are often conflated. Tunneling is encapsulation, the wrapping step. Encryption is making the wrapped contents unreadable. A tunnel can exist without encryption (GRE, IP-in-IP), and encryption can exist without tunneling (TLS over a single TCP connection). VPNs do both: encapsulate, then encrypt the encapsulated payload.

Practical consequence: anyone watching the network sees only the outer wrapper. They know you are talking to a specific VPN server and roughly how much data is moving. They do not know what sites you are visiting, what apps are open, or which IPs the inner packets target.

Why tunneling shape matters

Network-level adversaries cannot read tunnel contents, but they can see the tunnel exists. WireGuard's UDP signature is recognisable; some networks block it. OpenVPN over TCP-443 looks like HTTPS at first glance but has tells under deep packet inspection. Reality goes further by ensuring the outer wrapper is indistinguishable from a genuine TLS connection to a popular website.

The choice of tunnel protocol determines what an observer can detect, what they can block, and how much overhead each packet carries. WireGuard's lean header costs about 32 bytes per packet. OpenVPN over TCP costs more and adds head-of-line blocking. Picking the right tunnel is the central design decision of any VPN client.