High Availability WireGuard Site to Site

We’ll set up each of the four WireGuard routers all the same way: install Linux on it (any modern Linux distro will be fine and work basically the same), then:

This will build two parallel WireGuard VPNs (Virtual Private Networks): one between Router 1 and Router 3, and the other between Router 2 and Router 4:

Router 1 will have a private WireGuard IP address of 10.99.13.1, but a public IP address of 198.51.100.10 (and an IP address of 192.168.1.101 within Site A’s LAN). Router 3 will have a WireGuard address of 10.99.13.3, but a public IP address of 203.0.113.33 (and an IP address of 192.168.200.3 within Site B’s LAN). Router 1 will connect to Router 3’s public IP address over UDP port 51820, and vice versa.

Similarly, Router 2 will have a WireGuard address of 10.99.24.2, but a public IP address of 198.51.100.222 (with an IP address of 192.168.1.202 within Site A’s LAN). And Router 4 will have a WireGuard address of 10.99.24.4, with a public IP address of 203.0.113.244 (and an IP address of 192.168.200.224 within Site B’s LAN). Router 2 will also connect to Router 4’s public IP address over UDP port 51820, and vice versa.

At this point, we have WireGuard up and running on all four WireGuard routers, with Router 1 connected to Router 3, and Router 2 connected to Router 4. But because we put Table = off in their WireGuard configuration, none are set up yet to actually route packets beyond their own WireGuard subnet (10.99.13.0/24 for the connection between Router 1 and Router 3, and 10.99.24.0/24 for the connection between Router 2 and Router 4).

So we’ll configure the BIRD routing daemon with OSPF on each router in order to:

We’ll assign Router 1 a router ID of 10.99.13.1, Router 3 a router ID of 10.99.13.3, and use the 10.99.13.0 OSPF area for their connection to each other; and we’ll assign Router 2 a router ID of 10.99.24.2, Router 4 a router ID of 10.99.24.4, and use the 10.99.24.0 OSPF area for their connection to each other:

On Router 1, edit its /etc/bird/bird.conf file to make it look like the following:

The router id line sets the global ID for this router (used by both OSPF and BGP). The protocol device block configures BIRD to periodically sync its interface list from the OS, so as to detect when interfaces are added, removed, or updated.

The protocol kernel block syncs the OS’s main IPv4 routing table with BIRD’s internal master4 routing table. By default all routes are imported from the OS’s table into BIRD’s table, but none are exported from BIRD’s table to the OS’s table. The export where proto = "wg"; line configures BIRD to export to the OS’s main table all the routes it added to its master4 table from the named wg protocol instance — in other words, to copy all the routes it learns from OSPF about the other site into its own active routing table.

The protocol ospf v2 wg block sets up the OSPFv2 instance we’ll use for the WireGuard connection. Note that wg is just an arbitrary internal ID we’ve given to this instance — BIRD would have otherwise given it an ID of ospf1 by default. And by default it will import all the routes it receives over OSPF into its master4 routing table; but export none of the routes from its master4 table to OSPF. The export all; line in this block overrides this export default to export all of the routes from its master4 table to OSPF.

The import where net !~ 10.99.13.0/24; line configures BIRD to avoid pulling in any routes to the 10.99.13.0/24 subnet from OSPF — this is the subnet we’re using for the WireGuard connection between Router 1 and Router 3. The route for 10.99.13.0/24 is already set up in the OS’s main table by wg-quick when it starts up the WireGuard connection, so the OS doesn’t need to learn this route from BIRD; and since this route is only used behind the scenes by the private connection between the WireGuard routers, there’s no need to propagate it to other routers.

The area 10.99.13.0 block configures BIRD to use the area with an ID of 10.99.13.0 for OSPF on the specified interfaces (and as mentioned above, 10.99.13.0 is just an arbitrary 32-bit number, not necessarily related to an IP address or subnet). The interface "wg0"; line specifies that the wg0 WireGuard interface we set up in the section above is included in the area definition.

Other than the custom import and export filters, this OSPF configuration just uses BIRD’s default settings for everything — which is perfect for WireGuard (as long as all WireGuard routers in the same area use the same subnet — 10.99.13.0/24 in the case of Router 1 and Router 3). It will listen for and send out OSPF broadcasts on the wg0 interface, importing the routes learned from OSPF into its master4 table, and exporting the other routes in its master4 table to share over OSPF.

