VPNSpotter

DNS and WebRTC leaks: how to test and what to do

When your VPN misbehaves: a systematic troubleshooting method, speed fixes ranked by impact, and a quarterly privacy audit.

9 min read

Why DNS and WebRTC leaks matter more than you think

Your VPN tunnel encrypts traffic and routes it through a remote server. Simple enough. But your browser and operating system have other ways to resolve domain names and establish connections — pathways that don't automatically respect your VPN's routing rules. A DNS leak sends your domain lookups to your ISP's resolver instead of your VPN's. A WebRTC leak exposes your real IP address to websites through browser APIs designed for peer-to-peer communication.

Both undermine the core promise of VPN use: that your ISP, network administrator, or websites you visit can't see what you're doing or where you are. DNS leaks reveal what sites you're visiting. WebRTC leaks reveal where you actually are, even while the rest of your traffic flows through the VPN.

Neither is hypothetical. Default browser configurations leak WebRTC on most platforms. Windows 10 and 11 actively try to use "smart multi-homed name resolution" that bypasses VPN DNS settings. These aren't edge cases — they're predictable failure modes you should check for.

Testing for DNS leaks

DNS leaks happen when DNS queries bypass your VPN tunnel and go directly to your ISP's DNS servers or public resolvers you've configured outside the VPN.

The five-minute test:

1. Connect to your VPN 2. Visit `dnsleaktest.com` or `ipleak.net` in your browser 3. Run the extended test (it queries multiple DNS servers) 4. Check the results against your VPN provider's expected DNS servers

What you're looking for: The DNS servers shown should belong to your VPN provider or their designated DNS infrastructure. If you see your ISP's name, Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), or any resolver you didn't intentionally configure through your VPN, you're leaking.

Reading the results:

  • DNS servers in the same country as your VPN exit point: Usually fine, but verify they're actually your provider's servers
  • DNS servers in your actual physical location: Definite leak
  • DNS servers belonging to your ISP: Clear leak
  • Mixed results (some VPN, some not): Partial leak, equally problematic
Some VPN providers operate their own DNS infrastructure. Others rent servers or use third-party DNS. Check your provider's documentation for the expected DNS server addresses or hostnames. Reputable providers (NordVPN, Mullvad, IVPN) publish this information in their knowledge bases.

The command-line verification:

Web-based tests can be manipulated by browser extensions or local DNS settings. For confirmation, use command-line tools.

On Windows (in PowerShell): ``` nslookup dnsleaktest.com ```

On macOS/Linux: ``` dig dnsleaktest.com ```

The "Server" line in the output shows which DNS resolver actually answered. Cross-reference that IP address with your VPN provider's DNS servers.

Fixing DNS leaks

Windows-specific fixes:

Windows 10 and 11 use "Smart Multi-Homed Name Resolution" by default. This feature sends DNS queries to all available network adapters simultaneously and uses whichever responds first. Your physical network adapter usually wins that race against the VPN's virtual adapter.

Fix it through Group Policy (Windows Pro/Enterprise): 1. Open `gpedit.msc` 2. Navigate to: Computer Configuration → Administrative Templates → Network → DNS Client 3. Enable "Turn off smart multi-homed name resolution"

