VPN Leak Check

A VPN makes one promise that is easy to state and easy to test. The websites you visit should see the address of the VPN’s exit, not the address your internet provider gave you. Everything else people hope a VPN does, from hiding which sites they visit to keeping a browser from describing their home network, rests on whether that promise holds for every path traffic can take. Most of the time it holds for the obvious path and quietly fails for one of the others.

There are three places an address can slip out: the tunnel itself, WebRTC, and DNS.

What any website sees

The first path is the plainest. When your browser opens a page, the server at the other end receives packets from some address, and that address belongs to a network with a number and an owner. The network that carries this site puts the visitor’s address in a request header called CF-Connecting-IP and attaches facts about the request: the autonomous system number, the organisation that owns it, the country, the data center that took the request, and a few more. A website does not have to guess any of this. It is handed over with every request, whether or not the site chooses to show it to you.

That is why the first card on this page is the most reliable of the three. It asks this site’s own server what it saw for this one request and prints the answer: the address, the owner of the network, and the place the network says it is. The server keeps nothing. The answer goes back to the browser that asked, marked so that no cache stores it, and is forgotten.

What turns this into a verdict is your expectation. With the VPN switched on, the owner should be the VPN provider. If the server sees the same network as your home connection, the VPN is not carrying this traffic, whatever its icon says. The tool can make that comparison in two ways. You can type a word or two of the provider’s name, or you can run the check once with the VPN off, save that result as home, switch the VPN on and run again. The second way is stronger, because it compares two measurements rather than a measurement and a name.

The address WebRTC can show

The second path surprises people. WebRTC lets a browser make direct audio, video and data connections, and to find a route through home routers it gathers candidate addresses. The IETF’s ICE specification names the kinds: a host candidate is an address on one of the computer’s own interfaces, a server reflexive candidate is the address a router mapped the packet to on its way out to a STUN server, and a relayed candidate comes from a relay server. MDN’s reference for the browser interface lists the same types under the short names host, srflx, prflx and relay.

The server reflexive candidate is the interesting one. A STUN server’s whole job, in the words of its own specification, is to tell the client which address and port it saw a request arrive from. If the browser sends that request outside the tunnel, the STUN server sees your real internet address and the browser hands it to the page.

The IETF wrote this risk down plainly. RFC 8828 notes that with a split tunnel, where the operating system can route over more than one interface, WebRTC can discover not only the VPN’s public address but also the provider address underneath it. It also notes that host candidates can expose private addresses from inside a home network, the ranges that RFC 1918 sets aside for private use.

The same document defines 4 modes of behaviour, from using every interface to forcing all media through a proxy. In the stricter modes the browser follows the default route, the same one its web traffic takes, and that is usually the tunnel. Browsers also learned to hide local addresses behind random names: a host candidate written as a long identifier ending in .local is the browser keeping your local address to itself, a technique described in an IETF draft on multicast DNS candidates.

So the WebRTC card does one specific comparison. It takes the server reflexive addresses from the gathering and compares them with the address this site’s server saw. If they are the same, WebRTC agrees with the tunnel. If they differ while the VPN is on, something is leaving by another road, and the card says so. It compares the server reflexive address and not a host address, because a host address is usually private and says nothing about which network carries your traffic to the outside.

To ask, the page has to use one STUN server, and it names it before you press anything: stun.cloudflare.com, on port 3478. Its operator’s documentation states that this STUN service is free and unlimited. The peer connection is closed as soon as gathering ends.

Why DNS needs your help

The third path is the one most leak tests are named after, and it is the one a website is worst placed to see. Before your browser can open a page, something has to turn the name into an address. That something is a resolver, and whoever runs it learns every name you look up. If the VPN is on but name lookups still go to your provider’s resolver, the provider still sees where you are going, even though the pages themselves travel through the tunnel. A reference article on the problem describes exactly this pattern and ties it to setups where traffic can still use the local interface.

Here is the honest part. A web page cannot ask your operating system which resolver it uses. A complete DNS leak test needs a name server under the tester’s control that records which resolver asks for a unique, freshly made name. This site does not run such a name server, so it cannot run that test, and the page says so at the top rather than pretending.

What you can do instead takes about a minute. Some names answer with the address of the resolver that asked for them. A TXT query for o-o.myaddr.l.google.com is the best known; operators on the DNS-OARC mailing list point to it for exactly this question, and the result is easy to check by hand. You run the query in a terminal or command prompt with the command the tool shows for your system, paste the output, and the tool reads it.

Sometimes the answer has a second line. Resolvers that support EDNS Client Subnet pass part of your address along so that the name server can pick a nearby answer. RFC 7871 describes the option and asks resolvers to cut the address down for privacy: 24 bits for IPv4 and 56 bits for IPv6. Published guidelines for name servers that receive it describe how the source prefix and the scope are meant to be used. When that line appears, it shows which network your query really came from, and the tool checks whether that subnet holds the address the server saw.

When there is no subnet line, the comparison is weaker, and the tool labels it so. It can tell whether the resolver sits in the same address block as your tunnel exit, which is what you see when a VPN runs its own resolver. It cannot tell who owns a resolver address on another network. A public resolver and your provider’s resolver look the same from here, so a different network is reported as information, not as a leak.

Reading the example, and what to fix

The page opens on a finished example built from documentation addresses, the blocks that RFC 5737 reserves so that no real host is ever named. Home was saved as 198.51.100.23 on network AS64501. With the VPN on, the server sees 203.0.113.45, owned by AS64500, whose name matches the expected provider, so the tunnel card passes.

WebRTC tells a different story. Its server reflexive candidates include 198.51.100.23, the saved home address. That is a leak around the VPN, and the card shows a rounded square with a cross and the word Leak. In the 3D tunnel the middle gate becomes a ring with a wide gap. DNS is fine in the example: the pasted output names a resolver at 192.0.2.53 and a client subnet of 203.0.113.0/24, which holds 203.0.113.45, so queries left through the tunnel.

Fixes follow the path that failed. If the tunnel card fails, the VPN is off, disconnected, or excludes this browser; reconnect and check that it routes all traffic. If WebRTC fails, look for the VPN client’s leak protection or a browser setting that keeps WebRTC on the default route, which is the behaviour RFC 8828 describes for its stricter modes. If DNS fails, set the VPN to use its own resolver, or use encrypted DNS through DNS over HTTPS or DNS over TLS, both IETF standards, so that a resolver you chose is the one that answers.

Run the check again after each change. A result you can repeat is worth more than one that looked right once.

What none of this can do is worth saying as plainly. These checks see one browser at one moment. They do not see other applications, other devices, or a VPN that drops for ten seconds later today. They also cannot judge whether the VPN provider itself deserves your trust, which no test of addresses can answer.