Recursive Routing elicits "inbound" issue

I’ve configured recursive routing with ping-based failover detection using 1.1.1.1 and 8.8.8.8. The setup works when the primary routes (0 & 1) are disabled, defaulting to the 192.168.0.1 gateway with distance 5.

Current Configuration

[admin@roca] > /ip/route/print
Flags: D - DYNAMIC; X, I, A - ACTIVE; c, s, d, y - BGP-MPLS-VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY      DISTANCE
0  Xs 0.0.0.0/0       1.1.1.1             2
1  Xs 0.0.0.0/0       8.8.8.8             3
  DAd 0.0.0.0/0       192.168.0.1         5
  D d 0.0.0.0/0       10.16.19.1         10
2  As 1.1.1.1/32      192.198.0.1         1
3  As 8.8.8.8/32      192.168.0.1         1
  DAc 10.16.19.1/32   ether2              0
  DAc 192.168.0.0/24  ether1              0
  DAd 192.168.5.1/32  10.16.19.1         10
[...]

[admin@roca] > /ip/route/print detail
Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp
 0  Xs  dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=1.1.1.1 check-gateway=ping distance=2 target-scope=32 suppress-hw-offload=no
 1  Xs  dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=8.8.8.8 check-gateway=ping distance=3 target-scope=32 suppress-hw-offload=no
   DAd  dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=192.168.0.1 immediate-gw=192.168.0.1%ether1 distance=5 scope=30 target-scope=10 vrf-interface=ether1 suppress-hw-offload=no
   D d  dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=10.16.19.1 immediate-gw=10.16.19.1%ether2 distance=10 scope=30 target-scope=10 vrf-interface=ether2 suppress-hw-offload=no
 2  As  dst-address=1.1.1.1/32 routing-table=main pref-src="" gateway=192.198.0.1 immediate-gw=192.168.0.1%ether1 distance=1 scope=30 target-scope=31 suppress-hw-offload=no
 3  As  dst-address=8.8.8.8/32 routing-table=main pref-src="" gateway=192.168.0.1 immediate-gw=192.168.0.1%ether1 distance=1 scope=30 target-scope=31 suppress-hw-offload=no
[...]

[admin@roca] > /ip/firewall/nat/print
[...]
18    chain=dstnat action=dst-nat to-addresses=10.10.10.12 to-ports=80 protocol=tcp in-interface-list=WAN dst-port=80 log=no log-prefix=""
19    chain=dstnat action=dst-nat to-addresses=10.10.10.12 to-ports=443 protocol=tcp in-interface-list=WAN dst-port=443 log=no log-prefix=

Problem
When enabling routes 0 & 1 to activate the desired failover setup:

  • Outbound failover functions correctly


  • Inbound connections fail regardless of currently active routes:
  • DST-NAT port forwarding (ports 80 and 443)
  • WireGuard interface connections

Expected Behaviour

  • DST-NAT port forwarding continues to work


  • WireGuard interface connections continue to work

Network Topology

  • WAN Connection:
  • Primary gateway: 192.168.0.1 (DHCP, connected to ether1)
  • Secondary gateway: 10.16.19.1 (DHCP, connected to ether2)


  • LAN Networks:
  • 10.10.10.0/24 (connected to bridge interface, target of port forwarding)
  • 10.10.20.0/24 (connected to guest-wifi interface)


  • VPN Connections:
  • WireGuard interface (wg0) with network 10.8.0.0/24


  • Failover Configuration:
  • Primary route using 1.1.1.1 as a check gateway (distance 2)
  • Secondary route using 8.8.8.8 as a check gateway (distance 3)
  • Both routes above are set to recursively resolve through 192.168.0.1


  • Port Forwarding:
  • Ports 80 and 443 are forwarded to 10.10.10.12


  • Hotspot Feature:
  • Enabled in default configuration with default firewall rules

RouterOS Version
7.10.1

Prior Debugging

  • Manually enabled routes 0 & 1, both, in sync or alternatedly


  • Observed inbound connection failures when failover setup was enabled

Ask, please:

  • Explain the underlying issue and suggest debugging steps


  • Help me fix the DST-NAT with priority


  • Help me address the inbound WireGuard connection issue (if separate from DST-NAT)

/export file=anynameyouwish (minus router serial number, any public WANIP info, keys etc.

Thank you @anav, sincerely for your interest and feedback.

I attached the requested file. I don’t have any further clue, even after sifting through all its entries in order to obfuscate sensitive data (serial, public IP & ports).

I hope your trained eye may be able to spot something.

In the meantime: thank you for your effort to help me with this!
anynameisgood.rsc (10.9 KB)

It turns out the issue was due to a simple oversight:

2  As 1.1.1.1/32      192.198.0.1         1
3  As 8.8.8.8/32      192.168.0.1         1

Where what should have been a

6

became a

9

.

I apologize for the confusion. It seems I was overwhelmed by the complexity and missed this simple mistake.

I hope this eventually serves someone else a lesson!