I implemented a redundant WAN connection so that if the primary WAN connection became unavailable, Internet traffic would automatically switch to a secondary WAN link.
The office required continuous Internet access for employees, while IP cameras and other network-connected devices also needed reliable connectivity. To meet this requirement, I added a second WAN connection to the MikroTik router and configured a backup default route with a higher administrative distance. I then implemented a connectivity-probing mechanism to detect Internet reachability and automatically switch between the two WAN links.
The primary WAN remained preferred whenever it was available. If the primary connection failed, traffic was automatically routed through the secondary WAN. When the primary connection recovered, traffic automatically returned to it.
The main objective was to provide automatic WAN failover while ensuring that the router tested actual Internet connectivity rather than only the physical interface or local gateway.
The project objectives were:
Add a second WAN interface to the existing MikroTik router.
Configure WAN-1 as the primary Internet connection and WAN-2 as the backup connection.
Monitor Internet connectivity on both WAN links.
Automatically move traffic to WAN-2 when WAN-1 became unavailable.
Automatically return traffic to WAN-1 when Internet connectivity was restored.
Keep the failover and recovery process within the required 30-second interruption window.
Minimize CPU and resource usage because the existing router was already reaching approximately 70% CPU utilization.
The existing edge router had limited processing capacity, so the monitoring mechanism needed to have minimal overhead. For this reason, I avoided using a continuously running script to perform the connectivity checks and instead used RouterOS routing and gateway-checking features.
Another requirement was that the failover mechanism detect loss of Internet connectivity even when the physical Ethernet link remained up. This was important because disconnecting the Internet upstream from the fiber modem would not necessarily cause the Ethernet interface itself to go down.
The office's critical online service also required users to sign in again if their connection was interrupted for more than approximately 30 seconds. Therefore, the failover mechanism needed to detect failures and restore connectivity quickly enough to remain within this requirement.
The environment was an office network with approximately 35 employees who needed internet access. The network also supported IP cameras and ticketing kiosks.
The infrastructure consisted of:
A MikroTik edge router.
Two managed switches.
A fiber modem providing a 200 Mbps Internet connection.
A wireless radio providing a second 16 Mbps dedicated Internet connection from another ISP.
Wireless access for mobile users.
VPN and firewall services running on the MikroTik router.
Internet / ISP 1 Internet / ISP 2
| |
Fibre Modem Wireless Radio
200 Mbps Link 16 Mbps Link
| |
| |
ether1 / WAN-1 ether2 / WAN-2
| |
v v
+----------------------+
| MikroTik Core |
| Router |
| Firewall / VPN / DHCP|
| DNS / Routing / WLAN |
+----------+-----------+
|
---------------------------------------------
| |
SW-1 SW-2
| |
LAN Users Devices
| |
PCs / Devices Kiosks / IP Cameras
Some users connected wirelessly to the MikroTik router because they worked in different areas of the office and frequently changed locations.
The MikroTik router also provided firewall and VPN services for the network.
The internal network was divided into separate subnets:
Network Segment Subnet Purpose Connection
LAN Users 192.168.10.0/26 Wired employee devices SW-1
Wireless Users 192.168.10.128/26 Wireless employee devices MikroTik WLAN
Kiosks 192.168.20.0/28 Ticketing kiosks SW-2
IP Cameras 192.168.30.0/27 IP surveillance cameras SW-2
SW-2 used VLANs to separate kiosk and IP camera traffic before forwarding the traffic toward the router.
Before implementing WAN redundancy, all users and network devices reached the Internet through WAN-1, which was connected to the fiber modem through ether1.
After the failover configuration was implemented, Internet traffic used WAN-1 while it was available. When WAN-1 lost Internet connectivity, traffic automatically moved to WAN-2. When WAN-1 became available again, it regained priority and traffic returned to it.
Fiber Modem: A Huawei fiber modem, provided the primary 200 Mbps Internet connection.
Wireless Radio: A MikroTik SXT Sq 5 ac wireless radio was used as the secondary WAN connection. It received Internet access from a central access point approximately 1.5 km away through a separate ISP, providing a dedicated 16 Mbps connection.
MikroTik Router: A MikroTik RB951Ui-2HnD acted as the core router and provided the main network services.
The router was responsible for:
DHCP: Provided IP addresses for the different network segments.
DNS: Provided DNS caching and static DNS records for local services and used configured upstream DNS servers.
Wireless Access: Provided wireless connectivity for users with laptops and tablets.
Routing: Provided internal routing and the WAN failover mechanism.
Firewall: Controlled traffic between internal and external networks and protected the router and internal clients.
VPN: Provided VPN connectivity for remote access and administration.
NAT: Provided Internet access for private internal networks.
Switches: Two managed switches were used to connect end users and network devices, providing structured access and distribution across the office network.
SW-2 used VLANs to separate kiosk and IP camera traffic and forward the separated networks toward the MikroTik router.
When I started the project, the network was already operating through WAN-1 using the fiber connection.
The existing configuration included:
A DHCP client on ether1 receiving an IP address and gateway from the fiber modem.
A dynamic default route created from the DHCP client.
DHCP servers for wired and wireless clients.
VLAN configuration on the switches.
Existing firewall rules using connection tracking to allow established and related traffic.
Firewall rules that blocked unsolicited traffic from the WAN side, including ICMP traffic to the router.
Adding WAN-2
I connected the wireless radio to ether2 on the MikroTik router using an Ethernet cable.
Because the wireless radio did not provide DHCP on this connection, I manually configured addresses on both sides of the link.
On the wireless radio:
/ip address
add address=192.168.11.142/24 comment="To Core Router" interface=ether1 network=192.168.11.0
On the core router:
/ip address
add address=192.168.11.143/24 comment="Static IP for WAN-2" interface=ether2 network=192.168.11.0
Controlling the WAN-1 Default Route
The existing WAN-1 connection received its address and gateway dynamically from the fiber modem. I disabled automatic default-route installation so that I could control the route priority and configure recursive failover manually.
/ip dhcp-client
add add-default-route=no comment="From Fiber Modem’s DHCP Server" disabled=no interface=ether1 use-peer-dns=no use-peer-ntp=no
RouterOS DHCP clients can otherwise apply a dynamic default route received from the DHCP server. Disabling add-default-route allows the routing table to be managed explicitly.
Connectivity Probing
The next step was to configure probe routes. The purpose of these routes was to test reachability of external destinations through each WAN connection rather than relying only on the local Ethernet link or the ISP gateway.
/ip route
add comment="Probe WAN-1" distance=1 dst-address=1.0.0.2/32 gateway=192.168.88.1
add comment="Probe WAN-2" distance=1 dst-address=1.0.0.3/32 gateway=192.168.11.2
The probe destinations were then used as recursive next hops for the default routes.
Primary WAN Route
I configured WAN-1 as the preferred default route by assigning it a lower route distance:
/ip route
add check-gateway=ping comment="WAN-1 - Fiber Modem" distance=1 gateway=1.0.0.2 target-scope=30
Secondary WAN Route
I configured WAN-2 as the backup route with a higher distance:
/ip route
add check-gateway=ping comment="WAN-2 - Wireless" distance=2 gateway=1.0.0.3 target-scope=30
The router therefore preferred WAN-1 while its probe destination was reachable. If the WAN-1 path became unavailable, its default route became inactive and the higher-distance WAN-2 route became the active path.
I tested the failover mechanism using public IP addresses and traceroute.
First, I verified normal operation while WAN-1 was connected. Traffic used WAN-1, which was visible through the traffic counters on ether1. I also used traceroute to verify the actual path rather than relying only on interface traffic statistics.
Next, I disconnected the fiber connection from the fiber modem while keeping the Ethernet connection between the modem and ether1 physically connected.
This test was important because it simulated an upstream Internet failure while keeping the local Ethernet interface operational. Therefore, the router could not rely only on interface link status to detect the failure.
After several probe failures, traffic automatically moved to WAN-2.
I then restored the fiber connection and waited for the modem and WAN-1 connection to recover. After the connectivity probe succeeded again, traffic automatically returned to WAN-1 because it had the lower route distance.
The recovery time was shorter than the initial failover detection time.
I repeated the test using IP addresses associated with services that were permitted by the firewall and were considered critical to the office. The failover process also worked successfully for this traffic.
The tests verified both scenarios:
WAN-1 becoming unavailable while its Ethernet interface remained physically up.
WAN-1 recovering and automatically becoming the preferred route again.
The observed interruption remained within the approximately 30-second requirement defined for the office's critical online service.
The project successfully implemented redundant Internet connectivity for the office network.
The final configuration provided:
A primary 200 Mbps fiber WAN connection.
A secondary 16 Mbps wireless WAN connection.
Automatic Internet connectivity probing.
Automatic failover from WAN-1 to WAN-2.
Automatic recovery from WAN-2 to WAN-1.
Primary WAN preference using route distance.
Failover detection that did not depend only on Ethernet link status.
Low-overhead monitoring suitable for the existing router's CPU limitations.
Successful testing against normal Internet traffic and selected critical services.
As a result, the office gained automatic WAN redundancy without requiring manual intervention when the primary Internet connection failed. Employees and critical network devices could continue accessing the Internet through the secondary WAN connection, while the primary WAN automatically regained its preferred status after recovery.
All configurations and resources used in this project, including the fully configured and tested RouterOS environment exported in OVA format, are available on my GitHub for reference.