Because debian's default setup for ipmasq+iptables does exactly what I need w/o me having to do more than run apt-get install ipmasq iptables I've been using it for awhile. Lately though I've started to run into annoying quirks and would just like suggestions for something else to use.

What it will be installed on: debian etch based k6 133MHz 64MB RAM server that is an internet gateway machine and file server. Internally it serves SMB and NFS. To both the LAN and Internet it servers SSH, HTTP & FTP

What I'm shopping for:
1) Default config that is on par with ipmasq+iptables or to be plain english Joe Stupid configurable.
2) Readily gets along with self compiled kernels. This is the biggest problem I have. For some reason, the iptables with debian sid or etch hate when I compile my own kernel using the standard debian kernel config as a base (I optimise for my processor is really the biggest change I make besides using the newest version from It starts telling me that there are missing modules and options in the kernel for iptables and therefore ceases to share the external connect, and in some cases refuses to talk to the internal connect either.
3) consistent. On the odd occasion that I have to reboot the machine, it has a habit of setting things up in an odd order so that it's ignoring some or all of the internal IPs.
4) no bandwidth throttling. It will also, sometimes, spontaneously cut off one of the IPs. Seriously, this happens most when I'm dowloading a lot of data at a time, like a set of Debian DVD install discs or something like that. It almost never happens to one of the other comps which never has a lot of data to grab at once. It also seems related only to the Internal to external gateway. Purely internal connections never trigger it, though once it does all connections from that IP to the gateway machine, be they directly to it, or passing through to the internet .... refused.

Anyway, just looking for suggestions of alternatives to my current config. There's a thread about that here if you know what would cause a k6 I/II/III optimised 2.6.20 copy of the kernel to have the problems mentioned in that thread.