In my first column last spring I described how Linux's ipchains subsystem was used for IP packet filtering in Linux 2.2. "Packet filtering" involves discarding selected network packets based on the contents of their header. You arrange your network so that all packets pass through your Linux box, and then control from there what types of traffic can flow in and out of your network.

With Linux 2.4, packet filtering will be significantly changed. You'll still be able to use ipchains, but there will be new, more powerful replacements as well. Those of you who are familiar with BSD's ipfilter know how much can be done with packet filtering. This month we'll look at what you can do with "packet mangling," which involves not just dropping but actually modifying packets as we filter them.

IP Packet Mangling in Linux 2.2: Inside the Kernel

To understand why change is necessary, we need to look at how things stand in Linux 2.2. There are four main "packet mangling" subsystems: masquerading, packet filtering, transparent proxying and Fast NAT. Fast NAT (Network Address Translation) is new to Linux 2.2. Russian network überhacker Alexey Kuznetsov provided a method for using the routing code to specify that IP addresses should be translated as they pass through the Linux box. For example, you could tell it to alter packets coming from 192.168.1.1 to appear to be coming from 1.2.3.4; and translate the replies back again. This is simple, and if that's all you want to do, it's lightning fast.

IP masquerading is more sophisticated; like Fast NAT, it alters where packets appear to come from as they pass through the Linux box. However, masquerading always makes the packets appear to come from the Linux box itself. This is extremely useful for dial-up ISP or SOHO ISDN/DSL accounts: when you connect, you are assigned a single IP address. Sending out packets with different source addresses (as other machines on your network would have) won't work -- you'll never get replies.

If you have a full-blown LAN linked to the box doing the dialing, IP masquerading will make all the packets appear to come from that one assigned IP address. And IP masquerading is very common technology: Patrick Lenzof freshmeat.net reports that over 80 percent of all connections to his site come from masqueraded machines.

The masquerading engine ensures that packets that truly originate from the Linux box never get confused with packets that have been masqueraded to look the same.

Masquerading is intrusive from an OS point of view. If you want to use masquerading, you have to build a masquerading-enabled kernel (by setting CONFIG_IP_MASQUERADE). Fortunately, it does not do much harm; most distributions ship kernels with masquerading already enabled. Defining CONFIG_IP_MASQUERADE has an effect on seven kernel source files, in 16 different places: at total of around 120 lines of extra code.

Packet filtering is similarly intrusive: Defining CONFIG_FIREWALL when you build your kernel alters four kernel source files in ten places -- about 90 extra lines of code. Packet filtering is used to control masquerading, so you need it if you want to masquerade.

The most intrusive kernel option, however, is transparent proxying. This method causes the kernel to redirect all packets to a local program, regardless of their stated destination. In effect, you pretend the packets were for you, instead of the destination stated in the packet header. All replies sent by the target program are made to look like they came from the original intended destination, so the source of the packets doesn't know any better (this is the transparent part). Transparent proxying is used to set up the Squid web server as an automatic Web proxy server. The big advantage with Squid is that you don't have to configure the Netscape clients on your network to use a designated proxy server.

Transparent proxying is a kernel-level configuration option, so like packet filtering and masquerading, you have to decide whether you want it when you build your kernel. This affects eight kernel source files in 29 places -- over 400 lines of new code!

As you might imagine, transparent proxying is fragile; it's been broken at least twice during the Linux 2.1 development series. One of my favorite code comments of all-time is this gem from Alexey, found above some transparent proxy code in tcp_ipv4.c:

Seems, I never wrote nothing more stupid.

I hope Gods will forgive me, but I cannot forgive myself 8)

­ANK (981001)

We've seen in previous articles that sometimes large IP packets are broken up along the way into "fragments." Ordinarily, these fragments aren't reassembled into a packet until they reach their final destination. This causes difficulties for masquerading and transparent proxying, which need to see the whole packet to figure out what to do with it.

Hence, the kernel option CONFIG_ IP_ALWAYS_DEFRAG which defragments all packets, even the ones just passing through. This only alters two pieces of code in a single file, by moving eight lines, and both Red Hat and Debian ship kernels with this enabled for the sake of masquerading.

But consider a network where you have two separate connections to the outside world. One is the router of your choice while the other is your Linux box, set to perform packet defragmenting for you. Now imagine a fragmented packet where half the fragments pass through the Linux box, and half come in the other way. You'll never get a complete packet, since the Linux box is holding back its half of the fragments waiting for a complete Packet to pass through. This is a fairly unusual scenario, but it can and does happen. As a workaround, kernel guru David Miller hacked a special setting into the RedHat 6.0 kernel to correct this problem for people who happen to be using transparent proxying or masquerading. David's effort is appreciated, but this hack was too ugly to make it into Linus' kernel.

Linux 2.2: A User Perspective

One of the problems with the ipchains HOWTO and the mailing list is that we get a number of questions on transparent proxying and masquerading, even though it really has nothing to do with packet filtering.

For want of a better place to put it, the ipfwadm packet filtering infrastructure for Linux 2.0 was used to specify what packets were to be masqueraded or transparently proxied. ipchains, for Linux 2.2 inherited this role, and the distinction I usually make between packet filtering (dropping unwanted packets) and packet mangling (altering packets as they pass) is blurred if people have only experienced them in ipchains or ipfwadm, where you have to use the packet filtering rules to do IP masquerading. This masquerading/packet filtering crossover leads to a significant amount of confusion for users.

In a perfect world, your packet filtering rules should be unaffected by whether or not you're masquerading. By making both functions independent of each other, we can have separate HOWTOs, separate manpages, separate mailing lists, and even separate maintainers.

The other problem that confounds users is that there are various forms of Network Address Translation, and many tie directly in with others. For example, masquerading, transparent proxying, and port forwarding belong together. Giving them separate names, and using different tools to control them only adds to the confusion.

All of these concerns made it obvious that it was time for an overhaul. I wanted to rewrite packet filtering for 2.4, to make it faster and more flexible.

Since the early days of ipchains, many people have reported problems to the mailing list, some of which don't have easy answers, and some of which are the same issues week after week.

Confusion leads to lack of security. Requiring that people master masquerading to do packet filtering increases the learning curve: it becomes more likely that people will skip an important step and make a mistake. Making things simpler for the users is a security issue. My most important goal: make packet filtering easier to configure, harder to misconfigure.