What Is a VPN Leak?

01 / Definition

What is a VPN leak?

A VPN leak happens when traffic or network information that should be protected by the VPN unexpectedly bypasses the intended VPN route or becomes visible through an interface the VPN policy was meant to block.

Depending on the leak, this may expose:

• your normal public IPv4 address;
• a public IPv6 address from your regular connection;
• DNS queries or an unintended DNS path;
• network information exposed through WebRTC/ICE;
• or traffic sent over the normal connection during VPN startup, failure, or reconnection.

The words “supposed to be protected” matter. Full-tunnel and split-tunnel VPNs have different routing policies. In a split tunnel, some traffic is intentionally sent outside the VPN. That is expected behavior, not a leak, unless the traffic bypasses the policy unintentionally.

02 / Quick answer

Quick answer

Checking only the browser’s visible IPv4 address is not enough. It validates one path used by that browser request; it does not prove that every application, protocol, address family, or DNS flow on the device follows the same route.

03 / Model

How a VPN is supposed to work

Without a VPN, a simplified internet path looks like this:

Your connection uses one or more source addresses. A public website sees the public source address that reaches it. On a typical consumer connection, that may be an address assigned to your router or a shared public address used by your ISP through carrier-grade NAT.

With a full-tunnel VPN, the expected path for covered internet traffic looks more like:

The VPN client normally installs or changes routes so that matching traffic is sent to a virtual or logical VPN interface. The VPN protocol encapsulates that traffic and carries it to the VPN gateway. The gateway then decapsulates and forwards the traffic toward its destination.

A VPN does not make you invisible. Websites can still recognize you through accounts, cookies, browser storage, device signals, and other identifiers. HTTPS remains important too: the VPN protects the tunnel between your device and the VPN endpoint, while HTTPS protects the browser-to-website connection end to end, including beyond the VPN endpoint.

The useful engineering question is not simply whether the VPN is connected, but whether each traffic class follows the routing and security policy you intended.

04 / Policy

Full tunnel vs. split tunnel: the policy comes first

A full-tunnel VPN usually makes the VPN interface the preferred route for internet traffic, except in the cases where access to the VPN gateway itself is required or where traffic to the local network has been deliberately allowed.

A split-tunnel VPN is set up so that only certain destinations, applications, or types of traffic are sent through the VPN, while the rest use the physical interface. Microsoft’s Windows VPN documentation makes the same distinction: split tunneling uses specific VPN routes, while force tunneling installs VPN default routes so traffic normally prefers the VPN unless a more specific route or configured exclusion applies.

That means a leak test cannot be interpreted correctly until you know the intended policy. A packet outside the tunnel is a leak only if it violates that policy.

05 / Leak type

IPv4 leak

Related tool: IP Lookup — inspect the network, ASN and registration behind any address you observe.

An IPv4 leak happens when the regular public IPv4 address continues to be used for data which you intended to send through the VPN.

For example, suppose your baseline test shows:

Public IP: 203.0.113.25

After connecting to the VPN, the browser shows:

VPN IP: 198.51.100.44

Both addresses come from RFC 5737 documentation ranges, so they are safe examples rather than real user addresses.

When a full-tunnel VPN is functioning as it should for that browser request, the destination should usually observe the VPN-side egress address rather than the baseline ISP-side address.

What an IPv4 leak can reveal

A public IP address can often be associated with:

• an internet service provider or hosting provider;
• an autonomous system (ASN);
• a country or approximate geographic area;
• and the network from which a connection originated.

It typically does not reveal an exact home address on its own. IP geolocation databases are estimates, and a wrong city or country label can be a database error rather than proof of a VPN leak.

A baseline IP is not always stable

Do not rely only on exact string equality. Consumer IPv4 addresses can be dynamic, and some connections use carrier-grade NAT. If the baseline address changes between tests, compare the network owner or ASN, the expected VPN provider, the route behavior, and the address itself.

Common causes of IPv4 leaks

