What a VPN Tunnel Is, and Where the Protection Stops

The client says connected, the padlock is on, and a site still logs the address of your flat. Nothing has failed. A tunnel does not replace your Wi-Fi or your mobile link; it puts a second envelope around certain packets and posts that envelope across the network you already had. Understanding the trick is mostly a matter of following one request and noticing where the envelope is opened, because almost every confusing symptom, from a leaking home address to a stalled large download, comes from that boundary.

Two envelopes, one physical link

Your laptop keeps its normal connection to the router, and the router keeps its normal connection to the provider. Nothing about that path changes when a tunnel comes up. What changes is that selected packets are handed to a virtual interface, wrapped inside a new packet addressed to the VPN peer, and sent as ordinary traffic over the physical link.

The receiving end is a device that unwraps the envelope and forwards the original packet towards its destination. Between the two ends, an observer sees the outer header and nothing about the inner one unless the protocol encrypts it, which most consumer protocols do and the general technique does not require.

This is why the virtual interface is both real and misleading. It exists as a kernel object with an address and a maximum transmission unit, and the operating system routes into it like any other interface. It is not a cable, and its existence proves only that a component is installed. Whether your browser uses it is decided by routes, not by the interface being up.

Watch one request take the trip

Pick a destination and ask the kernel which interface it will use. This single command resolves most arguments about whether the tunnel is doing anything:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

If the route output names the tunnel interface, the packet will be wrapped. If it names the physical interface, it will not, and no amount of restarting the client changes that. The second command shows both interfaces side by side, which is how you spot a tunnel that came up without an address or with an address in the wrong family.

Then look at the first hop from inside the envelope, and compare it with the first hop outside:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Inside the tunnel the first hop is the peer's inner address, not your router. The capture on the tunnel interface shows the inner packets, which is the traffic the application believes it is sending. Capturing on the physical interface at the same time shows the outer packets, and the two together are the clearest demonstration of what a tunnel actually does.

Three addresses, and only one is seen by the website

People confuse these constantly, and the confusion produces false leak reports. They are different fields in different headers with different lifetimes.

The number beside the virtual adapter is the second row. It is not the address a website records, and quoting it as your public IP is simply wrong. The address a website sees is assigned by the exit, and for a private-network tunnel there may be no public exit at all, because the destination lives inside the organisation rather than on the internet.

A site-to-site tunnel is the same mechanism with different endpoints. Two routers wrap traffic between networks, and no individual device has a client installed. The envelope is identical in principle and the administrative boundary is not.

Where the envelope is opened, and what survives it

The tunnel ends at its peer. If the application's own encryption extends further, it survives that boundary, which is the normal case for HTTPS: the browser's session terminates at the website, so the exit forwards ciphertext it cannot read.

Nothing else survives by default. An unencrypted request is readable at the exit exactly as it was readable on the café Wi-Fi, and the tunnel does not add protection the application never had. Likewise, the exit's firewall rules and forwarding policy decide what happens next; a successful handshake is a fact about the peer connection, not about the rest of the journey.

Overhead is the other visible consequence. Each packet carries an extra header, and the outer transport may add its own, so the usable payload per packet shrinks. On a path with a fixed maximum transmission unit, that is exactly why a tunnel can pass a ping and stall a large upload.

Check the path the application actually took

The last step is to confirm the specific application, rather than the machine in general. Resolve the destination, look at the route for that address, and then observe the connection while it is open:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

If the route names the tunnel but the socket listing shows a connection with a source address from the physical interface, the application is bound to something specific, or a second tunnel is competing for the default route. That is a routing question, and it is answerable from these three outputs rather than from the client's status screen.

The RFC 4301 security architecture describes the IP-layer version of this wrapping for IPsec, and the same layering logic applies to WireGuard and OpenVPN. Once you can point at the inner packet and the outer packet as separate objects, most tunnel behaviour stops being mysterious and becomes a routing table you can read.