Nftables: a new packet filtering engine

Posted Mar 25, 2009 0:07 UTC (Wed) by herge (guest, #57423)
Parent article: Nftables: a new packet filtering engine

Will it solve other iptables drawbacks:
- no session replication between two firewalls.
- rule-matching should be done only for the first packet of a connection. Actually it is done per packet when using the filter table. While you can do this with PREROUTING, it should be done as a standard.
- RELATED state whould be handled natively, ne need to add RELATED rules for this.
- matching TIME_WAIT state as a default is dangerous : a short-lived TCP connection will be maintained in the connections' table for too long.
- using macro for rule maintenance, as done by pf.

pf and most commercial firewalls perform that way. Iptables' design is way broken.

to post comments

Nftables: a new packet filtering engine

Posted Mar 25, 2009 1:12 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

it is possible to replicate between firewalls

you can match on every packet of the connection. most people don't bother, but all you have to do is to not put 'if established allow' at the top of your ruleset.

the question of what is done automaticaly and what should be done explicitly can be argued forever, I see this as significantly weakening your RELATED complaint.

where does it match TIME_WAIT by default?

as for macros for rule management, with iptables you can use whatever tools you want in userspace to create your rules.

the things you are listing as drawbacks don't seem as drastic to me as they seem to appear to you.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 10:50 UTC (Wed) by herge (guest, #57423) [Link]

where does it match TIME_WAIT by default?
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
120

Once a connection has reached the TIME_WAIT state, it will be kept in the connection table for 120s.
While it can be tuned down, thei behavior should be dropped IMHO.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 2:16 UTC (Wed) by bduncan (subscriber, #6886) [Link]

iptables had many more drawbacks and I ended up sticking with ipchains for as long as I could. One of the worst was the way it broke logging. Many other issues like the way forwarding was broken making common rules (for both the router as well as the routees) more difficult.

I for one, am eagerly awaiting nftables!

Nftables: a new packet filtering engine

Posted Mar 28, 2009 3:57 UTC (Sat) by rusty (guest, #26) [Link]

> Will it solve other iptables drawbacks:
> - no session replication between two firewalls.

Well, that's not really a core iptables responsibility, IMHO.

> - rule-matching should be done only for the first packet of a
> connection. Actually it is done per packet when using the filter table.
> While you can do this with PREROUTING, it should be done as a standard.

Um, this is pretty trivial to set up. You probably want something like:
iptables -N NEWPKTS
iptables -A INPUT -m state --state NEW,INVALID -j NEWPKTS

Then put your rules in the NEWPKTS chain. (For simpler setups, you
can just have your first rule accept all ESTABLISHED and RELATED packets).

> - RELATED state whould be handled natively, ne need to add RELATED rules for this.

But if someone wants to log related packets, such an implicit rule would be a PITA.

> - matching TIME_WAIT state as a default is dangerous : a short-lived TCP
> connection will be maintained in the connections' table for too long.

There's an argument that the assured bit should be reset for TIME_WAIT conns (which makes the eligible for reaping if we need to make space), but you have to keep tracking conns through TIME_WAIT; the state is there in TCP for a reason!

> - using macro for rule maintenance, as done by pf.

This, I think, is your real issue: iptables is too low-level. I agree, but it was a deliberate decision to leave building the higher levels to someone else. As I've alluded elsewhere, it didn't really work.

> pf and most commercial firewalls perform that way. Iptables' design is
> way broken.

See above.

Hope that clarifies,
Rusty.