• incorrect or missing routes;
• VPN software malfunction;
• a reconnect or interface transition;
• intentional or accidental split tunneling;
• conflicting network adapters or virtual interfaces;
• another proxy/VPN/security product changing routing;
• or a fail-open state after the VPN disconnects.

06 / Leak type

DNS leak

Related tool: DNS Leak Test — observe which resolver actually answered a query made from your browser.

DNS resolves domain names into records a client can use to reach internet services. A device may use an ISP resolver, a public resolver, an enterprise resolver, a VPN-provided resolver, or an encrypted DNS service.

A technically useful DNS leak definition has two separate questions: which resolver handles the query, and which network path carries the DNS request to that resolver.

Those are not the same thing.

If your VPN is configured to carry DNS through the tunnel and your DNS requests unexpectedly go directly through the normal ISP interface, that is a genuine routing or DNS policy problem.

Why DNS leaks matter

DNS queries contain the domain names your device asks to resolve. They do not contain the full contents of an HTTPS session, but unexpected DNS routing can still reduce the level of privacy you expected from the VPN.

Encrypted DNS changes how results should be interpreted

DNS over HTTPS (DoH) carries DNS queries inside HTTPS. A browser can therefore use a third-party DoH resolver while the underlying HTTPS connection still travels through the VPN tunnel. In that case, the resolver may differ from the VPN provider even though the DNS traffic did not bypass the VPN at the IP-routing layer.

The reverse is also true: reaching the ‘expected’ resolver does not prove that the request took the intended path. Resolver identity alone is not enough to diagnose a leak.

For a full treatment of resolver identity versus transport path, encrypted DNS (DoH and DoT), split DNS and how to test correctly, see What Is a DNS Leak?

An important DNS testing mistake

Seeing a DNS provider different from your VPN company does not automatically prove a DNS leak.

Legitimate explanations include:

• browser-level encrypted DNS;
• operating-system custom DNS;
• enterprise DNS policy;
• a VPN provider using third-party resolver infrastructure;
• resolver forwarding, anycast, or a test that reports the recursive resolver’s egress rather than the identity of the resolver configured on your device.

The more appropriate question is this: “Does the DNS behavior conform to the policy I configured, and does the DNS transport itself remain on the desired network path?”

07 / Leak type

IPv6 leak

IPv4 and IPv6 have separate systems for addressing and routing; it is therefore possible for a VPN to properly handle one address family while dealing incorrectly with the other.

For instance, if the VPN sets up an IPv4 default route without touching the native IPv6 configuration, it is possible to reach an IPv6-capable destination from outside the VPN.

A situation is known as an IPv6 leak when a publicly routable IPv6 path is still available even though the VPN policy was intended to tunnel or block it.

Not every IPv6 address shown by a test is a leak

IPv6 link-local addresses (FE80::/10) are limited to a local link. Unique Local Addresses (FC00::/7; locally assigned ULAs normally use FD00::/8) are intended for local communication rather than normal global Internet routing. Their presence alone is not evidence that your public IPv6 identity escaped the VPN.

What matters is whether a globally routable IPv6 address or route associated with the regular connection remains usable for traffic that should be protected.

How to recognize an IPv6 leak

Test without the VPN first and record whether public IPv6 connectivity exists. Then connect to the VPN and repeat the test.

A suspicious result is not simply “an IPv6 string appeared.” It is a public IPv6 path that maps to the non-VPN connection, even though the VPN was expected to handle IPv6.

A VPN may deal with IPv6 in different ways. It may:

• tunnel IPv6;
• provide a VPN-side IPv6 egress;
• block native IPv6 while connected;
• or explicitly leave IPv6 outside the tunnel as part of its documented policy.

If the product promises full IPv4/IPv6 protection, native public IPv6 bypass is a leak. If the product explicitly blocks IPv6 and no public IPv6 route remains, the absence of a VPN IPv6 address is not itself a failure.

For dual-stack routing tables, address classification and how to verify the IPv6 path, see What Is an IPv6 Leak?

08 / Leak type

WebRTC leak

