VPNs protect traffic by tunneling packets through a remote server, but leaks — especially DNS, IPv6 and WebRTC leaks — can reveal your real IP or DNS queries even when a tunnel is active. This guide walks VPN users and client developers through concrete, cross‑platform steps to prevent, detect and fix those leaks in 2026. It covers configuration examples, OS‑level firewall and routing rules, browser settings, and a testing checklist you can reuse.

Why these three leak classes still matter

Each leak type exposes different metadata:

  • DNS leaks expose domain names you visit to a local resolver or ISP, undermining browsing privacy.
  • IPv6 leaks occur when IPv6 traffic bypasses an IPv4-only tunnel or the client hasn't routed IPv6 through the VPN, revealing the client address even if IPv4 is protected.
  • WebRTC leaks happen inside browsers when peer‑to‑peer endpoints reveal local or public IP addresses to web pages via APIs.

Modern complicating factors: system and browser DNS-over-HTTPS/QUIC, Android's Private DNS, operating systems adding per-interface resolvers, and apps that use their own DNS stacks. That means you must combine routing rules with correct DNS configuration and browser/app policies.

Principles to follow

  1. Force traffic and DNS over the tunnel when the VPN is "full‑tunnel." For split tunneling, explicitly whitelist only the traffic that should bypass the VPN.
  2. Block or reroute any DNS or IPv6 packets that try to leave over a non‑tunnel interface.
  3. Control browser behavior for WebRTC and DNS-over-HTTPS to ensure they use the tunnel's resolvers.
  4. Test with packet captures as well as public leak testers.

Preliminary steps: choose correct VPN client settings

Before you edit firewalls or routing tables, ensure your client is configured for full tunneling and to push DNS:

  • WireGuard: set AllowedIPs = 0.0.0.0/0,::/0 to ensure both IPv4 and IPv6 (if supported) route through the peer.
  • OpenVPN: use redirect-gateway def1 and, on Windows, add block-outside-dns (client or server push).
  • IKEv2/IPsec: enable "send all traffic" or equivalent profile option and verify server pushes DNS servers.

If your provider offers per‑app split tunneling, audit the routing policy for hidden IPv6 exceptions and ensure DNS is still sent through the tunnel for apps that go over the VPN.

Platform-specific configurations

Linux (systemd-resolved + ip rule + nftables)

Linux distros vary, but the pattern is consistent: bind DNS to the tunnel interface, route IPv6 via the tunnel, and firewall/drop non‑tunnel DNS.

  • Systemd-resolved: configure the VPN to register the tunnel's DNS servers with systemd-resolved for that link (using resolvectl or link‑specific configuration). Example:
resolvectl dns wg0 10.8.0.1
resolvectl domain wg0 ~.
  • IPv6: if your provider supports IPv6, add an IP rule to send IPv6 via the tunnel's table. Example:
ip -6 rule add from
  • Firewall: use nftables to drop any DNS going out a physical interface. Example snippet:
nft add table inet vpn
nft 'add chain inet vpn output { type filter hook output priority 0; }'
nft add rule inet vpn output oifname != "wg0" udp dport 53 drop
nft add rule inet vpn output oifname != "wg0" tcp dport 53 drop

Also block IPv6 packets leaving non‑tunnel interfaces if you do not route IPv6 through the tunnel.

Windows (WFP rules, OpenVPN block-outside-dns, and adapter metrics)

Windows requires two things: ensure DNS resolution uses the VPN adapter and that no DNS queries leak to physical NICs.

  • OpenVPN: add block-outside-dns to the client config to register DNS only on the tunnel adapter.
  • WireGuard: use the official Windows client which sets adapter DNS; verify the DNS servers appear on the tunnel adapter in ipconfig /all.
  • Advanced: for custom clients, use Windows Filtering Platform (WFP) or Windows Defender Firewall outbound rules to block UDP/TCP 53 on non‑VPN interfaces. Example PowerShell to create a firewall rule:
New-NetFirewallRule -DisplayName "Block DNS outside VPN" -Direction Outbound -Protocol UDP -RemotePort 53 -InterfaceAlias "Ethernet" -Action Block

Replace "Ethernet" with each physical interface alias. For IPv6, add rules for remote port 53 over IPv6 and also block ICMPv6 where appropriate (be cautious: some ICMPv6 is necessary for IPv6 functioning).

macOS (pf and per-interface resolver settings)

macOS uses the Packet Filter (pf) and per-interface DNS settings. Clients using Apple's Network Extension APIs can set per‑app or per‑interface DNS — prefer that. Otherwise:

  • Verify the tunnel interface's resolver appears first in scutil --dns.
  • Create pf rules to prevent DNS to external servers via physical interfaces. Example pf rule to block outbound DNS on en0:
block out on en0 proto { tcp udp } from any to port {53}

Edit /etc/pf.conf, load with sudo pfctl -f /etc/pf.conf && sudo pfctl -e. For IPv6, add equivalent rules specifying proto ipv6 and port 53. If using a commercial client with NetworkExtension, ensure it configures DNS settings at the NE level rather than relying on system defaults.

