Last Updated on 2017-03-13.

[:en]

Scenario

• 2x WAN, both having a static public IP (called WAN_p1 and WAN_p3 in this example)
• 1x LAN
• You want to use WAN_p1 by default and the backup connection only if the main one fails.
  • In both cases, the current IP should be updated to an external DDNS service, so incoming connections always use an IP/connection which is currently working.

Initial steps

First make sure both WAN connections are working and the firewall settings are correct.

E.g. you need at least some NAT masquerading rules and maybe a hairpin rule (sort of loopback):

/ip firewall nat
add action=masquerade chain=srcnat comment="masquerade all outgoing" out-interface=WAN_p1
add action=masquerade chain=srcnat comment="masquerade all outgoing" out-interface=WAN_p3

 

Configure DHCP Client (if needed)

Even if you have static IPs for your WAN connections, some providers need a DHCP client anyway to be usable, especially if there is a redial enforcement e.g. after 24 hours.

It should be enough to add a simple DHCP client with default options.

To give one WAN interface a higher usage priority, give the other one a higher distance value like 1.

The commands could look like:

/ip dhcp-client
add comment="first one, higher priority" default-route-distance=0 dhcp-options=\
    hostname,clientid disabled=no interface=WAN_p1
add comment="backup" dhcp-options=hostname,clientid \
    disabled=no interface=WAN_p3

Make sure both connections get their “static” IP and are up and running.

Configure Routes

Choose at least 2 external hosts with static IP addresses. I took the Google DNS servers 8.8.8.8 and 8.8.4.4 as they are quite reliable for connectivity checks.

First, we define that 8.8.8.8 should always be connected to via the main WAN connection, and 8.8.4.4 via the backup connection:

/ip route
add dst-address=8.8.8.8/32 gateway=WAN_p1 scope=10
add dst-address=8.8.4.4/32 gateway=WAN_p3 scope=10

Scope = only use this one gateway

I spent many hours trying to get a well-working failover with routes (check-ping, route distance etc.), but ended up using Netwatch which is the best way now in my opinion. I added it at the bottom of this tutorial.

 

Configure Netwatch (E-Mail)

You might want to get notifications if one of your connections goes down.

First, enter your email server’s settings unter Tools -> Email.

Then open Tools -> Netwatch and add a new host. I also choose 8.8.8.8 and 8.8.4.4 for this, because of the route settings the first one is sort of “mapped” to the main connection, the second one to the backup WAN.

For the Up and/or Down event, enter a command to send an e-mail to yourself.

The full command:

/tool netwatch
add comment="onlinecheck wan_p1" down-script="tool e-mail send [email protected] subject=\"wan_p1 is down\"" host=8.8.8.8 timeout=10s \
    up-script="tool e-mail send [email protected] subject=\"wan_p1 is up\""
add comment="onlinecheck wan_p3" down-script="tool e-mail send [email protected] subject=\"wan_p3 is down\"" host=8.8.4.4 timeout=10s \
    up-script="tool e-mail send [email protected] subject=\"wan_p3 is up\""

You should get a first notification after a few seconds.

 

Configure Dynamic DNS Service

From RouterOS v6.14, the system offers a very convenient DDNS service itself, you do not even have to register anywhere.

The only thing you have to do is activate the checkbox “DDNS Enabled” under IP -> Cloud.

Command as alternative:

/ip cloud set ddns-enabled

After a few seconds, you should get your personal public DNS name.

You can e.g. enter this DNS name as a CNAME in your domain settings. Note for the root domain entry (TLD), e.g. “example.com”, you cannot enter CNAMEs. I prefer to add both WAN IPs as A names for the root entry, and the up-to-date CNAME for any subdomains like www, * etc.

 

Configure Mangle

You might encounter issues regarding the availability for incoming connections via both WAN providers. E.g. if both WAN connections are up and you ping your WAN_p3 public IP from an external host, you will see the connection in RouterOS, but the ping itself will not succeed. Only after you disconnect WAN_p1, it works.

To solve this, we have use connection/routing marks, so the packets/answers go out where they came in, and vice versa.

Use the mangle table:

/ip firewall mangle
add action=mark-connection chain=prerouting in-interface=WAN_p1 new-connection-mark=WAN1 passthrough=no
add action=mark-routing chain=prerouting connection-mark=WAN1 new-routing-mark=WAN1 passthrough=no
add action=mark-routing chain=output connection-mark=WAN1 new-routing-mark=WAN1 passthrough=no

add action=mark-connection chain=prerouting in-interface=WAN_p3 new-connection-mark=WAN2 passthrough=no
add action=mark-routing chain=prerouting connection-mark=WAN2 new-routing-mark=WAN2 passthrough=no
add action=mark-routing chain=output connection-mark=WAN2 new-routing-mark=WAN2 passthrough=no


/ip route
add distance=1 gateway=WAN_p1 routing-mark=WAN1
add distance=1 gateway=WAN_p3 routing-mark=WAN2

 

Update 2017-04-13:

Configure Netwatch (Failover)

As I described above, I switched from failover via routing to a Netwatch solution which is quite fine and simple, because: You do not have to enter any of your public (maybe dynamic) IP adresses manually in the routing table, and the routes stay clear and understandable.

Routes:

Set a comment to both of your “main” routes, e.g. for “0.0.0.0 -> WAN_p1”: “Netwatch:WAN1” and “0.0.0.0 -> WAN_p3”: “Netwatch:WAN2”, so you can identify both routes in the Netwatch script.

Netwatch:

Edit both entries you created before for your email notifications.

E.g. for 8.8.8.8 (WAN1): Add

• Down:

  /ip route set [find comment="Netwatch:WAN1"] distance=2;

   

• Up:

  /ip route set [find comment="Netwatch:WAN1"] distance=1;

   

• Do it similar for 8.8.4.4 with “Netwatch:WAN2”

So if Netwatch notices a host and therefore a WAN port is unreachable, it gives the certain route a higher distance (lower priority). As soon as the interface is up again, it changes the distance back to 1.

In my case, WAN_p1 has a higher priority (lower distance) than WAN_p3, which is defined in the DHCPClient (“Default Route Distance”).

 

 

---

References:

http://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting

http://gregsowell.com/?p=819

https://forum.mikrotik.com/viewtopic.php?t=57635

https://forum.mikrotik.com/viewtopic.php?t=85952

http://tiktube.com/video/DofH3iFnjDJomGEoIDFqnrquKlEoLqHq=

https://wiki.mikrotik.com/wiki/MUM_2012_US

https://serverfault.com/questions/658361/how-to-make-connections-answer-from-the-same-gateway-they-entered-in-routeros

http://oriolrius.cat/blog/2016/08/29/internet-fail-over-connection-with-mikrotik/

 

 

 [:]