Related tool: WebRTC Leak Test — read the ICE candidates your browser gathers and compare the public-facing address.

WebRTC allows for real-time communication within browsers and applications, and in order to set up peer-to-peer connectivity it usually makes use of Interactive Connectivity Establishment (ICE).

ICE does not use a single general “WebRTC IP”; instead it collects candidate transport addresses, the main types of which are host, server-reflexive, peer-reflexive, and relayed candidates.

What those ICE candidates mean

• Host candidate – an address associated with a local physical or logical interface, including a VPN interface.
• A server-reflexive candidate is an address that is obtained as a result of NAT traversal, usually by means of STUN.
• A peer-reflexive candidate is an address that has been found as a result of ICE connectivity checks.
• Relayed candidate – an address that is assigned on a TURN relay server.

This is important since a WebRTC test can show a number of different types of network information; a private host address is not the same as your ISP-facing public address, and a TURN relay address is not your actual public address.

What is a WebRTC leak?

A meaningful failure in the context of VPN testing is when WebRTC reveals or actually makes use of a public candidate/path that is associated with the normal interface, even though the browser’s traffic was meant to be restricted to the VPN path.

The IETF guidance for WebRTC states that WebRTC should generally adhere to normal IP routing and use the kernel routing table; it also acknowledges the privacy concern associated with revealing additional candidates and includes modes that restrict the interfaces or candidate classes made available.

Hence, you should not treat every private address, local candidate, or unfamiliar ICE entry as a VPN leak.

For the full ICE candidate classification, STUN vs. TURN, and how to read each result, see What Is a WebRTC Leak?

09 / Leak type

Fail-open, disconnect, and reconnect leaks

A VPN may pass a steady-state leak test and still expose traffic during a state change. Operationally, this is one of the most important failure modes to test.

Typical trigger events include:

• VPN process or tunnel failure;
• switching Wi-Fi networks;
• Wi-Fi to Ethernet or mobile-hotspot transitions;
• sleep and wake;
• server handover or protocol renegotiation;
• starting the device before the VPN is ready.

If ordinary traffic switches back to the physical interface when any of these things occur, the connection is said to be operating in fail-open mode. A kill switch or a firewall policy is meant to cause the protected traffic to fail closed instead.

What is a VPN kill switch?

A kill switch is intended to stop protected traffic from automatically switching over to the regular internet route when the VPN is no longer available.

A simplified sequence is:

1. You establish a connection to the VPN.
2. The VPN route is used for protected traffic.
3. The tunnel unexpectedly drops.
4. If there is no fail-closed control, the operating system could once more choose the normal interface.

The specific details of implementation differ: some VPN programs enforce the kill switch using the operating system’s firewall or packet-filtering rules, while others rely on platform-specific routing or network controls. However, the label ‘kill switch’ is of less importance than the actual behavior, which is that protected traffic should not escape during the failure period.

A kill switch does not replace leak testing

The kill switch is primarily concerned with failover behavior and does not on its own verify that DNS, IPv6, WebRTC, or the split-tunnel policy is correct while the VPN is connected.

Check the steady-state routing as well as the transitions, for example disconnect, reconnect, sleep/wake, and network switching.

10 / Interpretation

Not every packet outside the VPN is a privacy leak

It is not true that a full-tunnel VPN necessarily encloses every frame or local control packet produced by the device; local networking still requires procedures such as ARP for resolving IPv4 neighbour addresses, NDP for IPv6, and usually DHCP in order to get network configuration. Additionally, some VPN clients intentionally permit LAN discovery so that printers, casting devices, or local servers can remain accessible.

Those packets are not automatically “VPN leaks” because they are not ordinary Internet traffic being routed around the tunnel. The correct test is whether Internet-bound traffic or protected data violates the VPN’s stated routing policy.

11 / Causes

Why do VPN leaks happen?

A VPN client is only one part of the networking stack. Routing tables, interface metrics, address-family behavior, DNS policy, browser networking, firewall rules, and virtual adapters all affect the final path.

