Four leaks, and where each one is controlled
A router VPN moves the tunnel off your devices, so the leak checks also move. Your phone or laptop no longer runs the VPN app's leak protection, so the router's settings now decide whether lookups and traffic leave through the tunnel. Proton's leak guide says that if the DNS server a leak test shows belongs to your real ISP, you have a DNS leak, and that connecting to a server in another country makes leaks easier to spot [1]. DNSleaktest describes it as the operating system continuing to use its default DNS servers while you think you are protected [9].
The table maps each leak to the place you would fix it on a GL.iNet router running firmware 4.x.
| Leak | What escapes | Where it is controlled | Test page |
|---|---|---|---|
| DNS | Name lookups go to the hotel's or ISP's resolver instead of the VPN's [1][9] | Router DNS settings: manual DNS options [4][5] | DNSleaktest.com, extended test [1] |
| IPv6 | Your real IPv6 address is exposed [2] | Router IPv6 settings: Enable IPv6 toggle and mode [6] | test-ipv6.com [10] |
| WebRTC | The browser reveals an address to a peer, outside normal page requests [11] | On each device's browser, not the router [11] | BrowserLeaks WebRTC page [11] |
| Tunnel down | Traffic falls back to the WAN when the VPN drops [7] | VPN Dashboard: Kill Switch, Enhanced Kill Switch, Allow Non-VPN Traffic [7][8] | Disconnect the tunnel and try loading a page |
The DNS settings that decide whether lookups use the tunnel
On firmware 4.11 and later, GL.iNet says DNS queries for traffic that matches a VPN policy use the DNS servers the tunnel provides by default. Non-VPN traffic uses the active WAN's DNS [4]. Two options change that. Apply Manual DNS to VPN tunnels sends tunnel traffic to your own manual DNS instead of the VPN's. Apply Manual DNS to Router Itself, on by default, makes the router's own services such as GoodCloud use the manual DNS [4]. On firmware 4.10 and earlier, the equivalent switch is Allow Custom DNS to Override VPN DNS [5].
Override DNS Settings of All Clients makes the router replace unencrypted DNS settings on connected devices [4]. That catches a laptop with a hardcoded plain resolver, but not a browser running encrypted DNS. DNSleaktest notes that browsers often turn encrypted DNS on by default and that queries to that provider could count as a leak [9]. Proton advises against third-party DNS, DNS over HTTPS and DNS over TLS alongside its VPN for the same reason [1].
If you use OpenVPN files from Proton, pick the right platform when downloading. Proton warns that a wrong platform choice may leave you vulnerable to DNS leaks [3].
| Setting | Firmware | Default per docs | Value for a leak-free test |
|---|---|---|---|
| VPN DNS used for VPN-policy traffic | 4.11+ | Yes, unless manual DNS is applied to tunnels [4] | Leave as default |
| Apply Manual DNS to VPN tunnels | 4.11+ | Off [4] | Off |
| Apply Manual DNS to Router Itself | 4.11+ | On [4] | Either; affects the router's own services only |
| Allow Custom DNS to Override VPN DNS | 4.10 and earlier | Applies once custom DNS is set [5] | Off |
| Override DNS Settings of All Clients (named for All Clients on 4.10 and earlier) | Both | Not stated | On, to catch devices with hardcoded plain DNS [4][5] |
| DNS Rebinding Attack Protection | Both | Not stated | Off only while logging in to a captive portal [4][5] |
IPv6: decide its state before you test
GL.iNet's IPv6 page tells you to toggle on Enable IPv6 and pick a mode: Native, Passthrough, NAT6 or Static IPv6. It says nothing about how IPv6 interacts with VPN clients [6]. It does warn that some features, including the firewall, GoodCloud and OpenVPN DCO, do not yet support IPv6 and are likely to cause connection problems when combined with it [6].
Proton says some of its apps route IPv6 inside the tunnel, with the initial connection to the server made over IPv4, and that about 80% of its servers support IPv6 [2]. That page covers its apps, not routers [2]. On a router, treat these two results as passes: no IPv6 connectivity at all, or an IPv6 address whose provider matches the VPN rather than the hotel or ISP. test-ipv6.com lists the IPv4 and IPv6 provider names. The site notes that when they do not match, you may be using a tunnel [10].
WebRTC on a router VPN
WebRTC is a browser feature for calls and peer connections. The BrowserLeaks WebRTC page shows two fields, Local IP Address and Public IP Address, with a session description log [11]. With a router VPN, a device that routes through the tunnel should report the VPN's public address there. A private address such as 192.168.8.x in the local field is your router's LAN, not your real public address.
If the public field shows your real address, the device is not going through the tunnel. Common reasons are a policy rule that excludes it (GL.iNet's tunnel rules can match or exclude devices by MAC address [8]) or a phone that has fallen back to cellular data. BrowserLeaks lists browser-side fixes: set media.peerconnection.enabled to false in Firefox's about:config, or use Google's official WebRTC Network Limiter extension in Chrome [11].
The tunnel-down test most people skip
On firmware 4.7 and earlier, the switch is Block Non-VPN Traffic (called Kill Switch in some versions) under the VPN Client's Global Options. With it on, a dropped VPN cuts internet access for every connected device [7]. From 4.8 it splits in two. Tunnel Kill Switch is on by default once a tunnel is active. Enhanced Kill Switch, under All Other Traffic in Policy Mode, is off by default [7]. Allow Non-VPN Traffic is enabled by default so unmatched traffic still reaches the internet [8].
GL.iNet's FAQ does not say whether the kill switch covers the router's own traffic or IPv6 [7]. GoodCloud, DDNS and rtty also go around the tunnel unless Services from GL.iNet Use VPN is turned on, because they normally need the real IP [8]. So the only reliable proof is a test. Disconnect the tunnel from the VPN Dashboard and confirm that a page fails to load on a device, rather than loading over the hotel network.
Day-one checklist and fixes
Run this from at least one phone and one laptop, because browser DNS and WebRTC settings are per device. Before you connect the VPN, write down the hotel or ISP name the test pages show, so you know what a leak looks like.
| Step | Pass | If it fails |
|---|---|---|
| 1. IP check with VPN on | Shows the VPN server's IP address, not your own [1] | Tunnel not up, or the device is excluded by a policy rule [8] |
| 2. Extended DNS test | No resolver from the hotel or your ISP [1] | Turn off Apply Manual DNS to VPN tunnels or Allow Custom DNS to Override VPN DNS [4][5] |
| 3. DNS test shows a big public resolver | Only a pass if you chose that resolver yourself | Browser encrypted DNS; turn it off on that device [9] |
| 4. ISP resolver remains after changes | n/a | Possible transparent DNS proxying of port 53 by the network [9]; confirm DNS is set to use the tunnel |
| 5. test-ipv6.com | No IPv6, or the IPv6 provider matches the VPN [10] | Turn off Enable IPv6 on the router, or confirm the tunnel carries IPv6 [6][2] |
| 6. BrowserLeaks WebRTC | Public IP is the VPN's or blank [11] | Device bypasses the tunnel; check policy and cellular fallback [8] |
| 7. Disconnect the tunnel | Pages stop loading [7] | Enable the tunnel Kill Switch or Enhanced Kill Switch [7][8] |
Watch demos / Official walkthroughs
See the hardware in action.
Videos load from YouTube only when you press play. These are provider videos, not our own product tests.

GL.iNet / Official video
Beryl AX (GL-MT3000) - Unboxing and Setup Guide
What to look for: Identify the hardware connections and setup steps for Beryl AX; other models can differ.
Watch on YouTubeQuestions before you decide
Which DNS leak test should I use?
Proton VPN's leak guide points to DNSleaktest.com. Connect to a server in another country, run the test, and check whether your real ISP's resolver appears. Proton notes that the resolver shown may belong to a partner provider, so an address that is not your ISP's is not by itself a leak.
My DNS test shows Google or Cloudflare instead of the VPN. Is that a leak?
Often it is the browser's own encrypted DNS. DNSleaktest notes that browsers often turn on encrypted DNS by default, and that queries to that provider can count as a leak. The router's Override DNS Settings of All Clients option only replaces unencrypted DNS, so change the browser setting on that device.
Does the GL.iNet kill switch also block IPv6 or the router's own traffic?
GL.iNet's kill switch FAQ does not say. It also notes that GoodCloud, DDNS and rtty skip the tunnel unless you turn on Services from GL.iNet Use VPN. Test the kill switch yourself with IPv6 in the state you actually use.
Should I turn IPv6 off on the router?
If you do not need it, leaving IPv6 off removes one leak path to check. GL.iNet's IPv6 page also warns that some features, including the firewall, GoodCloud and OpenVPN DCO, do not yet support IPv6 and may cause connection problems when combined with it.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Proton VPN: DNS leaks and privacy Accessed 30 Oct 2026
- Proton VPN: Preventing IPv6 VPN leaks Accessed 30 Oct 2026
- Proton VPN: How to download OpenVPN configuration files Accessed 30 Oct 2026
- GL.iNet Router Docs 4: DNS (firmware 4.11+) Accessed 30 Oct 2026
- GL.iNet Router Docs 4: DNS (firmware 4.10 and earlier) Accessed 30 Oct 2026
- GL.iNet Router Docs 4: IPv6 Accessed 30 Oct 2026
- GL.iNet Router Docs 4: Block non-VPN traffic (kill switch) FAQ Accessed 30 Oct 2026
- GL.iNet Router Docs 4: VPN Dashboard Accessed 30 Oct 2026
- DNSleaktest: What is a DNS leak Accessed 30 Oct 2026
- test-ipv6.com: Test your IPv6 connectivity Accessed 30 Oct 2026
- BrowserLeaks: WebRTC leak test Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.
