DNS, WebRTC and IPv6 Leak Tests: What They Mean for VPN Privacy

Overview

A VPN is meant to hide your real network identity from the sites and services you use. In practice, that means more than changing the visible IPv4 address. Modern devices and browsers make several network decisions in parallel. If those decisions are not fully routed through the VPN, information can escape in ways that matter for privacy, access control and troubleshooting.

The three leak types most people should test are:

• DNS leaks: your device sends domain lookups to your ISP or another resolver outside the VPN instead of the VPN provider’s DNS service or the secure resolver you intended to use.
• WebRTC leaks: the browser exposes local or public IP details through WebRTC mechanisms used for real-time communication. This can reveal more than you expect even when the VPN is connected.
• IPv6 leaks: your IPv4 traffic goes through the VPN, but IPv6 traffic is not tunnelled or is only partly handled, revealing your real IPv6 address or network path.

These are different problems, so the fix depends on what leaked. A DNS leak does not automatically mean WebRTC is leaking. An IPv6 leak does not always mean the VPN is broken; sometimes IPv6 is simply unsupported by the VPN app or disabled in one layer but not another. The safest approach is to test each area separately and record the results.

For developers, IT admins and privacy-minded users, this matters beyond personal browsing. Leak behaviour can affect geo-routing tests, remote access policies, incident response, split tunnelling decisions and whether a VPN setup is suitable for public Wi-Fi or sensitive client environments. If you are comparing providers, leak handling is part of any serious VPN comparison, not a minor checkbox.

One useful boundary to keep in mind: leak testing does not prove a provider’s VPN no logs policy. It only tells you whether traffic and metadata appear to be leaving your device through the paths you expect.

Step-by-step workflow

Use this workflow in order. It is designed to isolate variables so you can tell whether the leak is coming from the VPN app, the browser, the operating system or your network setup.

1. Start with a clean baseline

Before connecting the VPN, note what your normal connection looks like.

• Record your current public IPv4 address.
• Check whether your network has native IPv6 connectivity.
• Note which DNS resolvers appear to be in use.
• Close browser tabs that may keep old sessions or WebRTC states alive.

This matters because you need a before-and-after comparison. Without a baseline, a test result may look suspicious when it is actually expected.

2. Connect the VPN app, not just the browser extension

For a full-device test, connect through the VPN application first. Browser extensions can be useful, but many of them only proxy browser traffic and do not protect the rest of the system. If your goal is end-to-end privacy on the device, test the native app connection first, then test the browser separately.

Pick a standard server location and keep it consistent while testing. Changing locations mid-process makes it harder to see whether a result changed because of a fix or simply because you connected somewhere else.

3. Run a DNS leak test

A DNS leak test asks a simple question: when your device looks up a domain name, whose resolvers are doing the work?

What you want to see is that DNS requests are handled by the VPN provider’s infrastructure or by the resolver you deliberately configured to run through the tunnel. What you do not want to see is your ISP’s resolver, your office resolver when you are on a personal session, or an unexpected third-party resolver that bypasses the tunnel.

If the test shows resolvers in the same country or region as your real connection rather than your VPN endpoint, investigate further. That can indicate:

• the VPN is not forcing DNS through the tunnel
• the OS is preferring another network adapter
• split tunnelling rules are excluding DNS
• the browser is using secure DNS independently of the system resolver

A result is not automatically a leak just because the resolver name is unfamiliar. Some VPN providers lease or white-label DNS infrastructure. The key question is whether the resolver belongs to your normal connection path or your VPN path.

4. Run a WebRTC leak test in each browser you use

WebRTC is browser-specific, so one browser can be well-behaved while another leaks more information. Test Chrome, Firefox, Edge and any Chromium-based browser separately if you use them for work.

In a WebRTC leak test, you are checking whether the browser exposes:

• your real public IP address
• your local private IP address
• the VPN-assigned address only

The most privacy-friendly result is that the browser exposes only the VPN-related address or no meaningful real-network identifier at all. If your real public IP appears, the VPN setup is not containing WebRTC exposure in that browser.

According to the source material, some browsers can experience WebRTC leaks even with a VPN active, and one practical mitigation is to use a VPN provider’s browser extension with WebRTC blocking enabled. In the cited support guidance, NordVPN notes that its browser extension for Chrome, Firefox and Edge includes a WebRTC blocking setting, enabled by default, and that you should not connect through the extension if you are already connected through the app. The evergreen lesson is broader than one vendor: browser-layer controls can help with WebRTC, but they should complement the main VPN connection rather than create overlapping sessions unless the provider explicitly supports that setup.

5. Run an IPv6 leak test

IPv6 is often where otherwise solid setups fail. Some VPN services tunnel IPv6 correctly, some disable it, and some leave it to the operating system or browser to work around. Your test should tell you whether your real IPv6 address remains visible while the VPN is connected.

Possible outcomes include:

• No IPv6 detected: often acceptable if the VPN disables IPv6 to prevent leaks.
• VPN-owned IPv6 detected: also acceptable if the provider supports IPv6 through the tunnel.
• Your real IPv6 detected: likely an IPv6 leak that needs fixing.

Do not assume that good IPv4 masking means IPv6 is safe. Many users never notice the issue because the websites they visit continue to work normally.

6. Repeat the tests after reconnecting

Disconnect the VPN, reconnect to the same server, and test again. Then try a different server in the same country. Intermittent leaks can point to DNS race conditions, adapter issues or inconsistent app behaviour rather than a simple setting.

7. Test your real use case

Once the standard tests look clean, test the scenario you actually care about:

• browser plus video call app
• corporate laptop with SSO and MFA agents
• public Wi-Fi with captive portal history
• split-tunnel business VPN
• streaming or geolocation-sensitive browsing

