What is a VPN tunnel and how does it work?

A VPN tunnel is an encrypted path between two endpoints. The original packet is wrapped inside a new packet, protected so outsiders cannot read or alter it, and unwrapped at the far end. It hides content from the network in between. It does not make the endpoints themselves trustworthy.

What does "tunnel" mean in practice?

Tunneling means encapsulation: one packet carried as the payload of another. Say your laptop has the private address 10.1.0.5 and wants to reach a server at 10.2.0.9 inside an office. The laptop's VPN software encrypts that whole packet, puts it inside a packet addressed to the VPN gateway's public address, and sends it across the internet. The gateway decrypts it and delivers the inner packet to the server.

The NIST glossary describes a virtual private network as a virtual network built on top of existing networks that provides a secure communications path for private data across less trusted infrastructure.

How does IPsec do it?

IPsec is defined in RFC 4301. It offers two modes.

• Transport mode protects the payload of the original packet and keeps the original IP header. It suits traffic between two hosts.
• Tunnel mode encrypts the entire original packet and adds a fresh outer IP header. It suits gateway to gateway links and remote access, because the inner addresses stay hidden.

Both rely on security associations, which are agreed sets of algorithms and keys. Keys are normally negotiated automatically rather than typed in.

Other tunnel types exist. Many modern remote access products use TLS or UDP based protocols instead of IPsec, and the same wrapping idea applies.

What does a tunnel not protect?

• The endpoints. Malware on the laptop travels through the tunnel to the office network.
• Everything beyond the exit. After the gateway, traffic is as protected as the next link. If a user opens a plain HTTP site through a full tunnel, it is encrypted to the gateway and readable afterward.
• Metadata. The network still sees that you connect to a gateway, when and how much.
• Authorization. A tunnel proves a device or user got in. It does not decide what they may touch once inside.

Constructed example: a contractor connects through a site to site tunnel and gets reach to the entire 10.2.0.0/16 range because the route was broad. A stolen contractor laptop now has network reach to databases it never needed. Narrow routes and per resource rules would have limited the damage.

Split tunnel or full tunnel?

A full tunnel sends all traffic through the gateway, so company filtering applies but bandwidth and latency go up. A split tunnel sends only company destinations through the tunnel, which is lighter but leaves the device exposed on the open network at the same time. Choose deliberately and document it.

How does a tunnel get set up?

Before data flows, the two ends authenticate each other and agree on keys. With IPsec this negotiation is automatic and repeats from time to time, so a stolen key has a limited useful life. Authentication can use a pre shared key, which is simple but hard to manage across many sites, or certificates, which scale better and can be revoked. Pick certificates where you can. The remote user or site also gets an internal address and a set of routes that decide which destinations travel through the tunnel, and those routes are where most security decisions hide.

How to check or apply this

1. Confirm which protocol and version the tunnel uses and that it negotiates modern ciphers. Remove legacy options.
2. Use certificates or strong multi factor authentication for users, and device checks if you can.
3. Narrow routes to the subnets and ports users need.
4. Log connections and alert on odd locations, odd hours and failed authentication.
5. Patch gateways quickly. They face the internet and are attractive targets.
6. Decide on split or full tunnel and write it down.
7. Review whether per application access would serve some users better. NIST's zero trust architecture guidance assumes no implicit trust from network location.

Quick check

Sources

• RFC 4301, Security Architecture for the Internet Protocol
• NIST Computer Security Resource Center glossary, virtual private network
• NIST SP 800-207, Zero Trust Architecture

Last reviewed: 18 October 2026.