Nftables: Not addressing VJ channels or userspace tcp

Posted Mar 25, 2009 3:11 UTC (Wed) by dlang (guest, #313)
In reply to: Nftables: Not addressing VJ channels or userspace tcp by ras
Parent article: Nftables: a new packet filtering engine

iptables only has a linear ruleset if you choose to make it be linear.

on just about every real-world ruleset I've needed to deal with I was able to split the ruleset up through multiple tables/chains and not only speed up the processing, but make the ruleset smaller and easier to understand.

it's like the complaint about the inability to log and drop in one command. create a separate chain called LOGDROP with two rules, the first unconditionally logs the packet, the second unconditionally drops the packet. then in your rules where you want to log and drop you don't need two conditionals, you just do -j LOGDROP and it does both.

I've had firewall rulesets drop from 2000+ lines to <200 lines by using fairly simple tricks like having one set of rules that just examines the source/destination IP addresses and jumps to another chain that doesn't look at IP addresses, but only considers ports.

very few people seem to realize the power that comes from creating your own chains and splitting different types of checking between them.

nftables could be a significant win on the performance side, but to get there it really should start out by replicating the XXtables functionality that exists today so that users don't _need_ to care about nftables.

Nftables: Not addressing VJ channels or userspace tcp

Posted Mar 25, 2009 4:02 UTC (Wed) by ras (subscriber, #33059) [Link]

I agree if nftables is to get up Patrick will have to come up with some transition arrangement. Whether that be iptables and nftables co-existing for a while, or nftables emulating iptables rather like ifconfig is now an emulator is probably a matter of taste.

However, that is just my reading of the political wind. Personally I don't would not care if one day nftables just replaced iptables. It would not be a huge job to just replace my firewalls - if there was documentation.

As for speed, I think that is a minor issue compared to the code duplication. If you really want a fast firewall you could use a u32 ingress filter now for many purposes. And that is a problem. These layers all implementing similar functions bloat the kernel, slow things down and complicate things immensely. Networking is hard enough without having several different ways of doing things.

Nftables: Not addressing VJ channels or userspace tcp

Posted Mar 28, 2009 0:04 UTC (Sat) by Nelson (subscriber, #21712) [Link] (1 responses)

That's only partially true. Every maintained, real-world firewall, that is run by a more programmery type admin is this way. Just about all the others are complete cluster-Fs.

I've seen more than a few firewalls where people started adding special rules for things, with no documentation and then it changes hands, and after a while it's big, ugly, and nobody knows why it does what it does and they're afraid to change it.

FWIW, a compiler can optimize those big ugly ones down to the minimal set and they can also optimize them for efficiency. It's just about a perfect compiler problem from a textbook or something.. Since that's the case, while it's nice to let the programmer configure the tables and define why packets should flow through the rules of different ones, but it seems like there is a good case to build that compiler and just solve it for everyone.

I've developed a number of products that make use of netfilter in different ways. I like the goals of NFtables. Some of the netfilter plugins are kind of calcified, some are useless, not all are IPv6 compliant; it's worth cleaning it all up and setting a new benchmark.

Nftables: Not addressing VJ channels or userspace tcp

Posted Apr 6, 2009 8:14 UTC (Mon) by dlang (guest, #313) [Link]

note that I didn't claim that the rulesets _were_ split up cleanly, just that they _could_ be split up cleanly to multiple tables/chains.

the point being that you don't have to throw out the current system to get that, you 'just' need to create the tools to analyse the rulesets and optimize them.

nftables may have some real benefits, but a lot of what's being claimed for it could be done with iptables today, and doing it requires verylimilar tools be written in either case (the difference being if it compiles down to iptables commands or to nftables commands)

it has been commented that iptables was intended to be the assembly language level with the expectation that higher level languages would be written to compile down to it. In practice it is used directly.

it looks like nftables is intended to be the machine language level, making it unsuitable (and effectivly unusable) for admins directly with the expectation that higher level languages will be written to compile down to it.

since the higher level tools were never created for iptables I am concerned that they won't be for nftables, which is why I was calling for the minimum to be a compiler for the existing iptables functions.

people talk a lot about the need for 'high level' firewall/router controls, but as far as I know, nobody has ever produced a usable set of such 'high level' controls. every attempt that I have seen ends up oversimplifying things to the point that they are usable for a very small set of tasks, and as soon as you need _anything_ outside of that set, you have to throw out the 'simple' tool and go back to the low-level tool.