MikroTik has many useful features and one of our most common requests is how to configure multi-WAN failover. In this blog we will discuss some simple techniques used to achieve this.
You can watch our video on the topic, or read about it below.
In this example, there are separate WAN connections on Ethernet 1 & using 10.1.1.1 and 10.2.2.2 as the respective gateway IP addresses. All interfaces have been set with the correct IPs and other relevant configuration to make the router internet ready. Next step is the router configuration.
Default Route
Basic Gateway IPs can be added to the routing table statically or dynamically in RouterOS. Since the network is simple, we will use a static configuration in the example.
To access the main routing table, go to 'IP' > 'Routes'.
Here you will find a list of known networks to your router. Each time you add an IP to the router it will automatically populate the route list.
In this example you will see all of the networks but there is no internet break out. To achieve this, a default route needs to be configured using 0.0.0.0/0 as the destination and a valid gateway IP or interface. To verify connectivity, open up a new terminal and simply ping something on the internet.
In order to use more gateways you will require multiple default routes. RouterOS makes use of routes based on something called route distance. By default this is set to ‘1’ for statically assigned routes, the lower distance takes priority.
In the example, we create another default route but this time, the 'distance' is set to a higher value. It immediately displays the new route as inactive, given that everything is currently using the route with the lowest distance. If we disable route 1, route 2 becomes active instantly with almost no noticeable connection loss. The simplest way to confirm the second gateway is in use, is by closing and reopening the route list.
WAN Redundancy Basics
RouterOS has a built-in feature to automate fail over from one route to another. If we open up our first route there is an option to check the gateway by pinging the gateway IP address every 10 seconds. If there are 2 consecutive failures the gateway is considered to be down. This deactivates the route, thereby enabling the second default gateway.
We test this by creating a firewall rule which blocks ICMP traffic to the gateway IP.
After 20 seconds, we should see our second route come into action. The first route goes into an unreachable state which makes our second route active. Once 10.1.1.1 is reachable again it instantly reverts to the route with the lower distance.
WAN Redundancy with Recursive Routes
Although the previous technique works reasonably well, using the gateway IP to check connectivity isn’t the best solution. Making use of a public DNS IP is generally more reliable as it’s less likely to be unavailable. This can be achieved by a lookup process known as recursive routing. This is a route that points to another route. So we'll configure the router to use the DNS server address as the gateway instead of the actual gateway IP. To configure this, we would need to create a route to our public DNS provider. In this case, it will be Cloudflare at 1.1.1.1 and we will ensure this is reachable via our default gateway IP address, 10.1.1.1.
In order for recursion to work, we need to configure the 'scope' and 'target scope' options in the route. The 'scope' value can be anything as long as the 'target scope' is equal to or higher than the 'scope' value.
Next, we need to change the gateway IP on our default route to 1.1.1.1 and adjust the 'scope' and 'target scope' values. Our 'scope' can be set the same, but our 'target scope' needs to be 1 higher than the 'target scope' value set in our first route for the recursion to take place.
Since Cloudflares IP is reachable via 10.1.1.1, the default route now checks 1.1.1.1 before failover occurs. This would typically be more reliable than using the regular gateway IP address provided by the ISP.
We are able to make our configuration even more resilient by using an additional recursive route to another DNS provider. In order to do this we could make copies of our existing configuration and change the IP to another address, like 8.8.8.8.
When the default route is duplicated, we would need to use a higher 'distance' value. This will make it available for failover in the rare case that Cloudflare goes down.
If both IPs are down, it's likely there is no internet connection and failover to our second WAN will occur. We can test this by adding firewall rules to verify the routes work as intended.
Further work can be done to improve on this, like setting up notifications or routing traffic over separate WANs.
If you would like more in-depth information on features or setups that can be done on the MikroTik routers, have a look at the MikroTik Wiki page. They have a host of different configurations with examples as well as other useful information.
To keep up to date with releases and other possible blog posts from Scoop, subscribe to our newsletter.