On Router 3, edit its /etc/bird/bird.conf file to match the settings of Router 1, with the exception of using Router 3’s own unique router ID:

On Router 2, edit its /etc/bird/bird.conf file to set it up similarly to Router 1 and Router 3, but skipping the import of its own WireGuard subnet (10.99.24.0/24), and using a different area ID of 10.99.24.0 for its shared area with Router 4:

And on Router 4, edit its /etc/bird/bird.conf file to match the settings of Router 2, except with Router 4’s own router ID:

Run the following command on each router to start up an interactive command-line client to BIRD:

Then run the following command in the BIRD client to reload your changes to /etc/bird/bird.conf:

After reloading your changes on both Router 1 and Router 3, if you run the following command from Router 1, you should see that it’s communicating with Router 3:

But it won’t have imported any routes into BIRD’s default IPv4 routing table yet:

Now that the WireGuard links between Site A and Site B are up and exchanging routes, the next step is to propagate those routes to the sites. If you use OSPF at your sites, follow the instructions in this section to do so; if you use iBGP, follow the instructions from the Alternatively Configure BGP to LAN Routers section.

For this example, we’ll imagine that Router 1 is on the LAN subnet 192.168.1.64/26, and will exchange routes with its LAN router 192.168.1.65 in OSPF area 0; Router 2 is on the LAN subnet 192.168.1.192/26, and will exchange routes with its LAN router 192.168.1.193, also in area 0; Router 3 is on the LAN subnet 192.168.200.0/26, and will exchange routes with its LAN router 192.168.200.1 in OSPF area 0; and Router 4 is on the LAN subnet 192.168.200.192/26, and will exchange routes with its LAN router 192.168.200.193, also in area 0:

Site A also has a few other subnets, 192.168.2.0/24 and 192.168.3.0/24, that can be accessed through both the 192.168.1.65 and 192.168.1.193 gateways; while Site B has an additional subnet 192.168.200.128.0/26.

On each WireGuard router, edit its /etc/bird/bird.conf file to add a second protocol ospf block:

Replace eth0 with the actual name of the router’s LAN interface (if it’s not eth0), and replace the area ID 0 with the actual OSPF area ID you’re using for the LAN subnet the router is on (if not 0). Also notice that we’ve assigned this protocol block an arbitrary internal ID of lan (otherwise BIRD would give it an autogenerated ID like ospf2).

The export all; line configures BIRD to export all the routes from its master4 table to share with OSPF. By default, BIRD will also import all the IPv4 routes it receives over OSPF into its master4 table. If you don’t want to propagate all of the site’s routes to the other site, add an import filter here to the ipv4 channel to limit the routes that BIRD will pull in from this OSPF instance.

For example, to propagate only routes in the 192.168.1.0/24 subnet, add an import where net ~ 192.168.1.0/24; line to the ipv4 block; or to import all routes except the 10.0.0.0/16 and 10.100.0.0/16 blocks, add import where net !~ 10.0.0.0/16 && net !~ 10.100.0.0/16;; etc. BIRD includes a complete programming language for filtering routes, if you need something more sophisticated.

The full /etc/bird/bird.conf file on Router 1 should now look like this:

Now run the following command in the BIRD client to reload your changes to /etc/bird/bird.conf:

After reloading, you should see at least one neighbor for the new lan OSPF instance:

If you don’t, check the OSPF configuration on the LAN router, and adjust the WireGuard router’s lan OSPF configuration to match. In particular, make sure the area ID and hello interval match (BIRD’s default hello interval is 10 seconds).

If you’ve only added the new lan OSPF instance to one WireGuard router (like only to Router 1), BIRD will pick up the routes from the router’s own site only:

But once you’ve updated all the routers, each router should have at least one path to all the routes exposed by OSPF on any LAN subnet in BIRD’s master4 table:

And each router should have the best path for each subnet at the other site in its OS’s main table (notice that the routes exported by BIRD will be listed as proto bird):

