Skip to content
The Gateway

Fail-closed routing and kill-switch behaviour

Fail-closed routing means a device or policy that requires a protected path loses connectivity when that path fails. It must not silently fall back to the normal WAN route.

The Gateway applies this rule at the network gateway, so it also covers devices that cannot run a VPN client themselves.

Short answer

Section titled “Short answer”

When a protected policy depends on a tunnel, The Gateway keeps the blocking state active until every policy reference that requires it has been removed or a valid protected path is restored. The block is reconciled after daemon restarts instead of relying only on transient process state.

Expected state transitions

Section titled “Expected state transitions”
Event Expected result for a protected client
Tunnel is healthy Traffic uses the selected protected path.
Tunnel fails New traffic is blocked; no direct-WAN fallback.
Daemon restarts while tunnel is unavailable Blocking state is reconstructed from desired policy.
Tunnel recovers Traffic resumes through the protected path.
One of several protected policies is removed Shared protection remains while another policy still references it.
Final protected policy is removed The corresponding block can be reconciled away.

Why reference counting matters

Section titled “Why reference counting matters”

Several devices or policies can rely on the same tunnel. Removing one policy must not remove a kill-switch rule that another policy still needs. The Gateway tracks those references and reconciles the effective firewall state from the complete desired configuration.

What it protects against

Section titled “What it protects against”
  • A WireGuard or OpenVPN tunnel going down.
  • A tunnel failing during daemon restart or configuration reconciliation.
  • An overlapping policy being removed while another protected policy remains.
  • A protected device attempting to use the ordinary WAN route.
  • DNS queries escaping through an unintended resolver when DNS leak prevention is enabled.

What it does not guarantee

Section titled “What it does not guarantee”
  • Protection from a compromised host that bypasses the gateway through another physical or cellular link.
  • Anonymity from the VPN provider, destination, or application-layer identifiers.
  • Availability: fail-closed intentionally trades connectivity for policy enforcement.
  • Correctness of an upstream VPN provider’s exit or logging claims.

How to test it

Section titled “How to test it”

Run the failure test from the same device group and network path you intend to protect:

  1. Confirm the device uses the expected public exit and DNS path.
  2. Stop the selected tunnel on the gateway.
  3. Attempt a new TCP connection, a UDP request, and a DNS lookup.
  4. Confirm all prohibited paths fail instead of using the direct WAN.
  5. Restart gatewayd while the tunnel remains down and repeat the checks.
  6. Restore the tunnel and confirm the protected path recovers.

The performance and verification page explains how the current release evidence is scoped.

Section titled “Related”