DNS and WebRTC leaks: how to test your VPN and fix them

With the VPN on, every request should leave your device inside the encrypted tunnel. Three kinds of traffic tend to escape.

• DNS leaks. Before your device connects to a site, it asks a DNS server for the site's address. If those questions go to your internet provider instead of through the tunnel, the provider can see every site you visit, even though the pages themselves are encrypted.
• WebRTC leaks. WebRTC is the browser technology behind video calls. To find the best route for a call, the browser asks public servers, called STUN servers, for its address. In some setups this can reveal your real public IP to a website that asks.
• IPv6 leaks. Many networks now offer IPv6. If the VPN only carries IPv4, IPv6 traffic goes out the normal way, with your real address.

There is also the plain tunnel drop: the VPN disconnects for a moment and your device carries on without it. A kill switch prevents that.

1. 1Write down your real details. With the VPN off, open an IP checker such as the one on our home page and note your IP address, city and internet provider.
2. 2Connect the VPN and reload. The address, location and provider should now be those of the VPN server.
3. 3Run a DNS leak test. Use the extended test on dnsleaktest.com or the DNS test on browserleaks.com. Look at the list of DNS servers and who operates them.
4. 4Run a WebRTC test on browserleaks.com/webrtc. Look for any public IP address that is not the VPN's.
5. 5Check IPv6 on test-ipv6.com. With the VPN on, you should see either an IPv6 address that belongs to the VPN or no IPv6 at all, never one from your own provider.
6. 6Test a drop. While a page is loading, switch Wi-Fi off and on, or move between networks. With a working kill switch, nothing loads until the tunnel is back.

Most DNS leaks happen because the operating system picks a DNS server outside the tunnel. Fix them at the system level first.

• Windows: with WireGuard, turn on Block untunneled traffic (kill-switch) in the tunnel settings, which also stops DNS requests from going around the tunnel. With OpenVPN, add the line block-outside-dns to the profile if it is missing; it stops Windows from sending lookups to every network adapter at once.
• macOS, iPhone and iPad: the WireGuard and OpenVPN apps set DNS through the system's VPN settings, which normally take priority. If a test still shows your provider, look for a DNS profile, a content filter or a security app that forces its own DNS, and remove or pause it.
• Android: if you set a custom Private DNS provider, Android sends lookups to it through the tunnel, so leak tests show that provider instead of the VPN's DNS. That is expected. Set Private DNS to Automatic if you prefer the VPN to answer.
• Linux: the DNS line in a WireGuard file needs the resolvconf helper, as explained in our WireGuard setup guide. Connections imported into NetworkManager handle DNS for you.
• Encrypted DNS in the browser: Chrome, Edge and Firefox can send lookups over DNS over HTTPS to a resolver of their own. Those lookups travel inside the tunnel, so your internet provider does not see them, but they go to that resolver rather than the VPN's. Switch the setting off if you want the VPN to handle all DNS.

With a full-tunnel VPN such as WireGuard or OpenVPN, WebRTC usually cannot reveal your real public IP, because its requests go through the tunnel like everything else. WebRTC leaks are mostly a problem with browser proxy extensions and split tunnelling, where only part of your traffic uses the VPN or proxy.

• Firefox: open about:config and set media.peerconnection.ice.default_address_only to true. To switch WebRTC off completely, set media.peerconnection.enabled to false; video calls in the browser will then stop working.
• Brave: open Settings, then Privacy and security, find WebRTC IP handling policy and choose Disable non-proxied UDP.
• Chrome and Edge: there is no built-in switch. Some privacy extensions can set the WebRTC routing policy for you, but the simplest fix is a full-tunnel VPN instead of a proxy extension.
• Safari: Safari only shares local network addresses with sites you have allowed to use your camera or microphone. With a full-tunnel VPN there is nothing extra to change.

• Send IPv6 into the tunnel. In WireGuard, AllowedIPs = 0.0.0.0/0, ::/0 sends both IPv4 and IPv6 into the tunnel. If your file only lists 0.0.0.0/0 and a test shows your provider's IPv6 address, add ::/0. When the server does not offer IPv6, those connections simply fail and apps fall back to IPv4 inside the tunnel.
• Use a kill switch. On Windows, tick Block untunneled traffic in WireGuard. On Android, turn on Always-on VPN and Block connections without VPN. On Linux, wg-quick routes all traffic into the tunnel while it is up; for a strict kill switch, add firewall rules that only allow traffic through the WireGuard interface.
• Firewall mode works the same way. OpenVPN over TCP changes the port, not the leak protection. Leaks depend on the app and system settings described above.

BoltVeil gives you standard WireGuard and OpenVPN files for the official apps, so leak protection comes from those apps and your operating system: the kill switch, DNS handling and IPv6 routing described above. Run the five-minute test once on each device after setup and again after major system updates.

Plans and device limits are on the pricing page, the official apps are linked from the download page, and the servers page lists every location.