MikroTik: return traffic via the same gateway it came through

There is a MikroTik router with port forwarding configured — we forward some port to an internal server. Everything works while the router looks to the Internet via a single gateway. But as soon as a second — backup WAN, VPN tunnel with BGP routes, whatever — appears, the classic problem begins: the connection is established via WAN1, the request reaches the server, but the reply goes out via WAN2. The client sees a RST or just waits until timeout because the packet came from a different IP.

Client → [WAN1] → MikroTik --dstnat--> 192.168.1.10
                                              ↓
Client ← [WAN2] ← MikroTik <-----------  reply

This is asymmetric routing. It can be fixed cleanly — without touching the main table and without breaking other traffic.

Why RouterOS does this

When the server sends a reply packet, RouterOS looks into the main routing table and chooses the best route to the destination address. If main contains multiple default routes or BGP injected prefixes, the router will quite legally send the packet out via a different interface. It is not obliged to “remember” where the original request came from. This is normal behavior for an L3 router, which in this case works against us.

Solution: separate routing table for dstnat traffic

The idea is simple: mark only those connections that came in via WAN1 and passed through dstnat, and force them to use a separate routing table that has a single route — back via WAN1. Everything else continues as before.

Step 1 — create a separate routing table

/routing table add name=via-wan1 fib

Step 2 — add a default route through WAN1 to it

/ip route add \
    dst-address=0.0.0.0/0 \
    gateway=<WAN1_GATEWAY> \
    routing-table=via-wan1

Step 3 — mark the relevant connections via mangle

There are two rules here, and it’s important to understand why both are needed.

The first rule triggers on input via WAN1 and only on packets that have already gone through dstnat. It marks the whole connection:

/ip firewall mangle add \
    chain=prerouting \
    in-interface=<WAN1_INTERFACE> \
    connection-nat-state=dstnat \
    action=mark-connection \
    new-connection-mark=from-wan1-dstnat \
    passthrough=yes \
    comment="Mark dstnat connections from WAN1"

The second rule works without binding to an interface — it catches all packets of the marked connection, including replies coming from the LAN side, and sets a routing-mark on them:

/ip firewall mangle add \
    chain=prerouting \
    connection-mark=from-wan1-dstnat \
    action=mark-routing \
    new-routing-mark=via-wan1 \
    passthrough=no \
    comment="Route dstnat replies back via WAN1"

Step 4 — bind the routing-mark to the table

/routing rule add \
    routing-mark=via-wan1 \
    action=lookup \
    table=via-wan1 \
    comment="dstnat reply via WAN1"

What happens inside

Incoming packet goes the usual path: WAN1 → prerouting → dstnat changes dst-address to 192.168.1.10 → mangle #1 sets connection-mark=from-wan1-dstnat → mangle #2 sets routing-mark=via-wan1 → the packet goes to the server.

Reply packet returns from the server via the LAN interface. In prerouting connection tracking sees that this connection is marked as from-wan1-dstnat, mangle #2 triggers again and sets routing-mark=via-wan1. Then the routing rule directs the packet to the via-wan1 table, where the only route is via WAN1. In postrouting srcnat/masquerade the public IP of WAN1 is applied. The client receives the reply from the same address it used to establish the connection.

One nuance often overlooked: connection-nat-state=dstnat is checked after NAT rules have been applied. By the time this match runs, RouterOS already knows that the connection went through dstnat. That is why the first mangle rule filters by both interface and nat-state.

What to watch out for

Fasttrack. If you have fasttrack configured (connection-state=established,related), it can bypass mangle. This is not a theoretical issue — fasttrack is enabled by default in typical configurations. Make sure the mark-routing rule with passthrough=no is placed in the queue before fasttrack, otherwise established connections will skip past it.

Multiple external interfaces. The scheme scales well: for WAN2 create a via-wan2 table, a default via the second gateway, and an analogous pair of mangle rules. Each interface lives in its own table and they don’t interfere.

BGP. This problem is most pronounced in BGP environments — BGP can override default routes and the main table becomes unpredictable for interface selection. An isolated table via-wan1 is unaffected by that.

Verification

Check that connections actually receive the correct mark:

/ip firewall connection print where connection-mark=from-wan1-dstnat

Check routing rules:

/routing rule print

Check the route in the isolated table:

/ip route print where routing-table=via-wan1

If replies still go the wrong way — first thing to check is the order of rules in mangle (/ip firewall mangle print). Most likely fasttrack is placed before the needed rule.

Summary

Four commands, no changes to main, other traffic unaffected.