Two tunnels between the same locations

Two locations, two internet lines each, and therefore the wish for two tunnels as well. That is a good idea, but it works differently from what most people expect: the tool builds two tunnels neatly, and they then behave as two equal paths rather than as a primary and a spare.

Building the two tunnels

On the network board you right-click the router and pick Tunnel to twice, towards the same router on the other side. You then get:

Mind that port. Every new WireGuard tunnel gets 13231, and two WireGuard interfaces on one router cannot both listen on the same UDP port. Click the second tunnel and change its port before you generate. Forget it and that line fails when you paste.

Which one is used

Both at once, which is usually not what you meant.

The tool writes static routes per tunnel towards the networks on the far side, and those routes carry no distance. In RouterOS that means distance 1 for both of them. Two routes to the same network with the same distance give you ECMP: the traffic is spread over both tunnels.

That is not wrong in itself, but the behaviour on failure is unpleasant. A WireGuard interface never goes down: it exists from the moment it is created, whether the far side answers or not. When the line under tunnel 2 fails, the route via wg2 stays in place and roughly half of your traffic disappears. Not all of it, which makes it harder to recognise than a full outage.

Route distance is the control that counts

The tunnel type is beside the point here. WireGuard, GRE over IPsec, IPIP: they all produce an interface and a route, and it is the route that decides which one is used. So there is one thing to arrange, and that is the distance.

After pasting, on both routers, for every network on the far side:

/ip route
set [find gateway=wg2] distance=20

That makes wg1 the main path and wg2 the spare. Except: a route with a higher distance only takes over once the route with distance 1 disappears, and that does not happen by itself, because the interface stays up. So you also need something that pulls the route away.

Three ways to make the switchover happen

• BGP per tunnel. The tidiest one. Give both routers an AS number on the board and switch BGP on for each tunnel. The tool then writes a BGP session per tunnel over the tunnel address, leaves the static routes out, and makes sure the WireGuard peer still allows the networks on the far side, or the traffic would die on the allowed-address anyway. When a session goes away, the routes learned over it go with it and the other tunnel is left. Give the two sessions a different preference, or you are back to two equal paths. Expect the switchover when the hold time expires, not instantly.
• Netwatch. In the High availability section, add a host on the far side's tunnel address, 10.255.255.6 for instance, with a 10-second interval. In the "down" script you change the route distance, in the "up" script you change it back. That works well and reads clearly, but they are your rules: they are not in the generated script and they disappear when somebody generates again.
• Check-gateway on the route. For a route through a GRE or IPIP tunnel you can set check-gateway=ping, so the route disappears when the far side stops answering. That is the simplest form, and it depends on whether the tunnel address on the far side answers ping reliably.

Check the result with /ip route print (is there one active route or two?) and /interface wireguard peers print (how long ago was the last handshake?).

Two tunnels over two different lines

The reason for two tunnels is usually two internet lines. There is a catch: the tool has one public address field per router, and a tunnel uses that address as its endpoint. Two tunnels to the same router therefore get the same endpoint, and both follow whichever route the router picks at that moment.

If you want tunnel 1 to genuinely use line 1 and tunnel 2 to use line 2, you have to force it by hand: a route towards the far endpoint with the outgoing interface of that one line, and on the other side an endpoint filled in with the address belonging to that line. This is where it really becomes handwork, and where you have to write things down.

What does work by itself: when one side moves to its second line, that side dials again and the far side learns the new source address on the next handshake. See Two providers at every site.

What the checks catch

• Neither router has a public address on a WireGuard tunnel: the tunnel does not know where to connect.
• A DNS name on a GRE, IPIP or EoIP tunnel. Those want an IP address as their destination.
• Overlapping networks on both sides, so the routes over the tunnel clash.
• BGP on without an AS number on one of the two routers.
• Missing WireGuard keys.

Further reading: Tunnels between locations, BGP and Netwatch and monitoring.