Learn WireGuard - High Availability & Resilience

#Introduction

A dead WireGuard server means every client is disconnected. For critical deployments, a single server is not enough. The solution is a high availability architecture: two or more WireGuard servers with an automatic control handover mechanism when one fails.

Episode 19 covers HA patterns for WireGuard: keepalived with VRRP to move a virtual IP, route injection via BGP with BIRD and GoBGP, dynamic endpoint updates, and backup and recovery strategies.

The principle to remember: high availability does not mean no failure; it means failures the users do not feel. Our focus in this episode is minimizing recovery time and removing manual steps that can be forgotten in a panic.

#Keepalived and VRRP

#A Virtual IP for the Endpoint

Keepalived implements the VRRP protocol to create a virtual IP that can move between servers. Clients always point to this virtual IP, and when the primary server dies, the virtual IP moves to the standby server within seconds.

vrrp_instance wg_vip {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        203.0.113.50/32 dev eth0
    }
}

On the standby server, change state MASTER to BACKUP and lower priority, for example to 90. During this, run keepalived on both servers.

#Synchronizing Keys Between Servers

Both servers must share the same WireGuard private key, because clients already know the public key associated with the virtual IP. Synchronize /etc/wireguard/privatekey and wg0.conf from the primary to the standby server, for example via rsync or a vault.

Key synchronization also covers the same peer public keys on both servers, so no peer is lost during failover. Also make sure wg0.conf is identical on both sides, except for parts that are intentionally different.

rsync -avz /etc/wireguard/ server2:/etc/wireguard/

#Route Injection via BGP

#Announcing the Tunnel Subnet

With BGP, you can announce the tunnel subnet to your network routers, so the route to clients always points to the active server. BIRD is a lightweight and popular BGP daemon for this task:

protocol bgp wg_peering {
    local as 64512;
    neighbor 192.168.10.1 as 64513;
    export where net = 10.9.0.0/24;
}

Context: export where net = 10.9.0.0/24 announces the tunnel subnet to the upstream router. When a server dies, the route is withdrawn and traffic is redirected to the other server announcing the same subnet.

#GoBGP as an Alternative

GoBGP is a BGP implementation in Go that is easy to automate over gRPC. If you are more comfortable with an API than with configuration files, GoBGP can be used to announce and withdraw routes dynamically during failover.

VRRP and BGP are often combined: VRRP moves the virtual IP for client endpoints, while BGP ensures the upstream network knows which route to take. The two work at different layers and complement each other.

#Dynamic Endpoint Updates

#Clients Follow the Active Server

Clients store the endpoint as the virtual IP or the primary server's address. If you use a virtual IP, nothing needs to be updated on the client — the virtual IP is what moves. Another alternative is a script that updates the client endpoint during failover:

The virtual IP approach and dynamic endpoint updates are not mutually exclusive; some deployments use both as backup layers. What matters is that each mechanism has a tested activation path, so there is no ambiguity when a failure actually happens.

wg set wg0 peer <PUBLIK_CLIENT> endpoint 203.0.113.60:51820

The wg set wg0 peer ... endpoint command can be run from a failover script to point a peer at the standby server. This is useful when a virtual IP is not available in a given environment.

#Backup and Recovery

#Backup Before Disaster

High availability means nothing without recoverable data. Prepare an encrypted archive containing the private keys and all configuration, as we covered in episode 12:

• Archive every server's /etc/wireguard/, encrypted and stored off-site.
• A record of tunnel addresses, endpoints, and each peer's public key.
• A tested recovery procedure runbook.

#Test Failover Periodically

Run routine simulations: shut down the primary server and measure how long clients take to reconnect. Ideally failover happens within seconds and needs no manual intervention. Record the results as a benchmark to maintain.

Document those failover test results — including recovery time and issues that came up — then use them as the basis for improvement. An HA architecture that was never tested is just an unproven architecture.

#Closing

Episode 19 completed the high availability topic: keepalived with VRRP moves the virtual IP, BGP via BIRD and GoBGP announces routes, dynamic endpoint updates, and regular backup and failover testing.

Key takeaways:

• VRRP moves the virtual IP between WireGuard servers within seconds.
• Both servers must share the same private key.
• BGP announces the tunnel subnet and withdraws the route when a server dies.
• GoBGP provides an API for failover automation.
• wg set ... endpoint updates the client endpoint live.
• Regular failover testing keeps availability claims real.

In episode 20 we cover automation and IaC — managing WireGuard with Ansible and Terraform, and centralized management tools such as wg-dashboard, Firezone, Netmaker, Tailscale, and Headscale.