For Windows Home editions without Group Policy, edit the registry: 1. Open Registry Editor (`regedit`) 2. Navigate to: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient` 3. Create a new DWORD value named `DisableSmartNameResolution` 4. Set value to `1`

Alternatively, most quality VPN clients now include a "DNS leak protection" setting that forces all DNS through the tunnel using firewall rules. Enable it, then retest.

macOS-specific approach:

macOS respects VPN DNS settings better than Windows by default, but third-party DNS settings (like manually configured DNS servers in System Preferences) can override VPN DNS.

Check your DNS configuration: 1. Open Terminal 2. Run `scutil --dns` 3. Look for "resolver #1" — it should show your VPN's DNS servers when connected

If you see multiple resolvers or non-VPN DNS servers taking precedence, the issue is usually manually configured DNS in System Preferences. Clear those settings and let the VPN configure DNS automatically.

Linux configuration:

Most Linux distributions use `systemd-resolved` or `NetworkManager` to manage DNS. Both can leak DNS outside the VPN tunnel if not configured correctly.

For systemd-resolved, check `/etc/systemd/resolved.conf` and ensure it's not forcing specific DNS servers that override your VPN's settings. The safer approach: configure your VPN client to use `update-resolv-conf` scripts or similar mechanisms that update `/etc/resolv.conf` when the connection establishes.

Universal solution: VPN with built-in DNS:

The simplest fix is using a VPN client that enforces its own DNS through the tunnel at the firewall level, not just by changing system settings. Look for clients that specifically advertise "DNS leak protection" and test after enabling it. If leaks persist, the implementation is inadequate.

WebRTC leaks explained

WebRTC (Web Real-Time Communication) is a browser API for peer-to-peer audio, video, and data sharing without plugins. It's how browser-based video calls work. To establish peer-to-peer connections, WebRTC needs to discover your device's actual IP addresses — both local network IPs and public internet-facing IPs.

The problem: WebRTC queries happen at the browser level, outside your VPN tunnel's control. Even with a VPN connected, websites can use JavaScript to trigger WebRTC discovery and learn your real IP address.

This isn't a theoretical vulnerability. Visit `browserleaks.com/webrtc` right now with your VPN connected. If you see your real public IP address listed under "Public IP Addresses" or "IP Addresses," you're leaking.

What WebRTC exposes:

  • Your real public IP (the one assigned by your ISP)
  • Local network IPs (192.168.x.x range, less concerning but reveals network topology)
  • Both IPv4 and IPv6 addresses if you have dual-stack connectivity
Unlike DNS leaks that reveal what you're visiting, WebRTC leaks reveal where you are — your actual geographic location and ISP. This defeats geolocation-based privacy entirely.

Testing for WebRTC leaks

Browser-based test (fastest):

1. Connect to your VPN 2. Visit `browserleaks.com/webrtc` 3. Scroll to the "Public IP Address" section 4. Compare the shown IPs against your real IP (check your real IP by disconnecting the VPN and visiting the same page)

If you see your actual ISP-assigned IP address while the VPN is connected, you're leaking through WebRTC.

Alternative test sites:

  • `ipleak.net` (includes WebRTC alongside DNS tests)
  • `ipx.ac/run` (focused on WebRTC)
  • `whoer.net` (comprehensive leak testing)
Run tests in multiple browsers. Firefox, Chrome, Edge, Brave, and Safari all implement WebRTC differently. A leak in one doesn't guarantee leaks in all.

Stopping WebRTC leaks

Firefox (most control):

Firefox gives you the most granular WebRTC controls through `about:config`.

1. Type `about:config` in the address bar 2. Search for `media.peerconnection.enabled` 3. Set to `false`

This completely disables WebRTC. You'll lose browser-based video calling functionality (Zoom, Google Meet, Discord in browser), but you'll prevent leaks entirely.

For a middle-ground approach that keeps WebRTC functional but limits IP exposure: 1. In `about:config`, search for `media.peerconnection.ice.default_address_only` 2. Set to `true`

This restricts WebRTC to only exposing the default local IP, not probing for all network interfaces.

Chrome and Chromium-based browsers:

Chrome doesn't provide native WebRTC controls. You need extensions:

  • WebRTC Leak Prevent (open source, minimal permissions)
  • uBlock Origin with WebRTC blocking enabled (Settings → Privacy → Prevent WebRTC from leaking local IP addresses)
Install one, enable WebRTC protection, then retest at browserleaks.com. If the extension works, your real IP won't appear.

Brave browser:

Brave includes built-in WebRTC protection. No extensions needed.

1. Open Settings → Privacy and Security 2. Under "WebRTC IP handling policy" select "Disable non-proxied UDP"

This forces WebRTC to use the VPN tunnel or fail, preventing leaks while keeping WebRTC functional for sites that need it.

Safari (macOS/iOS):

Safari has no built-in WebRTC controls and doesn't support extensions that can disable it on iOS. macOS Safari supports some extensions, but compatibility varies.

The only reliable solution: Use Firefox or Brave on macOS instead of Safari when privacy matters. On iOS, you're out of luck — WebRTC will leak regardless of VPN.

IPv6 leaks: the forgotten third leak

Most VPN discussions focus on DNS and WebRTC, but IPv6 leaks are equally problematic. If your internet connection has IPv6 enabled (increasingly common) but your VPN only tunnels IPv4 traffic, IPv6 requests bypass the VPN entirely.

Test for IPv6 leaks:

Visit `test-ipv6.com` with your VPN connected. If it reports an IPv6 address and that address traces back to your ISP rather than your VPN provider, you're leaking IPv6 traffic.

Fix IPv6 leaks:

Option 1: Use a VPN that fully supports IPv6 tunneling. Mullvad provides native IPv6 support. Others are catching up.

Option 2: Disable IPv6 on your device entirely.

On Windows: 1. Open Network Connections 2. Right-click your network adapter → Properties 3. Uncheck "Internet Protocol Version 6 (TCP/IPv6)"

On macOS: 1. System Preferences → Network 2. Select your network interface → Advanced → TCP/IP 3. Configure IPv6: Off

On Linux, it varies by distribution, but typically involves editing `/etc/sysctl.conf`: ``` net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 ```

Disabling IPv6 has minimal practical impact for most users today, though that's changing as IPv6 adoption grows.

Building a quarterly leak audit routine

Set a recurring calendar reminder every three months to check for leaks. Your setup changes — browser updates, OS updates, VPN client updates, new browser extensions. Each can introduce new leak vectors.

The 15-minute quarterly check:

1. Connect to your VPN 2. Test DNS: `dnsleaktest.com` (extended test) 3. Test WebRTC: `browserleaks.com/webrtc` 4. Test IPv6: `test-ipv6.com` 5. Test on each browser you regularly use 6. Document results (screenshot or note which tests passed)

If something that previously passed now fails, recent changes broke your configuration. Check for:

  • Browser updates that reset WebRTC settings
  • VPN client updates with new default settings
  • OS updates that changed DNS resolution behavior
  • New browser extensions interfering with leak protection

When to worry and when to shrug

Not every leak matters equally, depending on your threat model.

Critical leaks (fix immediately):

  • DNS leaks showing your ISP's resolvers while using VPN to evade surveillance or censorship
  • WebRTC leaks exposing real IP when your goal is anonymity or location masking
  • Any leak if you're in a jurisdiction where VPN use itself is restricted
Lower-priority leaks (fix when convenient):

  • IPv6 leaks if you're using VPN primarily for encryption on public WiFi (though still worth fixing)
  • WebRTC leaks showing VPN provider's IPs instead of the exit server IP (annoying but not revealing your identity)
The key question: Does this leak expose information you specifically intended to hide? If yes, it's critical. If it's a technical imperfection that doesn't compromise your actual use case, prioritize accordingly.

Key takeaways

  • DNS leaks send your browsing queries to your ISP instead of through the VPN — test with dnsleaktest.com and verify VPN provider DNS servers appear in results
  • WebRTC exposes your real IP address through browser APIs even with VPN connected — disable WebRTC in Firefox via about:config or use extensions in Chrome-based browsers
  • Windows 10/11 aggressively leaks DNS through "smart multi-homed name resolution" — disable it via Group Policy or registry edit
  • IPv6 traffic often bypasses IPv4-only VPN tunnels entirely — test at test-ipv6.com and either use IPv6-capable VPN or disable IPv6 system-wide
  • Run quarterly leak tests across all browsers you use — OS and browser updates regularly break previously working configurations
  • Match leak fixes to your threat model: location/identity leaks are critical, while technical imperfections may be acceptable depending on your goals