The general information I found states everywhere that you cannot Fasttrack if you want to use Mangle/RAW Firewall rules.
I was trying to block sites using RAW Firewall based on this tutorial https://youtu.be/T2CQyN-D4u4 , which works very well, but only after I disabled Fasttrack.
I am confused, so is Fasttrack supposed to work with RAW Firewall in the end somehow, or the example configuration is not consistent here and it will not work with Fasttrack enabled?
Or am I missing something else here?
My understanding is that there is no interaction between RAW filter firewall rules and fastrack. Raw happens before any connection tracking etc.
Mangling, queues etc are a different story and one has to consider fastrack in the configuration.
Thanks for the reply. That is my understanding as well, yet the “prerouting” rules I create in RAW firewall are completely ignored with Fasttrack enabled. So I was wondering if it in fact is supposed to work together or not, given the help section document having both in there… the answer should be simple yes, it is supposed to work or no, it is not designed to work like this.
Is anyone using this together successfully?
You need to read again…RAW occurs before any conntrack is done… therefore fastrack which comes after never sees the packets that match to the raw filter rules.
Note that if you’re testing by enabling / disabling the rules while you check the connection, this won’t work. As soon as the connection hits fasttrack it will be offloaded to hardware, so it won’t hit any more firewall rules. You need to test with a completely new connection every time.
Fair question. RAW happens before fast-track decision, or it should at least, if it’s in RAW “prerouting”. I would have said the “tls-host” isn’t a support option in RAW, since it uses a restricted subset of allowed things, e.g. stuff in the IP headers. But, no, the RAW section in help.mikrotik.com does list tls-host as an option in RAW.
So we had to go up to the instant reply officials in the booth… Now the YouTube doesn’t lie, fast track is disabled in the video (@56 secs.): https://youtu.be/T2CQyN-D4u4?t=56
The default is for the fast-track rule to be enabled, so @normis likely ran into same trouble and disabled it for the video. Now @normis does do a good job of illustrating the glaring limitations of “tls-host” effectiveness (see mobile phone demo part). The firewall isn’t really designed for kinda content inspection required (e.g. it operates before packet re-assembly so fragmentation can also cause tls-host not to work), so another restriction that requires fast-track being disabled isn’t exactly surprising.
But clearly it doesn’t work with fast-track…whether it should…is a question left open by the docs.
Yes, I understand that, but now I see where the confusion is coming from - I do not actuallly use the RAW rules to directly drop the packets (event though I think it should still work, because exactly as you mention it is happening before any Fasttrack processing), I rather set it to only create address-list entries, which I then block using normal Firewall entry. So Fasttrack not seeing the packets from RAW should not be the problem here. And RAW prerouting happening before the connection tracking made me think that it should process the RAW rules first, since Fasttrack comes into play only in the next step.
But as Amm0 pointed out (good catch btw.), Fasttrack is actually disabled in the video tutorial, and this not working has probably something to do with the “specificness” of using the tls-host feature.
Shame that it does not work with Fasttrack, as there does not seem to be any universal way of blocking unwanted websites these days, without disabling Fasttrack, and even then it is not 100% reliable.