This is where many false assumptions appear. A VPN can pass a lab-style privacy check and still behave differently once split tunnelling, endpoint security tools or browser secure DNS features are active.

Tools and handoffs

The goal here is not to collect more tools than necessary. It is to know which layer owns the problem so you can apply the right fix or escalate it cleanly.

Browser layer

If only one browser shows a WebRTC leak, start there. Useful actions include:

• disable or restrict WebRTC exposure using browser settings or a trusted privacy extension
• install the VPN provider’s browser extension if it includes WebRTC leak blocking
• turn off browser-level secure DNS temporarily during testing to see whether DNS is bypassing the VPN path
• clear browser network state by restarting the browser fully

Be careful with stacking controls. For example, if a provider warns against connecting through both the app and extension at the same time, follow that guidance. Layering tools without understanding their traffic model can create confusing test results.

VPN app layer

If all browsers show the same issue, the VPN app or tunnel configuration is the likely owner. Check:

• whether DNS leak protection is enabled
• whether IPv6 handling is documented by the provider
• whether split tunnelling is active
• whether the kill switch is enabled and functioning as expected
• whether a protocol change alters the result

If you need a deeper refresher on tunnel behaviour, protocol choices can affect routing and reliability in subtle ways; see our guide to WireGuard, OpenVPN and IKEv2. And if you are diagnosing traffic escape during reconnects, our article on how a VPN kill switch works and when it fails is the next step.

Operating system layer

If the app looks correct but test results are inconsistent, inspect the OS. Common checks include:

• disable IPv6 temporarily to confirm whether IPv6 routing is the source of the leak
• review network adapter priority
• flush local DNS cache and renew network state
• check whether another VPN, proxy or endpoint agent is installed
• confirm whether per-app routing or enterprise policies are overriding the tunnel

For managed devices, the handoff may belong to desktop engineering or endpoint management rather than the VPN vendor.

Network and policy layer

In business environments, a result that looks like a leak can be an intentional policy choice. Split DNS, internal resolvers, secure web gateways and remote access policies may direct some requests outside the full tunnel for performance or control reasons. That is not necessarily wrong, but it should be documented and understood.

If you run a business VPN or secure remote access stack, hand off the evidence in a structured way:

• device and OS version
• VPN app version
• browser and version
• server location tested
• protocol used
• screenshots or text output from DNS, WebRTC and IPv6 tests
• whether split tunnelling, secure DNS or endpoint protection was enabled

This shortens the path to a useful answer. It also helps when deciding whether a traditional VPN is still the right model or whether a more granular approach makes sense; our explainer on ZTNA vs VPN is relevant when remote access requirements have become too complex for one-size-fits-all tunnelling.

Quality checks

A leak test is only useful if you interpret it carefully. These checks help avoid false positives and false confidence.

Check for browser secure DNS

Modern browsers may use their own DNS-over-HTTPS settings. That can make a DNS leak test look odd even though the traffic is encrypted. From a privacy perspective, the question is still whether DNS resolution follows the path you intended. If your browser is using a resolver outside your VPN plan, the result may not match your threat model.

Understand local IP exposure in WebRTC

Some WebRTC tests show private local addresses such as 192.168.x.x or 10.x.x.x. That is not the same as exposing your real public IP. For many users, the more serious issue is whether the browser reveals the real public IP or a routable address tied to the local network. Distinguish between the two before declaring failure.

Test with and without split tunnelling

Split tunnelling is a common source of confusion. If enabled, some applications may route outside the tunnel by design. Repeat the test with split tunnelling off. If the leak disappears, you have found the likely cause.

Reconnect and change protocol

If one protocol leaks and another does not, the problem may sit in the app’s implementation rather than your browser. That is one reason protocol testing belongs in a serious VPN privacy workflow, not just in speed benchmarks.

Use the same browser profile for comparison

Extensions, privacy settings and developer flags can all change results. Test with the same profile before and after each fix. Otherwise you may attribute the improvement to the wrong change.

Do not confuse a masked IP with complete privacy

A clean DNS, WebRTC and IPv6 result is good, but it is not the whole story. Cookies, browser fingerprinting, account logins and application telemetry can still identify you. Leak testing verifies tunnel hygiene, not complete anonymity. That is why it pairs well with broader privacy habits and with provider due diligence around logging and infrastructure.

When to revisit

Leak testing should not be a one-off task. Revisit it whenever the underlying platform changes or your use case changes. At a minimum, rerun the workflow when any of the following happens:

• your VPN app receives a major update
• your operating system changes version
• your main browser updates or resets privacy settings
• you enable split tunnelling, secure DNS, a new protocol or a browser extension
• you move from home broadband to public Wi-Fi or mobile tethering as a regular workflow
• your organisation changes remote access policy, endpoint tooling or DNS controls

A practical maintenance routine looks like this:

1. Keep a simple test log with date, device, VPN version, browser version and server used.
2. Run DNS, WebRTC and IPv6 tests after major updates.
3. If something changes, roll back one variable at a time until the cause is clear.
4. Document any accepted exceptions, especially in business environments using split DNS or hybrid access models.
5. Escalate with evidence rather than a general statement that the VPN is “leaking”.

If you are evaluating providers, add leak handling to your shortlist criteria alongside speed, pricing and platform support. This is especially relevant for users comparing the best VPN UK options for public Wi-Fi, streaming or business use. A service can be fast and still handle DNS or IPv6 poorly on the platforms you rely on.

The simplest takeaway is this: test the browser, test the tunnel, test IPv6 separately, and retest after changes. That process is more reliable than any marketing claim and more durable than chasing one-off settings guides. When tools evolve, the workflow still holds.