Routing Mark and route traffic to a different GW

RouterOS RouterOS beta
1

Hi,

i’ve read several messages about issues migrating from 6.x to 7.x about routing marks and routing tables,
but i didn’t find a way to repair my issue after upgrading fw.

Before upgrade, i’ve a router Mk with 2 different gateway, my conf was done for having access via ssh from second gateway to router Mk, replay packets needs to flow to second gateway and not to default gateway (default route).

My solution: mark connections and packets, then a static router take marked packet to secondary gateway, and was working well, till i’ve upgraded to routerOs 7.5.

Here my actual non-working conf:

/routing table
add fib name=FIB
add fib name=MNG-Traffic-OUT
add fib name=ULLmkr


/ip firewall mangle
add action=mark-connection chain=prerouting comment="Mark connection from ULL (Router MAC ADDRESS) NOT src-natted" connection-mark=no-mark connection-nat-state=!srcnat in-interface=bridge1 \
    log-prefix=ULL_conn_log new-connection-mark=ULL_connection passthrough=no src-mac-address=2C:91:AB:47:36:48
add action=mark-routing chain=prerouting comment="Mark routing to ULL" connection-mark=ULL_connection in-interface=bridge1 log-prefix=ULL_routing_mark_prerouting_log new-routing-mark=ULLmkr passthrough=no
add action=mark-routing chain=output comment="Mark routing to ULL" connection-mark=ULL_connection log-prefix=ULL_routing_mark_output_log new-routing-mark=ULLmkr passthrough=no

/ip route
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.0.1.253 pref-src="" routing-table=ULLmkr suppress-hw-offload=no

someone can help me to find error(s)?

thanks!

2

If I understand correctly what you have, then just remove second rule in prerouting and it should help. If you’re dealing only with access to router itself (not to some other device behind it), then this rule was always useless, but previously harmless, because it did essentially nothing. But recent change in v7 activated it and now it does something (and you don’t want that). You can also move first rule from prerouting to input chain to speed up processing a bit (not really noticeable).

3

Hi Sob, this the second time you have said something similar.
Is prerouting in ver7 going the way of the dodo bird for mangle rules?

4

Yeah, it was this thread and there was similarly useless rule as is (seems to be) here. It’s useless because if you want to handle only connections to router, you want to mark routing for responses and it happens in output chain (prerouting would be used for forwarded port to internal server). Otherwise there’s nothing wrong with prerouting, it’s the same as it always was.

What changed is handling of packets with routing marks. Previously in v6 and initially also in v7, there was:

  1. Hardcoded exception for local destinations (addresses on router). Even if there was routing table with only single default route (meaning that everything should be sent to that gateway), if destination was router’s own address, it didn’t happen. Recent v7 changed this and routing marks have maximum priority. So even if destination is local, routing mark says that it should use that other routing table => it has only one default route => packet is sent to that gateway, i.e. back to internet. It’s what happens here.

  2. Routing rules could override routing marks. Not anymore. So e.g. my favourite rule that forced destinations on local subnet to use only main routing table, regardless of routing mark, no longer works:

/ip route rule
add action=lookup-only-in-table dst-address=192.168.0.0/16 table=main

Instead, you must make sure to not assign routing marks to those packets. Which is doable, but can be a bit annoying, because this was simpler.

5

This may or may not help with this type of situation, but on RouterOS v7 I do something like this, to force any packets on VPN_VLAN through my Wireguard VPN, without needing mangle rules at all:

/routing rule
add action=lookup disabled=no interface=VPN_VLAN min-prefix=1 table=main
add action=lookup disabled=no interface=VPN_VLAN table=vpn

The first rule forces anything that is /1 or larger to use the “main” table, the second rule has /0 (the default route) use the “vpn” table. In this way, packets destined for any local subnets (or other subnets that the router has more specific routes for) will take that path, but the gateway of last resort will use the default route from the “vpn” table instead. These rules work for both IPv4 and IPv6, as there is no need to specify addresses. I find this approach much simpler than policy routing on RouterOS v6 in most cases, as it is easier to implement without accidentally creating loops of traffic where incoming traffic is accidentally policy routed back out.

6

Thanks for explanation, it’s work now!


7

I stumbled into the same problem. For reference, here is my IPv4 and IPv6 configuration to route incoming package correctly back to my second WAN interface:

/ip firewall mangle
add action=mark-connection chain=prerouting connection-state=new \ 
    in-interface=HETZNER log-prefix=HETZNER_pre_in4 new-connection-mark=HETZNER_con passthrough=no
add action=mark-routing chain=output connection-mark=HETZNER_con \ 
    log-prefix=HETZNER_out4 new-routing-mark=HETZNER_rt passthrough=yes
add action=mark-routing chain=prerouting connection-mark=HETZNER_con \
    in-interface=!HETZNER log-prefix=HETZNER_pre4 new-routing-mark=HETZNER_rt passthrough=yes
    
/ip route
add comment=HETZNER_rt dst-address=0.0.0.0/0 gateway=1.2.3.65 routing-table=HETZNER_rt
add comment=HETZNER_rt dst-address=1.2.3.64/28 gateway=HETZNER routing-table=HETZNER_rt

/routing table
add disabled=no fib name=HETZNER_rt

/routing rule
add action=lookup-only-in-table disabled=no routing-mark=HETZNER_rt table=HETZNER_rt

/ipv6 firewall mangle
add action=mark-connection chain=prerouting connection-state=new \ 
    in-interface=HETZNER log-prefix=HETZNER_pre_in6 new-connection-mark=HETZNER_con passthrough=no
add action=mark-routing chain=output connection-mark=HETZNER_con \ 
    log-prefix=HETZNER_out6 new-routing-mark=HETZNER_rt passthrough=yes
add action=mark-routing chain=prerouting connection-mark=HETZNER_con \
    in-interface=!HETZNER log-prefix=HETZNER_pre6 new-routing-mark=HETZNER_rt passthrough=yes
    
/ipv6 route
add comment=HETZNER_rt disabled=no distance=1 dst-address=::/0 gateway=1:2:3:4::1 \
    routing-table=HETZNER_rt
add comment=HETZNER_rt disabled=no distance=1 dst-address=1:2:3:4::/64 gateway=HETZNER \
    routing-table=HETZNER_rt
8

Sob,

Thank you for the findings. Upgraded to RoS 7.5 from 7.21 and hit this issue. Anav, I think this makes your New User Pathway To Config Success thread in need of an update.