How to Prevent Leaks When a Router VPN Disconnects

When you connect a VPN on a phone, the app usually tells you what happened if the tunnel falls. You see an icon change, a notification or a prompt. A router has none of that. It sits in a cupboard, forwards packets for every phone, TV and laptop in the house, and if the VPN tunnel dies at two in the morning, nobody gets a message. The question is what the router does next. Does it stop forwarding, or does it quietly send everything out over the ordinary internet connection?

That second behaviour is the leak this article is about. A vpn router kill switch is the set of rules that makes the first behaviour happen. Below you will find how routers actually react to a dropped tunnel, how to make a router fail closed, what to do about DNS and IPv6, a simple test you can repeat, and the trade-offs you accept when the whole home depends on one tunnel. For the app-side idea, see what a VPN kill switch is; this piece stays on the router.

Why a dropped tunnel on a router is a bigger deal

On a phone, a dropped VPN affects one person, and that person often notices. On a router, one drop affects every device at once, and nobody is looking. The tunnel can fall for ordinary reasons:

• the internet provider briefly resets your line or gives your router a new public address;
• the VPN server you were using restarts or becomes unreachable;
• the router reboots after a power cut and starts forwarding traffic before the VPN client has finished connecting;
• a firmware update resets a setting;
• the VPN session simply expires or the keepalive packets are lost.

In each case, the devices behind the router do not know. They still have a working local address and a default gateway, which is the router. They keep sending packets to it. If the router has no rule that says "never send these out the normal way", it will route them out the normal way, with your real public address attached.

Nothing breaks visibly. Pages still load. That is exactly why the failure is dangerous: you lose the protection without losing the connection, so no symptom tells you. The leak can last for hours.

How routers behave when the tunnel drops

Routers fall into three broad behaviours. Your firmware may offer more than one.

Fail open (the default on many routers)

When the VPN interface goes down, the route that pointed traffic into the tunnel is removed. The remaining route is the normal default route to your internet provider. Traffic keeps flowing, unprotected. This is what you get if you simply enable a VPN client and do nothing else.

Fail closed with a firewall rule

You add a rule that says traffic from the home network may be forwarded only to the VPN interface, never directly to the internet-facing interface. When the tunnel is up, traffic goes through it. When the tunnel is down, there is nowhere permitted to send the packets, so they are dropped. The devices lose internet until the tunnel returns.

Fail closed with a dedicated option

Some firmware has a checkbox or setting with a name such as "block traffic if VPN is down" or "kill switch". It builds the rule above for you. This is the easiest route, but you still need to test it, because the exact scope (which devices, which address families) differs between firmware versions.

Behaviour	Tunnel up	Tunnel down	Effort	Main risk
Fail open	Protected	Unprotected, still online	None	Silent exposure
Fail closed (firewall rule)	Protected	Offline, no exposure	Medium	Mistyped rule leaves a gap
Fail closed (built-in option)	Protected	Offline, no exposure	Low	Option may not cover IPv6 or router DNS

Building a fail-closed rule in plain terms

Interfaces and menus differ by brand, so this section describes the logic rather than exact clicks. Your router's own documentation is the authority for names. If you have not set up a VPN client on the router yet, follow the router setup guide first and confirm the tunnel works before adding any blocking.

1. Name the interfaces. Find out which interface is your LAN, which is the internet-facing one (often called WAN), and which is the VPN tunnel. Write the three names down.
2. Allow LAN to VPN. Make sure there is a forwarding rule that allows traffic from the LAN to the tunnel interface.
3. Remove or block LAN to WAN. Remove any rule that allows LAN traffic to be forwarded straight to the WAN. If your firmware has a default allow, add an explicit block for LAN to WAN placed below the allow rule for LAN to VPN.
4. Keep the router's own connection alive. The router itself still needs to reach the VPN server through the WAN, so do not block the router's own outgoing traffic. You block forwarding, not the router's own connection.
5. Mind the order. Firewall rules are usually read top to bottom. An allow above your block defeats it.
6. Save and reboot once. Rules that look right in the page sometimes only take effect after a restart, and a reboot also tests the startup case described below.

If you want only some devices covered, you apply the rule only to their addresses. That ties into policy routing, which another guide on this site handles separately, so here we assume the whole network is covered.

The startup gap and the reboot case

A subtle leak happens at boot. After a power cut, the router brings up the LAN and the WAN quickly, while the VPN client takes tens of seconds to connect. During that window, a fail-open router forwards traffic normally. A fail-closed firewall rule closes this gap only if it is loaded before the LAN starts forwarding.

To check it, look for these signs:

• After a reboot, devices that connect immediately get no internet for a short time and then come online. That is a good sign.
• If devices get internet instantly after a reboot but the VPN shows as still connecting, the rule is not covering the startup window.

Some firmware starts the VPN client later in the boot process than the firewall. That is fine, as long as the firewall rule, not the VPN client, is what decides whether forwarding is allowed.

DNS and IPv6: the two usual holes

Most people who build a kill switch test only "does the site load". Two other paths leak even when IPv4 web traffic is blocked.

DNS requests

Every time a device opens a site, it asks a DNS server for the address. If the router hands your internet provider's DNS to devices, or forwards requests itself over the normal connection, the names of the sites you visit leave outside the tunnel even while page traffic is protected. Read what a DNS leak is for the full picture. On a router, the fix is to make sure the DNS servers given to devices are reachable only through the tunnel, and that the router's own resolver does not use the WAN-side servers when the tunnel is down.

