Tagged packets simply do not match any longer in srcnat chain for packets tagged in output chain!

RouterOS General
1

Hi all,

Sorry for posting another question on this topic but I can literally not believe this. Either I am staring too long at it or it’s another weird bug.

I am tagging OUTPUT packets with a route mark to 8.8.8.8:

/ip firewall mangle
add action=mark-routing chain=output dst-address=8.8.8.8 log=\
    yes log-prefix=tagged new-routing-mark=default_wwan passthrough=no

I start ping in a terminal and confirm the packet counter increases for every ICMP packet!

Then I want to match on this mark in srcnat (to perform masquerade eventually) but it is never matched! Actually, it is matched only a single time when I start ping after some time…

/ip firewall nat
add action=passthrough chain=srcnat log=yes log-prefix=MEG routing-mark=default_wwan

I can confirm the packet counters to NOT increase.

WTF?


EDIT: First I thought the solution is indeed trivial: It’s the first packet because the following ones go to connection tracking.
But honestly, I am still a little bit baffled why not every single packet matches. And now I changed it to UDP and the packet counter for the srcnat rule is stuck again at zero…

2

Other packets are accepted in filter established rule

3

That’s not true. The individual stages (tables) of the firewall are passed independently and accept in filter is only relevant for filter.


The nat table is specific in terms that only the initial packet of each connection (connection-state=new) is pushed through it. If the chosen action in the respective chains was dst-nat and/or src-nat for that packet, it is stored in the connection context data and the same (or inverse, depending on their direction) nat treatment is applied to all subsequent packets belonging to the same connection automatically.

So if the UDP flow in question already tracked, adding a NAT rule that matches it will change nothing. You have to remove the tracked connection from the list, so that the connection tracking would treat the next packet in the flow as an initial one.

UDP connections survive 3 minutes by default since the last packet seen; ICMP ping ones survive 10 seconds, but at some point Mikrotik was reusing the same ID for pings so you could hit the previous tracked connection with a new ping. However, mangle rules process every single packet, so for a sequence of 10 pings, you should see the mangle rule to count 10 packets no matter what, at least in chain output where fasttracking cannot break that.

So if there are actually two issues (nat rule not matching at all and mangle rule only matching the initial packet of a connection/sequence), there must be something else behind that. Can you post the complete export as it looks now?

Or have I just misunderstood your edit and everything actually behaves the way I have described (every packet counts in mangle/only first packet counts in nat)?