Common causes include:

Split tunneling or exclusion rules

Split tunneling can be route-based, application-based, destination-based, or implemented by a product in another policy-specific way. A deliberately configured bypass is not a leak. A bypass caused by a missing or incorrect policy is.

Incorrect routing

The tunnel can still be set up even though the best route still indicates the physical interface for some destinations or address families, because route priority, prefix specificity, and platform policy are all relevant.

DNS policy conflicts

The operating system, browser, enterprise policy, VPN client and security software can all influence DNS. Conflicting settings can create surprising results even when the IP tunnel itself is healthy.

Incomplete IPv6 handling

The fact that IPv4 routing is correct does not mean that IPv6 routing is also correct, and dual-stack systems need both address families to be evaluated.

Network changes and multihoming

Laptops and phones may have one or more active or recently active interfaces, such as Ethernet, Wi-Fi, cellular, virtual adapters, and VPN interfaces, and the route selection can change whenever an interface appears or disappears or when it receives a new metric.

Multiple VPNs, proxies, security agents, or virtual adapters

Products that alter routes, DNS, packet filters, or proxy settings can conflict with one another. Adding more security software does not automatically make the network path more private.

12 / Method

How to test for a VPN leak properly

The most useful method is a controlled before-and-after comparison. Start with the baseline, then change one variable: connect the VPN.

Step 1: Disconnect the VPN and establish a baseline

Use the same physical network you plan to test. Record:

• public IPv4;
• public IPv6 connectivity and address, if available;
• ISP/network owner or ASN;
• DNS behavior/resolvers;
• WebRTC/ICE results.

When your public IP address is dynamic, make a note of the network owner/ASN and the address since this makes the baseline more resilient to a change of address.

Step 2: Connect the VPN

Make sure that you are connected to the server and mode that you really want to use and verify the product’s setting regarding full-tunnel, split-tunnel, browser-only protection, or some other scope.

Step 3: Repeat each test

Check IPv4, IPv6, DNS, and WebRTC again. Compare actual values rather than relying only on a green “safe” badge.

Step 4: Interpret each layer separately

• Does the browser’s IPv4 request exit through the expected VPN egress?
• Is there a public non-VPN IPv6 route when the VPN policy says there should not be?
• Which DNS resolver handles the query, and does the DNS transport use the intended path?
• Do the public ICE candidates correspond to the VPN route or to the regular connection?
• During a failure, is protected traffic still blocked when the tunnel is unavailable?

Step 5: Test state changes

After a VPN has reconnected, following a sleep and wake cycle, and when possible, after a network transition, the checks should be repeated since many routing faults are intermittent and only appear when the interfaces change.

Step 6: Remember the scope of a browser-based test

A website can observe traffic generated by the browser and browser-exposed APIs. It cannot, by itself, prove that every background service, desktop application, or process on the device uses the same route. A browser test is therefore a strong user-level check, but not a complete host-wide packet audit.

13 / Engineering

Advanced verification for engineers

If you need to distinguish a UI anomaly from a real routing problem, inspect the operating system directly. Commands differ by platform and VPN product, but these checks are useful starting points.

Windows

• Use route print to examine the IPv4 and IPv6 routing tables and VPN-related prefixes.
• Use Get-NetIPConfiguration to review interfaces, addresses, gateways, and DNS configuration.
• Use Get-DnsClientServerAddress to inspect DNS servers configured per interface.
• Use Test-NetConnection 1.1.1.1 -InformationLevel Detailed to inspect the selected interface and source address for a test destination.

route print
Get-NetIPConfiguration
Get-DnsClientServerAddress
Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Linux

• Use ip -4 route to inspect IPv4 routes.
• Use ip -6 route to inspect IPv6 routes.
• Use ip route get 1.1.1.1 to see which IPv4 route and source address the kernel would choose.
• Use resolvectl status to inspect per-link DNS and systemd-resolved configuration where available.

ip -4 route
ip -6 route
ip route get 1.1.1.1
resolvectl status

macOS

