FastPath/FastTrack with conntrack off

[shyrwall]

Hi

I need clarification on something i don’t really understand.

So let’s first say I have 1 firewall rule. What the rule does is not important. But it’s there so “fastpath” is disabled.

I then also disable all connection tracking by using “no track” in the RAW table (haven’t tried if the scenario below is different if i just disabled conntrack all together).

I then do a wget between 2 boxes on 10G and I get around 2Gbit/s.

I then enable the connection tracking and create fasttrack-rules.

Then doing the same wget gives me 9.6Gbit/s.

–

I understand that just disabling conntrack will still make the packets go through the firewall so this will slow it down.

My question is what rules can I make to achieve something similar to “fasttrack” with conntrack off?

[msatter]

With conntrack and fasttrack enabled only the first packet of a connection is checked over (established). All packets on the same connection are then waved through and not checked at all.

You have to to tell conntrack which traffic should be waved through after checking the first package.

[shyrwall]

With conntrack and fasttrack enabled only the first packet of a connection is checked over (established). All packets on the same connection are then waved through and not checked at all.

You have to to tell conntrack which traffic should be waved through after checking the first package.

Like I said. I want conntrack disabled and still use fastpath/fastrack-features (even if its maybe called something else). In our environment we can’t use connection tracking. The routers would die.

It feels weird that turning off conntrack (which is a cpu heavy feature) drops the performance of the router by /10.

If there isn’t some feature available to rectify this it feels more like a bug.

[mkx]

I’ve never seen any explanation about how fasttrack really performs (could be that MT considers it a trade secret).

It, however, seems that fasttrack completely bypasses (stateful part of) firewall for packets belonging connections marked for fasttracking. Which means only non-fasttracked packets go through firewall engine, ideally those woukd be only initial packets.
Setting “no tracking” does not cause to bypass firewall, it only causes them to bypass the connection tracking classification (which addmitedly is one of more expensive firewall functions). However, firewall filter rules (if any) still have to be evaluated, which is more expensive than simple check if firewall can be bypassed.

Bottom line is: working connection tracking, making fasttrack possible, enables better performance than disabled connection tracking without possibility for fast tracking. If one can live with raw firewall filters (which in turn can proove less efficient than stateful firewall with fasttrack), then stateful firewall might not be necessary and connection tracking could be disabled.

[msatter]

With conntrack and fasttrack enabled only the first packet of a connection is checked over (established). All packets on the same connection are then waved through and not checked at all.

You have to to tell conntrack which traffic should be waved through after checking the first package.

Like I said. I want conntrack disabled and still use fastpath/fastrack-features (even if its maybe called something else). In our environment we can’t use connection tracking. The routers would die.

It feels weird that turning off conntrack (which is a cpu heavy feature) drops the performance of the router by /10.

If there isn’t some feature available to rectify this it feels more like a bug.

So, where did I not answer question?

[shyrwall]

With conntrack and fasttrack enabled only the first packet of a connection is checked over (established). All packets on the same connection are then waved through and not checked at all.

You have to to tell conntrack which traffic should be waved through after checking the first package.

Like I said. I want conntrack disabled and still use fastpath/fastrack-features (even if its maybe called something else). In our environment we can’t use connection tracking. The routers would die.

It feels weird that turning off conntrack (which is a cpu heavy feature) drops the performance of the router by /10.

If there isn’t some feature available to rectify this it feels more like a bug.

So, where did I not answer question?

Umm not at all? My question was “My question is what rules can I make to achieve something similar to “fasttrack” with conntrack off?” and you just explained how fasttrack worked.

[shyrwall]

I’ve never seen any explanation about how fasttrack really performs (could be that MT considers it a trade secret).

It, however, seems that fasttrack completely bypasses (stateful part of) firewall for packets belonging connections marked for fasttracking. Which means only non-fasttracked packets go through firewall engine, ideally those woukd be only initial packets.
Setting “no tracking” does not cause to bypass firewall, it only causes them to bypass the connection tracking classification (which addmitedly is one of more expensive firewall functions). However, firewall filter rules (if any) still have to be evaluated, which is more expensive than simple check if firewall can be bypassed.

Bottom line is: working connection tracking, making fasttrack possible, enables better performance than disabled connection tracking without possibility for fast tracking. If one can live with raw firewall filters (which in turn can proove less efficient than stateful firewall with fasttrack), then stateful firewall might not be necessary and connection tracking could be disabled.

I’m sure it can be seen by just rooting the x86 or CHR install and checking I would expect its also just using the raw table in some way. Actually I will check on a CHR now.