Android

Android's Private DNS (DoT) and per‑app VPN API complicate behavior:

  • If using a system‑wide VPN, ensure the VPN client sets DNS for the tunnel. Test Private DNS in Android settings — if enabled to a third‑party provider that resolves outside the tunnel, you can leak DNS. Prefer provider DoH/DoT endpoints configured on the VPN adapter.
  • For per‑app VPN, verify which apps are excluded and that the excluded apps never bypass DNS routing by using local resolvers.

iOS/iPadOS

iOS enforces better isolation when you use the NetworkExtension API. For consumer users, use an up‑to‑date client from your provider. If you maintain a client:

  • Use NEPacketTunnelProvider/NETunnelProvider to configure DNSSettings and ensure includeAllNetworkActivity routes IPv6 to the tunnel.
  • Test with both Wi‑Fi and cellular because iOS may use different resolver behavior on each.

Browser and WebRTC: block or confine local addresses

Browsers can bypass system DNS via built‑in DoH/DoQ resolvers and can expose IPs via WebRTC. Steps:

  • Set browser DoH/DoQ to your VPN provider's resolver or disable the browser's independent secure DNS if it doesn't use the system resolver. In Chrome/Edge, set Secure DNS to "Use provider" that points to your VPN's DoH endpoint.
  • For Firefox: set media.peerconnection.multiplex and media.peerconnection.ice.default_address_only to limit candidate gathering (enterprise policy exists to manage WebRTC behaviour).
  • Consider browser extensions that control WebRTC (some block local IP candidates entirely), but prefer built‑in settings or enterprise policies for stronger control.

Testing checklist: how to prove the leak is gone

Run these tests in sequence. Treat leak testers as a first check — confirm with packet capture.

  1. Public leak testers: browserleaks.com, ipleak.net and dnsleaktest.com to see DNS servers and public IP.
  2. DNS resolution test: run dig @ and confirm queries go to the tunnel resolver. On Windows use nslookup.
  3. Packet capture: run sudo tcpdump -i any port 53 or icmp6 (or tshark/Wireshark) and verify no DNS/IPv6/RTCP/ICE candidates leave via physical interfaces.
  4. Browser WebRTC test: visit a WebRTC leak test page (browserleaks has one) and confirm the only public IP equals your VPN egress IP and no local addresses are exposed.
  5. IPv6 validation: if your egress supports IPv6, check curl -6 ifconfig.co through the tunnel, or use traceroute6 to confirm IPv6 path through the VPN.

Troubleshooting common failures

  • DNS still resolves via ISP: check per‑interface resolvers (Linux systemd-resolved, macOS scutil), browser DoH settings, and Android Private DNS. If browser uses an external DoH endpoint, change it to the provider or disable it.
  • IPv6 traffic bypasses tunnel: either route IPv6 through the VPN or disable IPv6 locally (last resort). On Linux, disable or add routing rules; on Windows verify IPv6 addresses on the tunnel adapter and route tables.
  • Split tunneling causes leaks: audit split rules; explicitly map AllowedIPs or per‑app rules and add firewall blocks to enforce policy.
  • Mobile apps leaking: use per‑app VPN whitelisting carefully and test each app; some apps use their own DNS or sockets that bypass the VPN.

Recommendations for VPN client developers

Providers and client developers should bake leak protection into their apps:

  • Always configure resolver entries on the tunnel interface using platform APIs (NE on iOS, WFP on Windows, systemd-resolved on Linux).
  • Enforce strict firewall rules at client startup that block DNS and IPv6 outside the tunnel before opening the tunnel (race conditions are common).
  • Provide a reliable kill switch that uses OS-level filtering rather than userland checks alone.
  • Support provider‑run DoH/DoT endpoints and configure browsers to use them where possible, or expose a system‑wide DoH profile on platforms that support it.
  • Publish an official leak testing checklist and commands for advanced users to verify behavior.

Checklist — final validation before you trust the VPN

  • Your client sets DNS servers on the tunnel interface.
  • AllowedIPs (WireGuard) or redirect-gateway (OpenVPN) include both IPv4 and IPv6 as intended.
  • Firewall rules block DNS (UDP/TCP 53) on non‑tunnel interfaces.
  • Browser DoH/DoQ configured to provider or disabled; WebRTC local candidate gathering limited.
  • Packet capture shows no DNS/IPv6/WebRTC candidate packets leaving physical interfaces.
  • Public leak testers report the VPN exit IP only and show the provider's DNS servers.

Preventing DNS, IPv6 and WebRTC leaks is both a configuration and design problem: users must configure clients and OS settings correctly, while providers must build clients that proactively set resolvers and enforce firewall rules. Use the tests and commands in this guide to harden your setup — and include packet captures when you doubt browser leak tester results. With careful configuration and developer attention, these leaks can be closed on all major platforms in 2026.