> 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.