So far I was believing that the action=fasttrack filter rule was treated the same like any other one, i.e. that if any previous rule in the same chain has action=accept or action=drop, the fasttrack rule will not be checked at all.
does not prevent packets whose both source and destination match the (same for both conditions) prefix/masklen from being fasttracked (and thus from bypassing queues, IPsec policies etc.).
Does the action=fasttrack rule work somehow in parallel to the other ones regardless its position in the chain?
Are you talking about dynamic one? or static one? Dynamic is not actually a rule it is just a placeholder to indicate that some of the packets doesn’t get to your firewall at all as they are fasttracked.
you need to find action=fasttrack-connection rule and place your rules before it. then you need to reboot the device , so that all connections are recreated, cause some of your connections might already be fasttracked, and are skipping firewall all toghether,
Are you talking about dynamic one? or static one? Dynamic is not actually a rule it is just a placeholder to indicate that some of the packets doesn’t get to your firewall at all as they are fasttracked.
Never enough to stress this difference given how many people get confused, but in my case, I’m talking about exactly the rule I’ve given in the example, i.e. the manually provided one, not the “statistic-showing” automatic one which cannot be deleted.
you need to find action=fasttrack-connection rule and place your rules before it.
That’s exactly what I did, see my example simplified to the bare bone. But the only way to prevent packets from being fasttracked was to prevent them from being connection-tracked at all using the raw table with action=no-track - which is not what I want, I want them connection-tracked but not fast-tracked.
Then you need to reboot the device, so that all connections are recreated, cause some of your connections might already be fasttracked, and are skipping firewall all toghether.
A good idea as well, but in my case, it was a small number of UDP connections which expire quickly, so I was checking (using /ip firewall connection print where src-address~“prefix” || dst-address~“prefix”) whether they are all gone and only when the list was empty I’ve given that another try.
The actual reason why the IPsec policy was not processing the packets was not that they were fasttracked but that they were src-nated. What prevented me from finding that out quickly is that the action=no-track rule in table raw prevented both fasttrack and src-nat handling.
The exception rule meant to exclude packets which should be tunnelled from being src-nated was there, but I had a brain eclipse and set there an out-interface condition referring to the interface through which the tunnel is running, which is not where the routing sends these packets before the IPsec policy grabs them.