Follow a packet through a VPN

Suppose your browser sends a request while a full-tunnel VPN is active. We can follow one packet the whole way.

First, the operating system consults its routing table. With a full tunnel active, the best route for almost every destination points at the virtual network interface. You can ask the kernel directly 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 is handed to the virtual interface, still unencrypted, carrying your VPN address 10.14.0.2 as its source.

The VPN client now encrypts and encapsulates it. The original packet becomes the payload of a new packet addressed to the VPN endpoint, and that outer packet leaves through your real interface.

This is the part your normal network can see: a stream of encrypted packets going to the VPN endpoint. It cannot read the protected inner packet, and it cannot see the real destination.

The VPN endpoint decrypts the outer packet and forwards the inner one toward the destination. When the endpoint also provides Internet egress, it rewrites the source address, so the destination sees the endpoint address instead of your current public address.

You can verify that last step yourself:

curl https://ifconfig.me
# 203.0.113.10

If that prints the VPN endpoint’s address, egress traffic is really using the tunnel. If it prints your home connection’s address, your routes are not doing what you think.

The reply retraces the path. The destination answers the endpoint, the endpoint wraps the reply, your client unwraps it, and the browser receives 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 it. The operating system keeps one ordinary route to the endpoint via your local gateway. That route is correct behavior, not a leak.