• Use netstat -rn to inspect the routing table.
• Use route -n get 1.1.1.1 to inspect the selected route for a destination.
• Use scutil --dns to inspect DNS resolver configuration, including scoped resolvers.

netstat -rn
route -n get 1.1.1.1
scutil --dns

For a host-wide investigation, packet capture together with routing and firewall inspection provides stronger evidence than a browser-only result. Capture only traffic you are authorized to inspect, and avoid recording sensitive data unnecessarily.

14 / Interpretation

How to read VPN leak test results

Good sign: the browser’s public IP changes to the expected VPN egress

This shows that the browser request being tested is exiting through the expected VPN path. Continue with IPv6, DNS, WebRTC, and failure-state testing.

Suspicious: the original public IPv4 remains visible

If full-tunnel browser traffic was expected, investigate routing, split tunneling, proxy settings, VPN exclusions and other network software.

Suspicious: a public baseline IPv6 remains usable

This is meaningful only when it is a public/global Internet path associated with the normal connection and the VPN policy was expected to tunnel or block it. Link-local or private/local IPv6 entries should not be treated the same way.

Needs interpretation: unfamiliar DNS servers

Do not diagnose a leak from resolver branding alone. Check the DNS transport path, the browser’s DoH settings, the operating system’s DNS configuration, the VPN’s documentation, and whether the resolver is reached through the VPN path.

Needs interpretation: WebRTC shows several addresses

Classify the candidate first. A local/private host candidate, a server-reflexive public candidate, and a TURN relay address represent different things. The critical question is whether a public non-VPN path is exposed or selected in violation of policy.

Not proof of a leak: VPN IP geolocation looks wrong

The geolocation databases used by VPN servers may be out of date or inconsistent. In most cases, this is a problem with the geolocation data rather than a routing leak if the address in question belongs to the expected VPN network but the location database identifies it as being in a different city or country.

15 / Fixes

How to fix a VPN leak

The solution will vary according to the layer that is not working properly. Do not alter five settings at the same time; instead, change one variable at a time, retest, and keep a record of the changes made.

If your normal IPv4 route leaks

1. Check if the full tunnel is actually enabled.
2. Review split-tunnel and app-exclusion rules.
3. Reconnect and attempt another VPN server.
4. Check the routing table and the default routes.
5. Check for another VPN, proxy, endpoint-security agent, or virtual adapter changing route selection.
6. Make sure the VPN client and the operating system are updated.
7. If the leak happens only when there is a failure, then check the kill-switch/fail-closed setting.

If DNS behavior is wrong

• Confirm the VPN’s intended DNS policy.
• Check the browser’s DoH or secure-DNS settings.
• Check the DNS settings of the operating system for each interface.
• Review any enterprise or security software that enforces DNS policy.
• Change one variable at a time, then test again.

If IPv6 leaks

Start by establishing the product’s IPv6 design. The appropriate remedy varies depending on whether the VPN supports dual-stack tunneling, whether it deliberately blocks IPv6, or whether it explicitly does not protect IPv6; blindly turning off IPv6 should be avoided unless that is the provider’s supported design or you are aware of the operational trade-offs.

If WebRTC exposes a non-VPN public path

• Confirm that the browser is covered by the VPN policy you expect, such as full-tunnel mode when appropriate.
• Update the browser and VPN client.
• Try a different browser in order to distinguish between browser policy and host routing.
• Review product-specific WebRTC or privacy settings.
• Do not treat every local candidate as a leak; check the public candidate and its path first.

If leaks occur only during transitions

• Enable the fail-closed or kill-switch control and test it.
• Check the cold start, reconnect, sleep and wake, and network changes.
• Verify that the client does not temporarily remove fail-closed firewall rules or restore an unprotected default route during renegotiation.
• Verify that traffic intentionally excluded by split tunneling still behaves as designed.

16 / Common questions

Does a VPN leak reveal your exact location?

Usually not. A public IP address can often be associated with an ISP, ASN, country, region, or approximate network area, but IP geolocation should not be treated as GPS-level positioning.