So you should now be able to ping Endpoint B (at 192.168.200.22) in Site B from Endpoint A (at 192.168.1.91) in Site A (provided you don’t have any firewalls blocking ICMP packets on some hop between the two hosts):

And if you kill one of the WireGuard links between Site A and Site B (like for testing purposes, run sudo wg-quick down wg0 on Router 1), you should still be able to ping Endpoint B from Endpoint A — Endpoint A’s LAN router should receive the link-state update via OSPF, and re-route the traffic between Endpoint A and Endpoint B through the other WireGuard link.

If you use use iBGP to exchange internal routes at one site (or both sites), you can use BGP instead of OSPF to propagate the routes exchanged by the WireGuard routers to the rest of the site.

For example, let’s say that Site A uses iBGP. We can configure Router 1 and Router 2 to use BGP, and connect them to a dedicated Route Reflector (RR) used by all the LAN routers at the site. The WireGuard routers will propagate the routes from Site B to the RR (and vice versa), and the RR will propagate the routes to the rest of the site:

The RR will be at 192.168.3.1, and will use a private Autonomous System Number (ASN) of 65000.

On Router 1 and Router 2, edit their /etc/bird/bird.conf files to add a protocol direct and a protocol bgp block:

Replace eth0 in the protocol direct block with the actual name of the router’s LAN interface (or if the WireGuard router has multiple interfaces connected to different parts of its site, use an interface pattern that encompasses them all, like "eth*", "gre*", etc). The protocol direct block is needed to import the direct interface routes for the LAN interface into BIRD’s master4 routing table, so that it can add the correct next hop to the routes from the other site that it will share via BGP.

In the protocol bgp block, replace 65000 with the actual private ASN you use, and replace 192.168.3.1 with the actual IP address of the iBGP server with which the router should exchange routes. Add multiple protocol bgp blocks if you have multiple iBGP servers with which the WireGuard routers need to exchange routes (one block for each iBGP server).

The export all; line directs BIRD to share all the routes in its master4 table with the other iBGP server. The next hop self; line directs it to adjust those routes to make the WireGuard router itself the next hop in all those routes. This will share the routes the WireGuard router learned from the other site, using the WireGuard router itself as the link to the site.

By default, BIRD will also import all the IPv4 routes it receives over BGP into its master4 table (to be shared back to its paired WireGuard router at the other site via OSPF). If you don’t want to propagate all of this site’s routes to the other site, add an import filter to ipv4 channel to limit the routes that BIRD will pull in from BGP.

For example, to propagate only routes in the 192.168.1.0/24 subnet, add an import where net ~ 192.168.1.0/24; line to the ipv4 block; or to import all routes except the 10.0.0.0/16 and 10.100.0.0/16 blocks, add import where net !~ 10.0.0.0/16 && net !~ 10.100.0.0/16;; etc. See BIRD’s filter reference if you need something more complicated.

The full /etc/bird/bird.conf file on Router 1 should now look like this:

Make a similar change to Router 2, and run the following command in the BIRD client on each to reload your changes:

Once you’ve updated the routers, each router should have at least one path to all the routes exposed by BGP in BIRD’s master4 table:

And each router should have the best path for each subnet at the other site in its OS’s main table (with the routes exported by BIRD listed with proto bird):

So you should now be able to successfully ping Endpoint B (at 192.168.200.22) in Site B from Endpoint A (at 192.168.1.91) in Site A (provided you don’t have any firewalls blocking ICMP packets on some hop between the two hosts):

And if you kill one of the WireGuard links between Site A and Site B (like for testing purposes, run sudo wg-quick down wg0 on Router 1), you should still be able to ping Endpoint B from Endpoint A — Endpoint A’s LAN router should receive the updated route to Endpoint B via BGP, and re-route the traffic between Endpoint A and Endpoint B using the other WireGuard link.

You can use the same basic setup outlined in the above sections to exchange IPv6 routes (and to exchange routes over IPv6 links). The main difference is that you need to use OSPFv3 instead of OSPFv2 to exchange IPv6 routes between the WireGuard routers — and since OSPFv3 is meant to operate only over direct IPv6 links, you have to assign IPv6 link-local addresses to your WireGuard interfaces.

So these are the steps to follow in order to add IPv6 to (or replace IPv4 with IPv6 in) the above examples: