Follow a packet through a VPN

Let’s follow one packet from your browser all the way to a website, with a full-tunnel VPN active. Once you can picture this path, most VPN behavior stops being mysterious.

The packet starts in the routing table. With a full tunnel, the best route for almost every destination points at the virtual interface. You can ask the kernel which route a destination would take:

ip route get 142.250.180.100
# 142.250.180.100 dev wg0 table 51820 src 10.14.0.2

The answer names wg0. The packet goes to the virtual interface, still unencrypted, with your VPN address 10.14.0.2 as its source.

Now the VPN client encrypts and wraps it. The original packet becomes the payload of a new packet, addressed to the VPN endpoint. That outer packet leaves through your real interface, eth0 or Wi-Fi.

This outer packet is all your local network can see. The coffee shop router sees a stream of encrypted packets going to one address. It cannot read the inner packet, and it cannot see where you are really going.

The VPN endpoint decrypts the outer packet and forwards the inner one toward the destination. When the endpoint also handles Internet traffic, it rewrites the source address. The website sees the endpoint’s address instead of yours.

You can check that last step yourself. Ask a public service which address it sees:

curl https://ifconfig.me
# 203.0.113.10

If that prints the VPN endpoint’s address, your traffic is really using the tunnel. If it prints your home connection’s address, your routes are not doing what you think. This is the first test I run after connecting to any VPN.

The reply retraces the path. The website answers the endpoint, the endpoint wraps the reply, your client unwraps it, and the browser gets its bytes as if nothing unusual happened.

One detail surprises people. Traffic to the VPN endpoint itself never goes through the tunnel. It cannot, because the outer packets need a direct path to reach the endpoint. The operating system keeps one ordinary route to it through your local gateway.

You can see that route too:

ip route get 203.0.113.10
# 203.0.113.10 via 192.168.1.1 dev eth0 src 192.168.1.34

The endpoint is reached through eth0, not wg0. That is correct behavior, not a leak. If someone tells you their VPN “leaks” because one address bypasses it, check whether that address is the endpoint itself.