Why I can’t run conntrack is because I would have several million entries and it just makes the whole box behave weird and sometimes even crashing. Not that I would expect like a pure linux router to be able to handle those amounts in the conntrack table either.

And not that a pure router should be using conntrack.. it really shouldn’t.

[mkx]

So, where did I not answer question?

OP somehow think that conntrack and fasttrack don’t have anything in common. However, the truth is that fastrack is actually a smart way of using conntrack tables, without conntrack it can’t work. One can’t have the former without the later.

BTW, not many smart firewall rules are possible without conntrack. What remains are raw firewall rules which work without conntrack.

BTW2, pure router doesn’t need conntrack at all, it’s firewall that needs that. Pure router should have whole /ip firewall section empty and I’d expect that in this case the performance would be decent (check official test results and compare “Routing - none (fast path)” with “Routing - N IP filter rules” …

BTW3, if your router is routing several million concurrent connections, then maybe you should be looking at a solution with higher capacity (and pricetag).

[shyrwall]

So, where did I not answer question?

OP somehow think that conntrack and fasttrack don’t have anything in common. However, the truth is that fastrack is actually a smart way of using conntrack tables, without conntrack it can’t work. One can’t have the former without the later.


BTW, not many smart firewall rules are possible without conntrack. What remains are raw firewall rules which work without conntrack.

BTW2, pure router doesn’t need conntrack at all, it’s firewall that needs that. Pure router should have whole /ip firewall section empty and I’d expect that in this case the performance would be decent (check official test results and compare “Routing - none (fast path)” with “Routing - N IP filter rules” …

BTW3, if your router is routing several million concurrent connections, then maybe you should be looking at a solution with higher capacity (and pricetag).

I know that. And I said so in my original post. Fastrack is just a fancy word for marking an established connection state so that it laters bypasses the firewall entirely. That’s why i wrote "similar to “fasttrack” " because I wouldn’t know what to call the feature.

BTW1 - Obviously not. But in a sane world INPUT rules would not have disabled fastpath on forwarded packets.

BTW2 - A “pure router” on the internet needs firewall rules for many reasons. Negate BGP TCP Reset attacks. Limit certain DDOS attacks like NTP amplifications. Neither of these would touch anything related to connection tracking.

BTW3 - So instead of Mikrotik just making it behave like any other router out there i should buy other hardware?

So let’s go through this,

You have a connection and once that connection hits the established state it is then “fasttracked” which means there is some packet handler somewhere before or in the raw table that matches an incoming packet and sees if its part of the connection in the conntrack table. If it is then the firewall/netfilter processing ends there.

There should be no reason that I couldn’t also make a rule that says “if the dst-ip is 1.1.1.1 then fastpath”. Why? Because to match the incoming packet against the conntrack-table it has to open the packet up and check srcip,srcport+dstip,dstport to match it to the table. Hence the same fastpath processor could also just match my “if dst-ip is 1.1.1.1” rule and also fastpath the packet.

[mkx]

BTW3 - So instead of Mikrotik just making it behave like any other router out there i should buy other hardware?

Mikrotik has many virtues but high speed firewalling is not one of them. I’m not saying MT should avoid this merket, but it’s obvously not in their focus … not right now.

There should be no reason that I couldn’t also make a rule that says “if the dst-ip is 1.1.1.1 then fastpath”. Why? Because to match the incoming packet against the conntrack-table it has to open the packet up and check srcip,srcport+dstip,dstport to match it to the table. Hence the same fastpath processor could also just match my “if dst-ip is 1.1.1.1” rule and also fastpath the packet.

This is not an user forum question, it’s a feature request

Mind that single rule wouldn’t do the whole job, connection tracking machinery recognizes return traffic as well and sometimes that’s not trivial to do by hand and in advance.

[shyrwall]

BTW3 - So instead of Mikrotik just making it behave like any other router out there i should buy other hardware?

Mikrotik has many virtues but high speed firewalling is not one of them. I’m not saying MT should avoid this merket, but it’s obvously not in their focus … not right now.

There should be no reason that I couldn’t also make a rule that says “if the dst-ip is 1.1.1.1 then fastpath”. Why? Because to match the incoming packet against the conntrack-table it has to open the packet up and check srcip,srcport+dstip,dstport to match it to the table. Hence the same fastpath processor could also just match my “if dst-ip is 1.1.1.1” rule and also fastpath the packet.

This is not an user forum question, it’s a feature request

Mind that single rule wouldn’t do the whole job, connection tracking machinery recognizes return traffic as well and sometimes that’s not trivial to do by hand and in advance.

Let’s just say the usual. It will be fixed in ROS v7