Harry,

> Just played around with upgrading one of my systems to 2.2.1 (up from
> RedHat 5.2/2.0.36), and one of the notable error messages Linuxconf
> provided me with was a notice that IP Forwarding was not part of my
> kernel.

In short, the firewalling mechanism has changed with the new Linux kernels.
The old kernel used ipforwarding and the new kernel uses ipchains. Linuxconf
supports only administration of ipforwarding (a front-end for ipfwadm);
support for ipchains administration is on the wish-list.

Below are some relevant messages about this topic from the list.

> Do I understand it correctly that unless this issue is addressed,
> switching a firewall/linuxconf config to 2.2.1 is not a wise move?

That is wise, unless you want to do the ipchains administration by hand and
wait for the linuxconf version that supports ipchains.

Jeroen Pluimers
http://www.pluimers.com

Linux is just like a wigwam:
no Windows, no Gates and an Apache inside.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Jacques Gelinas
Sent: Tuesday, January 12, 1999 5:40 PM
Subject: [linuxconf] Re: STATUS REQUEST

...

> Sendmail-8.9
> Kernel 2.2 (pre) IP aliasing/IPchains

Both are still on the todo list

...

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Allen Bolderoff
Sent: Thursday, December 03, 1998 10:00 AM
Subject: [linuxconf] Re: ipchains support?



Cool, one thing about ipchains, is a couple of scripts called:

ipchains-save and
ipchains-restore

ipchains-save > filename        # will save your current ipchains
                                # config to filename and
ipchains-restore < filename     # restores it for you.

file format is *very* simple compared to ipfwadm IMHO & should be easier to
emulate than playing around with ipfwadm.

Just my 2c

Allen

> is there any work/plans on including ipchains support in the near future?

> when 2.2 comes out, we know that ipfwadm will be obsolete, however with
> ipchains comes an ipfwadm emulation or wrapper which allows us to (IMHO)
run
> ipfwadm commands without all the functionality of ipchains, however the
/proc
> schema will be different. (/proc/net/ip_* is replaced with
> /proc/net/ip_fwnames and /proc/net/ipfwchains.

...


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Allen Bolderoff
Sent: Friday, December 04, 1998 3:15 AM
Subject: [linuxconf] Re: 2.1.13x and IP masq'ing


Actually, come to think of it, upon going meticulously through the
Documentation for ipchains, we would need, (if we wanted to have linuxconf
manage it) some sort of database of the chains, similar to the user
management consol for linuxconf.

The way ipchains works, is that you name a specific chain, which may
filter/reject/deny/accept based on any number of rules, and each rule in
each chain can fork off to another chain based on whether the packets match.
See
http://www.rustcorp.com/linux/ipchains/HOWTO.html
and more specifically http://www.rustcorp.com/linux/ipchains/HOWTO-4.html.

What I suggest, along with the following suggestion by James, is to have a
directory, /etc/ipchains.d/ containing all Chains in files named the same
name as the chain.
This allows anyone to do an /etc/rc.d/init.d/ipchains start command, and
providing the rc script knows about the /etc/ipchains.d directory, it will
read & install those chains, in fact, the chains would need to have a
numbering system similar to the /etc/rc.d/rc#.d/S##* system, in order to
effect the implementation of rules in the right order (preventing race
conditions in expecting all rules to implement Immediately)

We then need to have Linuxconf keep a list file, (similar to the way that
linuxconf handles the /etc/passwd file for users), of chains, so that it can
edit/add/updates a new/existing chain as necessary.

IMHO the ipchains stuff is 1000% better documented than ipfwadm ever will
be, and may not even need the expense of building the management if same
into linuxconf.

...


---
You are currently subscribed to linuxconf as: [[email protected]]
To unsubscribe, forward this message to [EMAIL PROTECTED]

Reply via email to