So, I am trying to switch from mangle rules using the route action (which works) to routing rules for more efficient use and less CPU cost. The routing rule I configure does not trigger at all and all my searching leads me to a bug, which supposedly has been fixed? Source: viewtopic.php?t=178678
Mangle Rule (working):

/ip firewall mangle
add action=route chain=prerouting dst-address=123.123.123.123 in-interface=WAN passthrough=no route-dst=192.168.9.9

Routing Rule (not working):

/routing table
add disabled=no fib name=RTR02

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.9.9 routing-table=RTR02 suppress-hw-offload=no

/routing rule
add action=lookup-only-in-table dst-address=123.123.123.123/32 table=RTR02

This is on latest stable: 7.15.3

When I disable the Mangle Rule and let the Routing Rule take over, no traffic is forwarded. Am I missing something?

PS: to mods, please approve my post, thank you.

Since the result is different on my 7.15.3 in terms that both ways the packet for "123.123.123.123" does reach "192.168.9.9", something in your overall setup must be different from mine. Without seeing the obfuscated export of your configuration, there is no way to identify that difference.

However, there is a notable difference in the behavior of the router: if the gateway is indicated using action=route in prerouting in mangle, the router sends an ARP request for the actual destination address (123.123.123.123) from the interface through which the gateway (192.168.9.9) is accessible, whereas if the gateway is chosen using a routing table, the router behaves "normally" - it first sends an ARP request to obtain the MAC address of 192.168.9.9 and then sends the IP packet for 123.123.123.123 to that MAC address.

Could it be that they are missing the default route from the custom routing table in the main one?

I have noticed this train of thought on the forum recently and I don't get it. Why presence of a route to a given destination (or even less logically, of a default route) in the main table should be a mandatory pre-requisite for a route to that destination to work in another table?

My full config looks like the following (with both mangle and routing rules):
The other router 192.168.9.9 is currently a wireguard peer, but even testing this config with a local router on the same subnet reachable via ARP, the result is the same. Am I missing a reference in the main table for 192.168.9.9, even though it's brought in by the wireguard interface as being reachable on REMOTE1? Could it be fast track, even though i've disabled the fast track rules for testing and there was no difference?

I have noticed this train of thought on the forum recently and I don't get it. Why presence of a route to a given destination (or even less logically, of a default route) in the main table should be a mandatory pre-requisite for a route to that destination to work in another table?

For the following reason:

For a user-created table to be able to resolve the destination, the main routing table should be able to resolve the destination too.

Quote from the MikroTik Docs page for policy routing (https://help.mikrotik.com/docs/display/ ... cy+Routing)

Am I missing a reference in the main table for 192.168.9.9, even though it's brought in by the wireguard interface as being reachable on REMOTE1?

Possibly, better add the route to roll it out as a probable cause. It could also be of higher distance if ECMP is not desired and one gateway is to be preferred over the other

My full config looks like the following (with both mangle and routing rules):

OK, so the difference from the configuration I have used to test it that causes the two to yield different results is that in yours, 123.123.123.123 is an own address of the router whereas in mine it wasn't. This has a huge impact, because the routing rules are evaluted after the routing step that distinguishes between own (local) and other (external) addresses, whereas the mangle rules are evaluated before this step. In RouterOS 6, it used to be even more complicated as mangle rule with action=route was the only way to bypass that own/other address distinction; in RouterOS 7, an action=mark-routing rule bypasses it too.

So to remove the need to use mangle rules to send incoming traffic for 123.123.123.123 via Wireguard, you have to detach that address from the router itself. But doing so will cause another issue - the router will stop responding to the ARP requests regarding that address that are coming from 123.123.123.0/24.

That's actually not a big deal as there are two ways to make a router respond with its own MAC address to received ARP requests regarding external addresses. Both require that a route towards that address was available through some other interface than the one through which the ARP request comes in. But there is also a good news - you actually don't need a separate routing table, you can use main, because a route with a longer destination prefix always takes precedence. So even though attaching 123.123.123.122/24 to ether1 dynamically creates a route to 123.123.123.0/24 via ether1, adding a route to 123.123.123.123/32 via some other gateway than ether1 (in your case, the Wireguard interface) to table main will make traffic to 123.123.123.123 take this "more specific" route. And such a route will also make it possible for the router to selectively respond the incoming ARP requests regarding 123.123.123.123: /ip arp add address=123.123.123.123 published=yes interface=ether1 is the way to do that.

/ip arp add address=123.123.123.123 published=yes interface=ether1 is the way to do that.

Thank you so much, this is all I needed to get my routing rule working!

I added that to my config, disabled the mangle rule, and removed IP address 123.123.123.123. This finally got traffic flowing using the route rule!

So now as the basic issue has been resolved, we can come back to the ones that popped up in the process.

My full config looks like the following (with both mangle and routing rules):

The only chain where an action=fasttrack-connection makes any actual sense is forward. If RouterOS itself is an endpoint of the connection, skipping some stages of packet processing in the firewall, which is the essence of fasttracking, would save a negligible amount of CPU.

For a user-created table to be able to resolve the destination, the main routing table should be able to resolve the destination too.

Quote from the MikroTik Docs page for policy routing (https://help.mikrotik.com/docs/display/ ... cy+Routing)

I know it's thin ice, but I still think the above statement is actually just a simplification aimed to avoid detailing the cases where this is actually required.

One of them is described later on that page - if you intentionally plan on using table main as a fallback one in case that the packet cannot be routed using the preferred table. Another one is when RouterOS itself sends a packet, as in that case, it uses table main unless routing rules indicate a different one, and only if mangle rules eventually assign a different one later, the routing is "adjusted" (actually, repeated, but e.g. the choice of source address made by the first routing is not changed). I cannot imagine any other case.

with what @sindy adviced, do you need /routing rule if at all?

with what @sindy adviced, do you need /routing rule if at all?

I've made some tests and neither the routing rule nor the extra routing table are needed. However the "published" ARP entry doesn't work if ARP mode on the bridge/vlan interface is set to reply-only. The router doesn't answer to the ARP requests with its MAC address. It only does so after switching ARP mode to enabled.