Blackhole route vs VPN kill switch: what each one does

A packet leaves a laptop, never reaches the VPN gateway, and no firewall counter moves. The route table already decided the packet's fate: a blackhole entry matched it and the kernel discarded it before any interface saw it. That behavior is useful when a destination should fail closed, but it is a routing action with a narrow scope. Treating it as a complete kill switch is where designs go wrong.

What the discard action actually matches

A route lookup picks a table, then the longest matching prefix inside it. A blackhole route is a normal entry whose action is discard, so it only affects packets that would have selected that entry after the whole decision. Change the table with a policy rule, or add a more specific prefix, and the discard no longer applies.

This is why the scope of a blackhole is exact and easy to state: it covers the prefix, in the table, for that address family. It does not cover a destination that another table would win, and it does not cover IPv6 just because the IPv4 prefix is discarded.

ip route get shows the decision before you deploy anything, including the table and the route type. Reading that output is faster than inferring from a failed request which rule or prefix took effect.

Blackhole is not the same as unreachable or prohibit

Linux offers three discard-like route types, and they differ in what the sender observes. A blackhole drops the packet without a reply, so the client sees a timeout. An unreachable route returns an ICMP unreachable message, so the connection fails quickly with a host or network error. A prohibit route returns an administrative-prohibition error, which is closer to a deliberate policy refusal.

Pick the behavior you want the application to see. A silent drop is appropriate when you do not want to reveal the policy, and an immediate error is better when users need to understand why a destination is unavailable. Mixing the types across a network produces support tickets that describe the same policy as three different faults.

Do not assume every discard entry is interchangeable when you diagnose a connection. The error text, the timing and the packet capture differ, and the route type in the table tells you which one you are looking at. The ip-route manual lists the types and their error behavior.

How it compares with a kill switch

A kill switch is packet filtering: a firewall rule that drops egress traffic which would leave outside the tunnel. A blackhole route is a forwarding decision made earlier in the stack. Both can stop traffic, but they see different things and miss different cases.

Coverage is where the comparison matters. A firewall can match owner, port or interface and can block an application while leaving the endpoint reachable; a route cannot. Conversely, a route can send a whole prefix into a discard without any packet filter being loaded, which is useful on a minimal system.

WireGuard's AllowedIPs is cryptokey routing, not a firewall. It decides which destination prefixes are accepted into the interface, and a profile that lists only the tunnel subnet simply leaves other destinations to the ordinary default route. That is why full-tunnel profiles use 0.0.0.0/0 and why wg-quick also installs firewall rules when it can.

Keep the tunnel endpoint outside the discard

The endpoint's outer address must remain reachable through the physical interface. A discard that also captures that address prevents the handshake from leaving, and the tunnel never comes up, which looks like a VPN failure rather than a routing policy. Check the route for the endpoint before and after the change.

Management access belongs in the same review. If the only path to the router or the client is the tunnel, an overly broad discard can lock you out of the machine that would let you remove it. Keep a documented out-of-band route, a console, or a timed rollback.

IPv6 needs its own entry and its own review. A design that blackholes IPv4 while leaving IPv6 on the default route leaks exactly the traffic the policy was meant to stop, and the mistake is invisible in an IPv4-only test.

Stage it with a timer and a rollback

Apply the route with a short automatic removal so a mistake cannot persist across a reboot. The commands below use a documentation range; replace it with the prefix your design actually discards:

sudo ip route replace blackhole 10.0.0.0/8
ip route get 10.1.2.3
sudo systemd-run --on-active=60 /sbin/ip route del blackhole 10.0.0.0/8

The second command should report the blackhole route and the table it came from. The third schedules removal in one minute, which is enough time to confirm the policy and short enough to recover from a mistake on a remote host. Once the behavior is confirmed, make the entry persistent through the same configuration management that owns the other routes.

Close the change by recording the prefix, the table, the address family and the rollback method. A discard is a deliberate exception in the routing design, and the next engineer needs to know which traffic it was meant to stop before deciding whether it still belongs.