Problems with 2.2

1. No infrastructure established for passing packet to userspace
   • Kernel coding is hard
   • Kernel coding must be done in C/C++
   • Dynamic filtering policies do not belong in kernel
   • 2.2 introduced copying packets to userspace via netlink, but reinjecting packets is slow, and subject to `sanity' checks (eg. reinjecting packet claiming to come from an existing interface is not possible).

2. Transparent proxying is a crock
   • We look up every packet to see if there is a socket bound to that address
   • Root is allowed to bind to foreign addresses
   • Can't redirect locally-generated packets
   • REDIRECT doesn't handle UDP replies: redirecting UDP named packets to 1153 doesn't work because some clients don't like replies coming from anything other than port 53.
   • REDIRECT doesn't coordinate with tcp/udp port allocation: a user may get a port shadowed by a REDIRECT rule.
   • Has been broken at least twice during 2.1 series
   • 2.2.1 stats on code:
     CONFIG_IP_TRANSPARENT_PROXY: 34 occurances in 11 files.
     CONFIG_IP_FIREWALL: 10 occurrances in 5 files.
     

3. Creating packet filter rules independent of interface addresses is not possible
   • Must know local interface addresses to distinguish locally-generated or locally-terminating packets from through packets.
     • Even that is not enough in cases of redirection or masquerading.
   • Forward chain only has information on outgoing interface.

4. Masquerading is tacked onto packet filtering
   • Interactions between packet filtering and masquerading make firewalling complex
     • At input filtering, reply packets appear to be destined for box itself
     • At forward filtering, demasqueraded packets are not seen at all
     • At output filtering, packets appear to come from local box.

5. TOS manipulation, redirect, ICMP unreachable and mark (which can effect port forwarding, routing, and QoS) are tacked onto packet filter code as well.

6. ipchains code is neither modular, nor extensible (eg. MAC address filtering, options filtering, etc).

7. Lack of sufficient infrastructure has led to profusions of different techniques:
   • Masquerading, plus per-protocol modules.
   • Fast NAT by routing code (doesn't have per-protocol handling).
   • Port forwarding, redirect, auto forwarding.
   • No NAPT solution other than masquerading.

8. Incompatibility between CONFIG_NET_FASTROUTE and packet filtering
   • Forwarded packets traverse three chains anyway
   • No way to tell if these chains can be bypassed

9. Inspection of packets dropped due to routing protection (eg. Source Address Verification) not possible.

10. No way of atomically reading counters on packet filter rules.