How Does a VPN Work? Follow a Single Packet Out and Back

A VPN works by inserting itself into a decision your device already makes thousands of times a minute: given a packet, which interface should it leave through? The client adds a new interface, makes it the preferred one, and then wraps everything handed to it inside an ordinary encrypted connection to a server. Following one packet from your application to its destination and back is the clearest way to see where each change happens, and which of your problems each step can and cannot affect.

The account below is deliberately about interfaces, routes, and addresses rather than about handshakes and ciphers. Which protocol builds the connection and which cipher protects it are separate questions that change this walkthrough’s efficiency, not its shape.

Before the VPN: the decision your device already makes

Every outbound packet gets matched against your routing table before anything else happens. The table is a short list of destinations and the interfaces that lead to them. One entry usually covers the local network directly, and one catch-all entry — the default route — says where to send anything else, which for most home setups is your router.

So a packet aimed at a website goes to your router, your router replaces the private source address with its own public one, and the packet leaves your connection. The reply comes back to that public address and the router works out which device asked for it. This is the arrangement a VPN modifies, not one it replaces.

Step one: the client builds an interface

When you connect, the client creates a virtual network interface. The operating system treats it like a network card: it has an address, a subnet mask, its own resolver settings, and a place in the routing table. The address it holds comes from the operator’s internal range and identifies your session to the server, not to the internet — a point developed in why a VPN gives you two IP addresses.

Nothing has moved yet. At this point you have two working interfaces and the same routing table you had a moment ago.

Step two: the routing decision changes

This is the step where a VPN actually takes effect, and it is nothing more than an edit to a list. The client installs a new default route pointing at the virtual interface, so the catch-all destination is now the tunnel instead of your router. It also installs one narrow exception: traffic addressed to the VPN server itself must keep using the physical interface, or the encrypted connection would try to travel inside itself.

Two familiar behaviours fall directly out of these edits. Split tunnelling is the client choosing, per application or per destination, which of the two interfaces to select. A tunnel that connects but changes nothing is a default route that never got replaced.

Step three: the packet is wrapped and re-addressed

Your application’s packet arrives at the virtual interface still addressed to the website. The client takes that whole packet — headers and all — and puts it inside a new one addressed to the VPN server, encrypting the contents on the way in. The new packet is then handed to your physical interface and sent the ordinary way, through your router and out over your provider’s link.

That is what encapsulation means: the original packet becomes the payload of another. The useful way to hold it is as two sets of addresses travelling together. The inner pair says “from my tunnel address, to the website”. The outer pair says “from my router’s public address, to the VPN server”. Only the outer pair is readable in transit, which is the entire privacy property of this step, stated in addressing terms.

So what your provider and your local network keep is the outer pair, plus volume and timing. What they lose is the inner pair — which hosts you are actually contacting.

Step four: the exit

At the server the outer packet is unwrapped and decrypted, and the inner packet is recovered. The server then does something your router already does: it replaces the private source address with a public one it owns, notes which session the connection belongs to, and forwards the packet onward.

From here the packet is completely unremarkable. It travels to the website by ordinary routing, and the website sees a request from the server’s address. That address is the one leak tests report, the one geolocation databases get looked up in, and the one shared with everyone else exiting that server.

Nothing about the destination end of the journey is encrypted by the VPN. Whatever protection the traffic has from the server onward is whatever the connection itself provides — the same protection it would have had without a VPN at all.

Step five: the return trip

The reply arrives at the server addressed to the server. The server matches it to your session, addresses it to your tunnel address, wraps and encrypts it, and sends it to your router’s public address. Your client unwraps it, hands the inner packet to the virtual interface, and your application receives a reply from the website exactly as it expected.

Every round trip therefore takes a detour through the server, which is the entire mechanism behind a VPN’s effect on responsiveness. A distant server means a longer detour on every single exchange, and it is a matter of geometry rather than of the provider’s quality.

What name resolution does in the middle of all this

Resolution is a separate journey, and it is the step most likely to be misconfigured. Before any of the above happens, your device has to turn a hostname into an address, and that query follows its own routing and its own resolver setting. The virtual interface carries resolver settings of its own precisely so lookups go where the traffic goes.

When they do not — because the operating system kept an earlier resolver, or queried several at once — you get the case where traffic is properly tunnelled while the record of what you looked up goes somewhere else entirely. Confirming the exit address tells you nothing about this. It is a second, independent test.

Watching the steps on your own machine

You can observe most of this directly, which is worth doing once:

1. Interfaces. List them connected and disconnected. The virtual one appearing, with a sensible address, is step one confirmed.
2. The routing table. Check where the default route points in each state. That is step two, and it is the step that silently fails. How to read your own network settings covers what the fields mean.
3. The path. Run a traceroute to the same destination in both states. Disconnected, you see your provider’s early hops; connected, the first useful hop is the server and the path continues from there. What a traceroute shows before and after you connect reads one line by line.
4. The exit. Note the public address a service reports for you in each state. That is step four.

Four checks, four steps, and each one distinguishes a different failure that presents identically in an app’s status indicator.