Hide Network Connections via VPN (Kill Switch)

A VPN kill switch is a fail-closed firewall policy: it blocks internet traffic unless that traffic travels through an active VPN tunnel or is needed to reach the VPN server. To work reliably, the policy must cover startup, disconnects, IPv4, IPv6, and DNS. Test it during failure, not just while the VPN shows “connected.”

A lasting setup depends on rules that stay in place when the VPN app closes, the computer restarts, or the network changes. A toggle in a VPN app can help, but it is not proof that traffic cannot escape. I treat the host firewall as the enforcement point and the VPN client as one part of the system.

This guide explains how to plan that boundary, install a default-deny policy, test it, and recover safely. Commands below help inspect a system; firewall rules differ by operating system, firewall manager, VPN, and network. Do not paste a generic ruleset into a machine you rely on without checking those details first.

Plan the VPN and Firewall Boundary

A VPN tunnel encrypts traffic between your device and a VPN endpoint. A kill switch is the firewall policy that blocks internet-bound traffic when it is not using that tunnel. The goal is fail-closed egress: if the tunnel is unavailable, ordinary internet access stops rather than falling back to your regular connection.

Survey the device and VPN

Before changing rules, record the operating system, firewall manager, VPN protocol, interface names, server addresses, and ports. Also note whether the VPN endpoint is a fixed IP or a hostname, which DNS resolver you use, whether IPv6 is enabled, and whether you need local network access.

On Linux, these commands provide useful starting points:

• ip route shows IPv4 routes.
• ip -6 route shows IPv6 routes.
• ip link lists network interfaces.
• resolvectl status may show DNS settings on systems using systemd-resolved.
• sudo nft list ruleset displays active nftables rules.

Commands and output vary by system. On Windows or macOS, use the system’s network settings and firewall tools, along with the VPN provider’s documentation, to identify equivalent details.

Define what is allowed

A sound policy blocks outbound traffic by default, then permits only required traffic. Common allowances include loopback traffic, traffic through the VPN interface, and narrowly scoped packets to the VPN endpoint so the tunnel can connect. Allow DNS only through the tunnel or to a resolver explicitly approved for use through it.

Decide separately whether devices on your local network should remain reachable. Allowing LAN access can be useful for a printer or file server, but it creates an exception to review. Do not make a broad exception such as “allow all UDP” or “allow all HTTPS”; it can undermine the boundary.

Check IPv4, IPv6, DNS, and LAN Access

A leak is traffic that reaches a destination outside the VPN when you expected the tunnel to carry it. Checking only IPv4 is not enough: an IPv6 route can remain active even when the VPN carries only IPv4. DNS matters too, because a lookup can reveal the domains your device requests.

Check both IP versions

Inspect both routing tables before and after connecting. On Linux, run ip route and ip -6 route. Confirm which interface carries the default route and whether IPv6 has a route that bypasses the tunnel. A VPN that supports only IPv4 needs a deliberate IPv6 policy: route IPv6 through the tunnel or block it at the firewall.

RFC 8200 sets the minimum IPv6 link MTU at 1280 bytes. That is a protocol requirement, not a kill-switch setting, but it matters when troubleshooting IPv6 connectivity. Do not treat disabling an IPv4 route as a fix for IPv6 leakage.

Check DNS and endpoint resolution

Conventional DNS uses UDP and TCP port 53, as described in RFC 1035. Your policy should allow DNS through the tunnel, or to a specific resolver reached through it. A resolver exception on the physical network should be narrow and intentional.

A hostname-based VPN endpoint may need to be resolved before the tunnel is up. Plan how that lookup happens. One option is to use a verified endpoint IP in the firewall policy, if your provider supports stable addresses. If the address changes, update the exception through a controlled process rather than opening DNS or internet access broadly.

Decide on LAN access

Local network access is separate from internet access. If you need a printer or local server while the VPN is active, allow only the specific local addresses or network ranges you need, where your firewall supports that level of control. If you do not need LAN access, keeping it blocked reduces exceptions.

Remember that a device used as a router may forward traffic for other devices. A host’s outbound firewall policy alone may not protect forwarded traffic. Review forwarding rules as well if the device acts as a gateway.

Install Fail-Closed Egress Rules

Firewall rules should be active before applications can send traffic and should survive reboot and network changes. The policy must remain in force if the VPN interface disappears. In practical terms, that means installing the deny rule first and ensuring that stopping the VPN does not remove it.

Apply rules in a safe order

Use this sequence to reduce the chance of a brief, unprotected window:

1. Record the current firewall configuration and confirm you can reach the device locally if remote access matters.
2. Identify the VPN interface and the exact endpoint IP, protocol, and port.
3. Set outbound traffic to default-deny.
4. Allow loopback, required tunnel traffic, and only the specific endpoint traffic needed to establish the tunnel.
5. Add DNS and LAN exceptions only if required, and keep them narrow.
6. Persist the policy across reboot and test it before relying on it.

For WireGuard, UDP 51820 is a conventional default listen port, not a required port. Permit the port actually configured for your endpoint. The exception should specify the verified destination address, transport, and port. A general UDP or HTTPS allowance is not an equivalent substitute.

Keep the policy independent of the VPN app

VPN apps often offer a kill-switch setting, but behavior varies. Some apply firewall rules only after the app starts; others may remove rules when the app exits. I do not assume the setting covers boot, crashes, or reconnects until I test those states.

On Linux, nftables can enforce an outbound default-drop policy and allow traffic on the VPN interface plus a specific endpoint exception. The exact rule set depends on interface names, endpoint address family, DHCP needs, and firewall manager. Do not mix independently managed rule systems without checking how they interact. On Windows and macOS, use supported firewall controls or a VPN client with documented system-level enforcement, then test the same failure cases.

