I just thought I would share this info on how to get iptables working under Debian.

Just for reference, the kernel I built using these procedures was with the following hardware configuration:



Step 1:

Install wget.



Step 2:

Download the latest kernel sources from kernel.org. I'm not sure if the 2.6.X kernel releases will work with this little howto, so I would grab the latest 2.4.X release to ensure the kernel actually boots and is fully functional. The 2.6 kernels should work though but you are on your own in that case. The latest version right now is 2.4.30, so we would do:



Step 3:

Install the debian kernel building utils:



Step 4:

Browse this site:

http://wiki.osuosl.org/display/LNX/Debian%...0Dell%20Servers

Notice it has a link to a kernel config with iptables enabled in the comments. Here's that link.

http://www.erikin.com/index/Docs/linux/deb.../kernel/.config

Make sure you are in the /usr/src/linux-2.4.30 directory and wget that file.



Step 5:

Run make menuconfig:



Go to Networking Options ---> IP: Netfilter Configuration --->

You should see that most of the options are set to be built as modules. Just what we need! I would suggest against changing anything in the kernel config unless you know exactly what you are doing or you'll leave yourself with a botched system.

Exit out of the kernel configuration. Save the kernel configuration when it asks.

NOTE: If you have the same system configuration you shouldn't need to change anything.

Step 6:

Run make-kpkg clean:

Lets just make sure everything is "tidy" for the kernel build:




Step 7:

Build the kernel package:



Step 8:

Install the kernel package:

Assuming the kernel built, and there is no reason it shouldn't if you are following these instructions, there should be a new .deb package placed in /usr/src. Lets go install it!



If you are using a kernel revision other than 2.4.30 than the file may be named slightly different, ie 2.4.29, etc. If you are using the 2.4.30 kernel it should have that filename for the .deb package.

When you are installing, you'll be asked a few questions. You don't want to make a boot floppy, so say no to that. Also, if it asks to install to the boot block and run lilo (sorry, forget exactly what it says) say yes.

Step 9:

Verify that the kernel is installed correctly. Do the following:



Take notice of these lines:



vmlinuz.old can be booted with the LinuxOld entry in lilo when the server gets rebooted. It will default to the "Linux" lilo option though which is our new kernel.

Step 10:

Verify that our lilo.conf file isn't botched and rerun lilo.

Lets open /etc/lilo.conf. You can use vi or nano. I usually use nano myself though, so that's what this example shows.



NOTE: If you haven't cleaned up the lilo.conf file it is going to have a ton of comments in it. So, you are likely not to see anything remotely resembling the lilo.conf I use. lol

I wouldn't get into changing too many options if it doesn't look exactly the same. Just verify that the image=/vmlinuz and image=/vmlinuz.old are there. Take note that the append = "console=ttyS0,9600n8" is for the remote console access. Check out the Debian ROD/Remote Console How To for info on enabling that. If you haven't done that yet, do so now.

That should do it. Rerun lilo and reboot to use the new kernel.



Running lilo should show you the following if successful:



Now you can reboot to use the new kernel with iptables support. Just type reboot in your console. I would definitely suggest having the rod/remote console working in case iptables ends up locking you out upon reboot

That should do it! You are on your own setting up iptables, but just make sure you allow the proper ip ranges in your firewall script so servermatrix/theplanet can monitor your server.

Thanks for this!

*post stickied*

No problem. I'll build the kernel-headers, kernel-source, and kernel-image .deb packages and link them here.

I put the deb packages at http://debian.littlelukey.com for anybody that wants them.

iptables is part of the linux kernel and is the linux routing/firewall/etc solution. Why would it not be in Debian? I don't understand. It's in kernels by default.

EDIT: 2000th post! 500 to go.

The kernel "vmlinuz-2.4.26-bf2.4" that came with the ded. box didn't have the modules built in. I'm kind of assuming the Debian install was done with a debian installer like the one here: http://wiki.osuosl.org/display/LNX/Debian%...0Dell%20Servers If so they don't include iptables as a module or compiled into the kernel for some really odd reason. It really makes you wonder what was going through their head when they decided to do that...

And what about the 2.4.* kernel images included in Debian? Can you not just do:

My deb servers all have iptables running, including the *conn_track* modules, and I normally install my kernels directly from official Debian packages.

I tried that, even tried a couple kernels from backports.org. Each time I tried I had to open a reboot ticket and have them reboot it to the old kernel. From what they said the one time it complained about some driver and it would give a kernel panic. I wish it was as easy as installing with apt-get, but building my own kernel was the only way that worked flawlessly and would actually boot the server...plus be fully functional.

My recipe for remote reboots after kernel changes:

1. Keep the old kernel as the default (i.e. vmlinuz.old).
2. Put "panic=5" in the 'append=' line of lilo.conf (when the kernel panics, it will reboot after 5 seconds).
3. Run lilo to save your configuration.
4. Run lilo again, this time with the '-R LinuxNew' (this tells lilo to boot the new kernel on the next boot only, replace 'LinuxNew' with label of your new kernel).
5. Reboot.

Here's the sequence of events:

1. Lilo loads the new kernel (because of lilo -R LinuxNew, if it boots correctly, change lilo.conf to make the new kernel the default).
2. If the new kernel panics, the panic=5 should reboot it.
3. On the reboot, it should load the default kernel as specified in lilo.conf (lilo -R no longer in effect).
4. Now you're back in the old kernel, check syslog to see why the new kernel panic'd and adjust.

I've done this to servers in 4-5 DC over the years, and the only time I've ever had to call tech support after a kernel upgrade reboot was the one time here at SM where I chose not to follow my own advice (there was also an issue with the old kernel the e1000 driver not being loaded at boot, so I would have had problems either way).