Fasttrack

HI all,
I have my 2 first foward firewall filter rules as follows:

/ip firewall
add action=fasttrack-connection chain=forward  connection-state=established,related,untracked
add action=accept chain=forward  connection-state=established,related,untracked

I see a lot of packets falling through fasttrack. It’s like an almost 50/50 distrubution between those rules, meaning almost exact equal number of packets reach both rules.
My question: is this normal? Shouldn’t the majority of of packets hit fasttrack?

Thanks for your help!
Cheers!

The fasttracking rule marks the connection and then it hits the second rule. Now fastracking will fasttrack most of the subsequend packets of that connection.

So equal numbers is here correct. You can see the actual amount of fastracked packets at top of the table in the dummy fasttrack rules.

Thank you for the clarification. I guess everything is alright then. Probably i misunderstood fasttrack. So it seems fasttrack has no effect on filter rules but only on connection tracking.

Fastracking is available to have higher speeds archievable on the router.

Instead of all traffic going through the each rule, returning traffic that is trusted (marked fasttrack) is redirected at entry point, past all rules, directly to the receiver/client.
To check if the traffic is still trusted some packets, have travel through the rules to be checked. This is called ‘slow’ path.

See: https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS#PacketFlowinRouterOS-Fasttrack

So does that mean that the packets I see hitting the fasttrack rule are only the packets that are needed form time-to-time to check if the the connection is still valid?

It is the first establised, related and untracked packet in your case of a connection and the packets that go over the slow path.

Untracked does not really fit in a fastracking rule because that can be unproven connections and you are waving it past the rules.

@msatter thanks, so i got it right.

Regarding untracked, I took the rule from here: https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall

Almost, also the first est/rel packet is counted.

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
  add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked

Taken from that page and I don’t see untracked in the fasttracking line. That make sense because you want to fasttrack an untracked connection.

Oops my mistake. Thanks for the hint.

Would you mind explaining why an untracked connection should not be fasttracked? Is it because an untracked connection cannot be fasttracked because it is not tracked by definition?
Does it even have an effect to mark untracked as fasttrack? Would that somehow make an untracked connection tracked?

Sorry for all the questions, but it’s not 100% clear to me . Thank you! I really appreciate your help!

You want something to be tracked that told earlier to untracked. That makes no sense.

Connection state notrack is a special case when RAW firewall rules are used to exclude connection from connection tracking. This one rule would make all forwarded traffic bypass the connection tracking engine speeding packet processing through the device.

You get about 30% speed advantage by no track but you are then depended on other ways to, direct traffic. An example is IPSEC that can manage the flow of the IPSEC traffic (policy).

Connection tracking is an intensive task and on DDoS or a other brute force attacks you want to keep that traffic away from reaching connection tracking. RAW sits before connection tracking and there you can tell which traffic is dropped, untracked or allowed (default) to use connection tracking.

And yet an other help page: https://help.mikrotik.com/docs/display/ROS/Basic+Concepts#BasicConcepts-ConnectionTracking

The same info is different location in the help pages and more cross pointers would make things easier.

Thanks. I think I got it now. I’m also using RAW, however only for early dropping packets, not to mark as notrack.