What Happens in the First Second of a VPN Connection
Connecting a VPN is a short sequence: the client finds a server, proves who each party is and agrees on keys, creates a virtual network interface, and rewrites your system’s routing rules so traffic goes there. Every one of those steps involves network activity that happens before the tunnel exists, which is why the moment of connection is the most interesting part of a VPN’s operation and the most likely place for something to leak.
Knowing the sequence lets you reason about failure modes yourself instead of trusting a connected icon.
Step one: finding the server
The client has a server name — an entry in its list — and has to turn that into an address. That means a DNS lookup, performed using whatever resolver your system is currently configured to use, which at connection time is the one your local network handed you.
Consequence: your local network sees a lookup for a hostname that is recognisably a VPN endpoint. This is unavoidable in the general case and is worth knowing about, because it means “the network cannot tell I use a VPN” was never true.
Some clients keep cached endpoint addresses, or fetch a server list over an encrypted channel first, which changes the details but not the principle: the first packet cannot be inside a tunnel that does not yet exist.
Step two: the handshake
The client and server now establish a secure channel. Modern protocols differ in their details, but the ingredients are broadly the same as of writing:
Authentication of the server, so your client knows it is talking to the provider’s machine and not something impersonating it. Depending on the protocol this uses certificates or pre-distributed public keys.
Authentication of you, using credentials, a certificate, or a key configured when you set up the client.
Key agreement, producing session keys that both sides hold and nobody watching can derive. The important property here is that the session keys are ephemeral, so a recording of the traffic does not become readable later if a long-term key is compromised.
Cipher negotiation, agreeing which algorithms to use — or, in the newer protocols, not negotiating at all, because a fixed modern set is baked in. That design choice removes a class of downgrade attack and is one reason newer protocol designs are simpler than older ones.
How long this takes and how many round trips it needs varies by protocol, and it is the honest reason some connections feel snappier than others. It is not something this site puts numbers on, since we have measured nothing.
Step three: the virtual interface
With a secure channel established, the client creates a virtual network interface on your system. To the operating system it looks like an ordinary network adapter; in reality, anything sent to it is handed to the VPN client, encrypted, and forwarded inside the established channel.
Why this matters: the interface is what lets the VPN work for every application without any of them knowing. Nothing needs VPN support, because from the application’s point of view it is just the network.
Why it needs privilege: creating interfaces and modifying routing requires elevated rights, which is why VPN clients install privileged components and why you are extending them more trust than an ordinary app.
Step four: rewriting the routing table
Now the client changes your system’s routing rules so traffic prefers the new interface. Typically that means installing a default route pointing at the tunnel, plus specific exceptions — one for the VPN server’s own address, so the encrypted traffic itself does not loop back into the tunnel, and often exceptions for local network ranges so printers and file shares keep working.
The client also normally reconfigures DNS to use a resolver reachable through the tunnel, so your lookups stop going to the local network’s resolver.
This is where implementations differ most, and where the interesting bugs live. Handling IPv6 as thoroughly as IPv4, coping with a network that changes underneath you, dealing with an operating system that has its own opinions about DNS resolution — these are the details that separate a client that leaks from one that does not.
The gaps, in order of importance
Before the tunnel is up. Between the moment you connect to a network and the moment routing is rewritten, applications may already be sending traffic — background sync, mail checks, update services. That traffic goes out in the clear, from your real address. This is why the advice to connect before you use the network is not fussiness.
During a reconnect. Networks drop; tunnels re-establish. The window between the old tunnel failing and the new one being ready is the same exposure as above, and it recurs every time you move between networks or your device wakes up. A kill switch exists specifically to block traffic during that window, and VPN leaks and kill switches covers what it does and does not cover.
Incomplete route coverage. If the routing changes handle IPv4 but not IPv6, or miss some destinations, part of your traffic quietly bypasses the tunnel while the client reports success.
DNS that ignores the reconfiguration. Some applications and some operating system components resolve names through paths that the client’s DNS changes do not capture.
What this tells you about evaluating clients
The protocol name on the marketing page is the least interesting part. Two clients using the same protocol can behave completely differently at connection time, and the differences are exactly the ones that determine whether you are protected in practice — which is the argument in why protocol choice matters less than you think.
What to look for instead: whether the client blocks traffic until the tunnel is established rather than only after a drop; whether it handles IPv6 explicitly; whether it reconnects predictably when the underlying network changes; and whether its behaviour is documented rather than implied.
And then verify it once yourself, rather than assuming. The mechanism overview explains why every property of a VPN follows from this one arrangement — including its failure modes.