A VPN leak can still be important since even if the location estimate is inaccurate, revealing the original network or Internet service provider may still undermine the privacy objective.

Does a VPN leak reveal your browsing history?

Not automatically. An IP leak exposes a network identity or route. A DNS leak may expose domain-resolution activity to the resolver or to an observer on that DNS path. Neither means that a leak instantly reveals everything you do online.

Encrypted DNS changes who can observe the DNS exchange, while HTTPS separately protects the web session between the client and the website. These layers should be discussed independently.

Can a VPN leak your IP while saying “Connected”?

Yes, it is possible for a client to set up a tunnel interface or a VPN session when a route, DNS policy, IPv6 path, or application exclusion differs from your intention.

The ‘Connected’ state is a control-plane signal. Correct forwarding is a data-plane outcome, and that is what leak testing verifies.

Is split tunneling a VPN leak?

Not when it is intentional. Split tunneling deliberately sends some traffic through the VPN and other traffic through the normal route.

The engineering mistake is calling every bypass a leak without first checking the routing policy. A bypass becomes a leak when it is unintended or outside the defined policy.

Is browser geolocation a VPN leak?

Not necessarily. A VPN changes network routing, but it does not automatically change GPS data, browser location permissions, Wi-Fi-based positioning, or saved location information.

A website may therefore still determine your real location if you grant precise-location access or if another non-IP location signal is available, even while the VPN tunnel is working correctly. That is a separate privacy issue, not evidence of an IP-routing leak.

Are cookies a VPN leak?

No. Cookies, login sessions, and local browser storage can recognize you after your IP changes. That does not prove that the VPN exposed your original address.

Why your time zone can still reveal your region

Changing your public IP address does not mean that your device’s time zone will automatically change too; a website can observe that the VPN exit is located in one country while the browser’s time zone indicates another.

It is a fingerprinting or consistency signal, not a VPN route leak.

VPN browser extension vs. full VPN app

A browser ‘VPN’ extension may operate as an HTTP or SOCKS-style proxy, or it may protect only browser traffic, depending on the product. A native VPN client usually operates lower in the operating system’s network stack and can cover more applications.

If a desktop application uses the normal interface while only a browser extension is enabled, that is not automatically a leak. It may simply be outside the extension’s advertised scope.

When should you test your VPN?

Test after changes that can affect networking, including:

• installing a new VPN;
• changing VPN protocols or servers;
• operating-system or VPN-client updates;
• changing DNS settings;
• enabling split tunneling;
• installing another security/network product;
• switching networks;
• router changes;
• unexpected IP or DNS results.

17 / Checklist

VPN leak testing checklist

18 / FAQ

Frequently asked questions about VPN leaks

19 / Summary

The bottom line

A VPN leak is not simply “a VPN that does not work.” It is a mismatch between the network behavior you expected and the path the traffic actually takes.

That is why a reliable test starts with a baseline and checks multiple layers.

• IPv4 routing;
• public IPv6 routing;
• DNS resolver and transport behavior;
• WebRTC/ICE candidates;
• split-tunnel policy;
• disconnect and reconnect behavior.

If you remember one principle, use this one: establish the intended policy first, then verify each path against it. A green “Connected” status is not a packet-level test.

If you want to verify your current connection, run a VPN leak test while disconnected, record the baseline, reconnect the VPN, and compare the results before concluding.

20 / References

Technical references

RFC 5737

IPv4 Address Blocks Reserved for Documentation

RFC 8445

Interactive Connectivity Establishment (ICE)

RFC 8828

WebRTC IP Address Handling Requirements

RFC 8826

Security Considerations for WebRTC

RFC 8484

DNS Queries over HTTPS (DoH)

RFC 4291

IPv6 Addressing Architecture

RFC 4193

Unique Local IPv6 Unicast Addresses

RFC 1918

Address Allocation for Private Internets

Microsoft Learn

VPN routing decisions

Microsoft Learn

Test-NetConnection