Wireless Link Backup: Routed Failover or One Segment?

Two buildings, a point-to-point radio and an internet VPN that could serve as a second path. Before the backup becomes automatic, one question decides almost everything else: what has to survive, IP reachability between separate subnets, or a single shared Ethernet segment? The radio behaving like a cable is not an argument for extending every broadcast frame across the internet. Answer the question first, because the two answers demand different loop control, different health checks and different ideas of what recovery means.

Decide What Has to Survive the Outage

List the applications that must keep working and note whether they depend on Layer 3 reachability or on Layer 2 adjacency. File sharing, database connections and web services usually care only about routes; discovery protocols, some clustering products and anything that expects a single broadcast domain care about adjacency. A backup that restores the wrong kind of reachability produces a site that is technically connected and practically useless.

Write that list down and attach it to the design, because the answer usually drifts once the first application owner hears about the new link.

Routed Failover: Two Prefixes, One Preferred Path

With distinct site prefixes, the backup is a routing problem. Each router has a preferred path over the radio and a less preferred path over the tunnel, and the preferred route is withdrawn when the radio stops delivering traffic. The far side needs its own return route, and both sides should agree on which path is preferred in each direction so that traffic does not take a long way round in one direction only.

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

Read the third command as well as the second: a policy rule, a second table or a source-based decision can send traffic from one subnet differently from another, and a single default lookup hides that.

Bridged Failover: One Segment, One Blocking Path

If adjacency is genuinely required, the backup has to carry Ethernet frames, which a routed IP tunnel does not do. Bridging a VPN interface into a local segment is supported by some platforms, and those interfaces then become bridge members with the attendant consequences. Two simultaneously forwarding Layer 2 paths form a loop, so the design needs a spanning tree that spans both sites and a clear statement about which path should block.

That is a substantial design decision rather than a checkbox, and the bridging documentation for your platform, such as the bridge overview for pfSense, is the place to confirm what a VPN member actually participates in. Enabling a spanning-tree option on one unrelated device proves nothing about the end-to-end arrangement.

Monitor the Boundary That Matters

A powered radio, a link-up interface and a healthy tunnel each describe a local fact. None of them proves that a packet from one building reached a host in the other, which is the only fact the failover logic should act on. Monitor a target beyond the far router if policy allows it, and monitor both directions separately so an asymmetric failure is visible.

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

Keep the check cheap and bounded: a short interval, a small count and a timeout that fits the application's tolerance. A monitor that itself depends on the path it is testing will report success right up until the moment it stops reporting anything.

Rehearse Both Directions Under Load

Do not copy a single convergence target from someone else's topology. Detection time, route or bridge convergence, tunnel readiness and application recovery each contribute their own delay, and the sum on your equipment is the only number that matters. Rehearse while representative traffic runs, so the measurement includes the queues and sessions that exist in production.

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

Test restoration as carefully as failure. An unstable radio that flaps in and out will drag traffic back and forth if the preference logic has no damping, and users experience that as worse than a clean single outage. Record the selected path at each stage, which fresh requests succeeded and what happened to sessions that were open when the path changed. That record is what turns a second cable into an operating policy.