Verify Leak Prevention and Recovery

A connected icon is not a leak test. Verification means checking that normal traffic stops when the tunnel is unavailable, while the device can still reconnect through the narrowly permitted endpoint path. Test after applying the rules and again after a reboot or relevant VPN or network change.

Run controlled tests

First connect the VPN and confirm that ordinary browsing and required services work. Then test DNS, IPv4, and IPv6 using tools or test sites you trust. For command-line checks, curl -4 and curl -6 can test whether a web request succeeds over each IP version; dig can query DNS. These tools alone do not prove which path a request took, so inspect routes and firewall counters or logs as well.

Next, disconnect the VPN deliberately. Repeat the checks. Internet-bound requests should fail, while the VPN endpoint should remain reachable enough for the client to reconnect. Test these states individually:

• VPN disconnected by the user.
• VPN process stopped or crashed.
• Network briefly lost and restored.
• Device restarted before opening the VPN app.
• IPv6 available on the network while the VPN carries only IPv4.
• DNS lookup during startup and after a tunnel failure.

If a test succeeds outside the tunnel, stop and review the rule that allowed it. Do not fix a connection problem by allowing all outbound traffic.

Keep a recovery path

A fail-closed policy can block the access you need to repair it. Before deploying on a remote machine, arrange a trusted local or out-of-band recovery method and save the current ruleset. Document how to restore the firewall through the operating system’s supported recovery tools.

If the VPN endpoint changes, update the specific endpoint exception and retest. If you change VPN providers, protocols, DNS settings, or firewall managers, treat that as a policy change, not a routine app update.

Worked Test Scenarios

These scenarios are test plans, not claims about a particular customer or product. They show how I would check two common setups. Adapt the steps to the actual device and provider; interface names and firewall behavior are not universal.

Laptop using a WireGuard tunnel

Suppose a laptop uses a WireGuard interface and a configured UDP endpoint. I would record the endpoint’s IP and port, inspect both route tables, and confirm which interface carries tunneled traffic. The policy would allow traffic through the tunnel and the specific outer connection to that endpoint, while blocking other outbound traffic.

Then I would test normal use, disconnect, reconnect, and reboot. If the provider’s tunnel carries only IPv4, I would verify that IPv6 is blocked or routed through the VPN. I would also check that DNS queries do not use an unapproved resolver outside the tunnel.

Desktop that needs a local printer

Suppose a desktop must reach a printer on the home LAN while internet traffic stays in the VPN. I would first confirm the printer’s local address and whether access is needed during VPN use. Then I would add only the required LAN exception, if the firewall can scope it, and test both printer access and internet behavior with the tunnel off.

The key test is not just whether printing works. It is whether a broader LAN or internet exception was added by mistake. Keep a record of the allowed local range and remove the exception if the printer no longer needs it.

Check	Expected result	If it fails
VPN connected	Internet and DNS use the tunnel	Inspect routes, DNS, and VPN-interface rules
VPN disconnected	General internet traffic fails	Find and narrow the outbound allowance
IPv6 test	IPv6 uses the tunnel or is blocked	Add a deliberate IPv6 policy
DNS test	Resolver is reached through the tunnel or an approved path	Review port 53 and resolver routes
Reboot test	Deny policy is active before ordinary apps connect	Fix firewall persistence or startup order

The useful measure is the result of each failure test, not a speed score. If the VPN disconnects and an ordinary web request still succeeds, the policy is not fail-closed.

Conclusion and FAQ

A reliable VPN kill switch is a firewall boundary, not a promise made by an icon. Start with a full survey, define specific exceptions, apply default-deny before applications run, and test failure states for IPv4, IPv6, and DNS. Keep a recovery plan, and retest after system or VPN changes.

Does a VPN kill switch hide that I am using a VPN?
No. Your network can generally see a connection to the VPN endpoint, along with traffic timing and volume. The tunnel can conceal destination traffic from some local observers, but it does not make the VPN connection invisible.

Is the VPN app’s kill-switch toggle enough?
Not without testing. Behavior differs by app and operating system. Check startup, crashes, reconnects, and shutdown to confirm traffic cannot fall back to the regular connection.

Why should I test IPv6 separately?
A VPN may carry IPv4 but not IPv6. If IPv6 remains routed outside the tunnel, IPv6 traffic can bypass an IPv4-only policy.

Should I block IPv6 or route it through the VPN?
Either can prevent an outside-tunnel path. Choose based on the VPN’s support and your needs, then verify the firewall and routes. Do not assume IPv6 is handled automatically.

Can DNS leak even when the VPN is connected?
Yes. DNS may use a resolver outside the tunnel if routing or firewall rules allow it. Check which resolver is used and permit DNS only through the tunnel or an explicitly approved path.

Does WireGuard always use UDP port 51820?
No. UDP 51820 is a conventional default, not a requirement. Allow the actual configured endpoint address, transport, and port.

Can I keep access to my printer while using a VPN?
Often, yes, with a narrow local-network exception. Limit it to the needed device or range where possible, and test that it does not permit general internet traffic.

What should happen when the VPN disconnects?
Ordinary internet traffic should fail until the tunnel reconnects. The firewall may still allow the specific traffic needed to reach the VPN endpoint.

Will a kill switch protect every app on a router?
Not necessarily. A device routing traffic for others needs rules for forwarded traffic as well as traffic created by the router itself.

What should I do if the VPN will not reconnect?
Do not open unrestricted outbound access. Check the endpoint address and port, DNS bootstrap needs, interface names, and firewall logs. Use your documented recovery method to make a narrow, tested correction.

(This article was written by one of our staff writers, Richard Montclair. Visit our Meet the Team page.)