IPv6

Many home connections now give the router an IPv6 prefix as well as IPv4. If your rule only covers IPv4, devices that use IPv6 may continue through the normal connection with a public IPv6 address while IPv4 traffic is correctly blocked or tunnelled. The IPv6 specification in RFC 8200 explains why every device can have a globally reachable address, which is exactly why a gap matters. Your options are to apply the same fail-closed rule to IPv6 or to turn off IPv6 on the LAN while the VPN is in use. Do one of them deliberately instead of hoping.

A repeatable test

You cannot trust a kill switch you have never triggered. Test it when no one is in a call or a download.

1. With the tunnel up, visit an IP-checking page from a laptop on the home network and note the address. It should not be the address your internet provider normally gives you. If you are unsure which is which, what a public IP address is explains it.
2. Open a DNS or IPv6 leak test page and note the results.
3. On the router, disable the VPN client (or disconnect the tunnel). Do not unplug the router's WAN cable, since you want only the tunnel to fall.
4. On the laptop, reload the IP-checking page. A fail-closed router shows an error or time-out. A fail-open router shows your real address.
5. Also try opening a site by its name and by its IPv6 address if you know one. Neither should work.
6. Re-enable the VPN client. After a short wait, traffic should resume and the address should be the tunnel address again.
7. Repeat steps 3 to 6 once after a full router reboot.

For the general checks that apply on any device, the guide on checking that your VPN is working lists the tools and what the results mean.

Three scenarios

A family with a shared connection. Priya's family has two children, a smart TV and four phones. She wants the whole house covered for public-address privacy. She enables the VPN client, then finds that after a power cut the TV loads content immediately while the router status shows the VPN as still starting. That means the startup gap exists. She adds the LAN-to-WAN block, reboots, and sees that devices now wait about half a minute before they get internet. The children complain once, and she explains that the short wait is the protection working.

A remote worker in a rented flat. Marcus works from home and uses a router VPN for the household. A company app on his laptop complains when the tunnel is down. With a kill switch, the laptop simply times out, which is what he wants for work traffic. But his video calls with colleagues drop for ninety seconds whenever the tunnel renegotiates. He decides to keep the kill switch and plug his work laptop into a separate guest network that follows the same rule, so the family's streaming does not compete for the same tunnel.

A small cafe or shared flat network. A cafe owner sets up a router VPN to cover customer Wi-Fi. A fail-closed rule means customers lose internet when the tunnel fails, which can cause complaints. She decides that for a public network, being offline is better than being exposed, but she posts a short notice on the Wi-Fi login page and keeps a mobile hotspot as a backup for the till.

What failing closed costs you

A kill switch trades availability for protection. Know what you are accepting.

• Outages feel bigger. If the tunnel fails, the whole home loses internet, not one device. A reboot of the VPN server or a hiccup in the provider's network may be the cause, and you cannot fix it from the couch.
• Devices that do not tolerate the tunnel suffer. Some banking apps, game consoles and smart-home gadgets behave badly on a VPN. If they sit behind a fail-closed rule, they have no alternative path. Read VPN router vs VPN app to decide which devices belong on the router at all.
• Support calls get harder. If someone says "the internet is down", you now have a new place to look first: the tunnel.
• Smart-home devices may disconnect from their cloud service. If a thermostat or camera needs its manufacturer's server to be reachable and the tunnel is down, it will go offline, and may need a manual reconnect.

A middle path is to keep a second SSID or LAN that is not covered by the rule. Devices that cannot live with outages go there, and everything else stays protected.

Troubleshooting a kill switch that does not behave

The internet never comes back after a drop. The rule is working, but the tunnel is not reconnecting. Check the router log for authentication or time errors, confirm the router clock is correct, and confirm the account is still valid. If the pass has expired the tunnel will never reconnect; see how pass expiration works.

Internet works while the tunnel shows down. The rule is not applied, is placed below an allow rule, or does not cover the device type. Re-check rule order and any "default allow" setting.

A guest network or a second router bypasses the rule. Rules apply per interface. A separate guest zone or an access point that has its own router mode may forward traffic without passing through your block.

Everything is offline after every reboot, forever. The firewall rule may be loaded but the VPN client is not set to start automatically. Enable start on boot for the client.

The test shows a leak only on IPv6. Apply the rule to IPv6 or turn IPv6 off on the LAN for the period you use the tunnel.

Frequent drops. Frequent tunnel failures are a stability problem, not a kill switch problem. Work through improving VPN connection stability first, since each drop becomes an outage when you fail closed.

Common mistakes

• Enabling the VPN client and assuming that means a kill switch exists.
• Testing only by loading one website.
• Blocking the router's own traffic to the VPN server, so the tunnel can never reconnect.
• Writing the block rule above the allow rule.
• Forgetting IPv6 and the router's own DNS.
• Never retesting after firmware updates.
• Putting every device behind the rule, including ones that cannot work on a VPN.

Summary

A router has no screen to warn you when the tunnel falls, so the default behaviour is often to carry on over the ordinary connection. A router kill switch means forcing the router to forward only into the tunnel, so that a drop causes an outage instead of an exposure. Build the rule in the right order, cover DNS and IPv6, test it by deliberately disconnecting the tunnel, and repeat the test after updates. Accept that failing closed makes outages more visible and keep a separate network for devices that cannot tolerate it.

If you are choosing a pass to use on a router or on your devices, you can look at the pricing page at your own pace, and check your My Pass page for the connection methods available.