WireGuard 5G Branch: Let the Branch Dial the Hub

Pointing a branch at a hub is the easy half of this design when the branch sits behind a changing cellular address and the hub holds a stable name. The hub then learns the branch from authenticated traffic instead of from a record you have to keep updated. The contract is simple: the branch always initiates.

Configure it deliberately, then verify the part that people assume works. Both steps take minutes, and the second is where these designs usually fail.

Which Side Holds the Stable Endpoint

The branch configuration names the hub's endpoint and public key. The hub configuration names the branch's public key and its allowed inner prefixes, and it may carry no endpoint at all, because identity comes from the key rather than from the source address of the last packet. That asymmetry is the whole mechanism, and it removes an entire class of discovery problem from the hub side.

When the branch sends an authenticated packet, the hub records the source it arrived from and uses that mapping for replies. Renumbering the cellular link then costs nothing beyond the next handshake, and every component you no longer need is one that cannot fail during a cutover. That property is worth testing during a scheduled change rather than during an incident. Do it while someone can watch both ends at once.

Give the Branch a Configuration That Survives Renumbering

Keep the endpoint and the keepalive on the branch, and keep the hub's peer entry free of a hard-coded address. The keepalive holds the translated mapping open long enough for the hub to send unsolicited traffic after an idle period.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Twenty-five seconds is the commonly cited example for keeping a NAT mapping alive, not a requirement for every peer. Set it from the mapping timeout you actually observe, and remember it generates traffic on a metered link for as long as the interface is up.

On the hub, the branch peer's allowed prefixes must cover everything the branch will send. A missing prefix behaves like a routing failure at the far end and produces no warning on either side, which is why it is worth reviewing before the first real packet. Diff the hub's allowed prefixes against the branch interface addresses before the first connection.

Verify the Mapping and the Failover

Confirm that the handshake completes, that the hub lists the branch's current endpoint, and that the branch's inner addresses are reachable through the tunnel. That is the baseline, and it should be recorded before anyone touches the cellular link. Two lines of output are enough. Keep them in the ticket with the timestamp.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Then test the failure the design exists for. Pull the primary WAN and confirm that the branch's underlying route to the hub now leaves through the cellular interface. A tunnel cannot repair a broken physical path, so an outer route still pointing at a dead uplink produces a handshake timeout that looks exactly like a hub problem.

If the outer path is explicitly bound or policy-routed, failover has to include it. That gap between a design that reads correctly and one that survives an outage is usually the only thing missing.

What This Design Does Not Solve

Nothing here admits an inbound connection to the branch. If something at headquarters must dial into the cellular site, the tunnel direction is wrong for that requirement, and dynamic DNS only updates a name. Provider translation, inbound policy and the client's endpoint refresh all remain in the way, and a changed record cannot open carrier-grade NAT.

Keep the branch prefix distinct from every other site, and constrain what its gateway will forward. The stable hub endpoint simplifies discovery and does nothing for routing design, address planning or the question of which application routes survive a failover.

Write four things into the runbook: who initiates, which prefixes are allowed, how long the keepalive is, and what happens when the primary link drops. Those lines are what a future operator actually needs at three in the morning.