How to test your VPN for DNS and IP leaks.

Guide · 18 October 2026 · 7 min

State of things on 18 October 2026: Pevnost is in private beta. The first server, in Hluboká nad Vltavou, is live with our DNS resolver inside the tunnel at 10.8.0.1. Accounts are paid by bank transfer; Bitcoin and Lightning open as soon as our node finishes syncing, Monero and cash by post later. Windows app 0.2.2 beta and Android app 0.1.0 beta (APK) are on the Apps page; iOS and macOS use the official WireGuard app. Last reviewed 18 October 2026.

A VPN that is "on" can still tell the world where you are. The two usual ways are an IP leak, where some traffic goes around the tunnel, and a DNS leak, where your computer asks your ISP's resolver which address a name has, so the ISP sees every site you visit even though the connection itself is encrypted. Neither is exotic. Both take two minutes to check, and you should check after every system update, every new network and every change of VPN app.

What a DNS leak is

Before your browser connects to a site, it asks a DNS resolver for the site's address. Operating systems pick that resolver from the network you are on, usually your ISP's or your home router's. If that setting survives the tunnel coming up, the question "what is the address of example.org" leaves your machine in plain text, outside the tunnel, with your real IP address on it. The site itself is then reached through the VPN, but the ISP has already seen the name.

Pevnost avoids this in the configuration itself. Every device file we generate carries DNS = 10.8.0.1, fd7e:1::1: a resolver that runs on the VPN node, is reachable only through the tunnel, does full recursion itself with no upstream forwarder, and keeps no query log (the config is public in our repository and described in the privacy policy). The official WireGuard apps install that resolver for the duration of the tunnel and remove it when the tunnel goes down. If a test shows anything other than our node answering your DNS, something on your device is overriding it.

1. Check the exit address

Open a plain‑text "what is my IP" service in the browser, or from a terminal run something that returns only your public address (any such service works; we do not run one, deliberately). With the tunnel up, the address shown must be our node's address, currently 46.28.107.26, not your ISP's. Check both before and after connecting so you know what the difference looks like.

If the address does not change, the tunnel is not carrying your traffic. Common causes: the tunnel is up but a second VPN or a proxy extension in the browser takes precedence; the app shows "connected" while the handshake has not completed (look at "last handshake" in the WireGuard app, it must be recent); or a split‑tunnel setting excludes the browser.

2. Check who answers your DNS

The browser test sites that list "your DNS servers" work by making your machine resolve a batch of unique names and watching which resolvers ask the test site's authoritative server. Use one if you like; with Pevnost the result must show exactly one resolver, located at our node's address, and nothing belonging to your ISP, your router or a public resolver you did not choose.

From a terminal you can check the same thing without a third party. With the tunnel up:

nslookup pevnost.net 10.8.0.1      # Windows, macOS, Linux
dig @10.8.0.1 pevnost.net +short    # macOS, Linux

If the node answers, the resolver inside the tunnel is reachable. Then run the same query without naming a server (nslookup pevnost.net). The "Server" line must be 10.8.0.1. If it shows your router (often 192.168.x.x) or your ISP, your system is not using the tunnel resolver and names leak.

3. IPv6

Our first node has no public IPv6 yet. The device configuration still routes all of IPv6 (::/0) into the tunnel on purpose: IPv6 packets go into the tunnel and stop there, instead of going around it to your ISP. A browser IPv6 test must therefore show "no IPv6" while connected. If it shows an IPv6 address that belongs to your ISP or mobile operator, the app on your device did not install the IPv6 route; on Android and iOS that happens with some third‑party WireGuard clients, so use the official one.

4. WebRTC

Browsers can reveal local and sometimes public addresses through WebRTC, the technology behind in‑browser calls, even when every other request goes through the tunnel. With the tunnel up a WebRTC test should show only your tunnel address (10.8.x.x) and our node's address. If it shows your home address, disable WebRTC or restrict it in the browser's privacy settings or with an extension that does so. This is a browser issue, not a VPN issue; no VPN can fix it from the outside.

5. If something leaks

Windows, our app: the kill switch is part of the tunnel service and is active whenever the tunnel is up; traffic outside the tunnel, including DNS, is blocked by the Windows firewall rules the official WireGuard engine installs. If a test still shows your ISP's resolver, a third‑party "smart DNS" or security product is intercepting DNS at the application layer; remove it or exclude the tunnel.
Windows, official WireGuard app: in the tunnel's edit dialog tick Block untunneled traffic (kill‑switch).
Android: Settings → Network → VPN → gear next to WireGuard → Always‑on VPN and Block connections without VPN. With both on, nothing leaves the phone while the tunnel is down, and DNS is forced through it.
iPhone and iPad: turn on On‑demand activation in the tunnel settings so the tunnel comes back on every network. iOS has no user‑visible kill switch; short gaps while switching from Wi‑Fi to mobile are possible.
macOS and Linux: the official app has no kill switch on macOS; on Linux add a firewall rule that allows only the WireGuard endpoint and the wg0 interface, or use wg-quick's PostUp hooks to do it.

What a leak test cannot see

A clean leak test tells you that your device sends its traffic and its DNS questions into the tunnel. It says nothing about what happens at the other end. Our hosting provider, like every carrier, can see which addresses connect to our node and when, and can sample traffic flows on the uplink; anyone who watches both your line and our uplink can correlate timing and volume. Sites you log into know who you are regardless of the address you come from. We spell this out in a separate post; the short version is that a VPN moves trust from your ISP to us and narrows what either can see, and that no test on your device can measure that part.