Mikrotik chain terminology explained?

RouterOS Beginner Basics
1

I never had problem with networks, i do understand the packet flows, how tcp sessions work etc. but mikrotik is killing me on terminology.

Currently I am trying to mark ssh traffic on home router to further QoS it (didnt get there yet) and I am confused by the terminology used and after a bit of thinking I am constantly bumping into bunch of terms which are typically lacking the direction.

If I just check the Chain rule in ip firewall mangle:
forward, input, output, prerouting, postrouting.

Ingoing, outgoing, this would make sense to me. Input? Is this ingoing? Output? Is outgoing? Prerouting and postrouting, this is when? At packets comming to the port and before it leaves?

I would imagine that there is something that should tell firewall to follow the tcp stream and mark all packets going out, but looks like we speak different language… totally confusing.

Terminology is just so confusing, is there some article (due to sheer amount of different terms, with pictures :smiley:) that would explain terms? I can write my own tcp stack but mikrotik wording is really killing me…

2

Perhaps this wiki article will make things more clear to you?

3

Thank you so much… fiu… I have found physical in and out interfaces… lets see…

(dont understand me wrong, I am not complaining, actually its a bit fun :slight_smile: A puzzle… :slight_smile: )

4

I agree, it’s not a good-night reading, but explains quite a lot. If you manage to get through and understand most, then you’ll know quite much about how ROS handles traffic.

5

A stupid question, chain forward on ether1 (that is my uplink), action=mark-connection when marking dst-tcp, dst-port 22 is showing me statistics that match packets count while size is incrementing for around ~40 bytes per packet which would come to roughly size of their headers ~40 bytes. Is this how statistic works (as in theory firewall doesnt need to handle the data segment at all) or I am missing something?

6

I’m not sure what you have configured.

However, be careful about fast-track. By default it’s enabled (it’s a firewall filter rule) and when a connection gets fast-tracked, packets belonging to it will bypass most of firewall stuff and further packets won’t get counted by any firewall filter rule[*]. And default setup is such that connection gets fast-tracked as soon as its state reaches “connected” which for TCP connection happens right after initial SYN SYNACK exchange, which usually only consists of IP+TCP headers.
OTOH, if the packet count actually reflects the further traffic as well, but byte count seemingly only counts 40 bytes per packet, then this is some kind of a bug.

[*]What I wrote above is not the whole truth. Even if connection is fast-tracked, some packets will pass the usual “slow-path” to keep connection tracking state current. If fast-tracking is misconfigured, it’ll show as extremely slow connection and the reason is that only packets taking the sliw-path actually reach final destination. And it’s easy to break fast-tracking when configuring mangling, these two features are mutually exclusive (on per-connection basis, so if connections which should be mangled can be separated from conneczions which should be fast-tracked using some criteria, both features can be used in parallel).

7

Ok, this might explain it, I am observing “special dummy rule to show fasttrack counters” and they are showing the correct values, while mine is only getting peanuts…

ip firewall mangle chain=forward action=mark-connection new-connection-mark=ssh-session passthrough=yes protocol=tcp dst-port=22 log=yes log-prefix="ssh-session" 
ip firewall mangle chain=prerouting action=mark-packet new-packet-mark=ssh-packet passthrough=yes connection-mark=ssh-session log=no log-prefix=""

The idea was to first mark the tcp connection and then mark the packets (as queues work on packet level). But this fasttrack does make sense, it is bypassing my mangle rule…

Thank you again, I would be digging for this for quite a while… now going to study fasttrack… and people are telling dvorak keyboard is having a steep learning curve… this is better :smiley:

8 
ip firewall filter chain=forward action=fasttrack-connection connection-state=established,related connection-mark=!ssh-session log=no

Works like a charm, interestingly it didnt work on !22 but it works on connection-mark=!ssh-session

And… queue :slight_smile:

/queue simple add comment="queue to limit ssh traffic (pcq - all users equaly)" limit-at=0/56M max-limit=0/56M name=queue-ssh-limit packet-marks=ssh-packet queue=pcq-upload-default/pcq-download-default target=""

(I’ll am a bit verbose here as someone else might get stuck in same point)

9

One more hint: firewall filter rules are applied to packets in order from top to bottom. So your fast-track rule could be rewritten into two:


/ip firewall filter
add chain=forward action=accept connection-state=established,related connection-mark=ssh-session log=no
add chain=forward action=fasttrack-connection connection-state=established,related log=no

Performance wise it doesn’t make much of a difference[*], but it is slightly more versatile as you can add more exclusions from fast-tracking. And apart from added rules the rule list remains the same as default rules (which are, IMHO, pretty good).

[*]This variant is slightly slower for all packets not fast-tracked yet and which are not connection marked with ssh-session as they are matched agains one rule more than in your scenario.

10

I guess you used dst-port=!22 … so fast-track rule kicked in on return packets (which have src-port=22) but connection state is established as well. When using connection-mark, then the direction of a packet doesn’t matter any more since connection tracking machinery did its job already.