Re: Firewall tools don't play nice with each other
On Wed, 24 Apr 2002, Russell Hires wrote:
>> > I also meant the packaging of the tools. Part of Debian Policy
>> > states that some packages should conflict with other packages.
>>
>> Yes, where the packages cannot coexist correctly.
>>
>> > I think that, for example, guarddog should conflict with shorewall
>> > firewall. I think that only one should be in place at a time.
>>
>> Well, that's nice, but /why/ should there only be one in place?
>
> If each package modifies rc.firewall, then I guess it doesn't matter.
As far as I can see, one of the few times that you might actually have
two firewalling packages conflict was if they both modified the same
file.
OTOH, there isn't an 'rc.firewall' shipped as part of any Debian package
on x86 as of today. Which packages were you thinking of?
> But I don't think they do. I also don't know where they insert
> themselves in the startup sequence.
For every package that I have installed so far, they have correctly
inserted themselves /nowhere/ in the startup sequence.
> This is the problem that I've had in particular:
>
> I've got two different firewalls in place, at two different points in
> my start up, so I think that one works, but then another is actually
> doing the firewalling.
If you start two firewalling packages then, yes, there is a potential
for some conflict between them.
> Then, on top of that, I've got PPPoE (which is also a debian package),
> which does its own thing to the firewall/ipchains to enable forwarding
> to the other (private) hosts on my network.
It does this by default? How odd. It didn't last time I used it, but
then I got a sane connection. :)
If you asked it to, of course, it's your lookout to make sure that it
works correctly with any existing iptables setup...
> I had to go and hunt down why the firewalling wasn't working the way
> that I thought it was because of this. This is ultimately what I'm
> looking at as a problem. It's the last firewall script that is run
> that determines what the rules are.
That shouldn't be the case and, if it is, it's a bug in the package --
it shouldn't assume that it can just junk any existing rules. That would
break several other packages such as the `ipac-ng' accounting system...
> There should be some debian policy about that.
If the firewall really can't operate without junking existing
configuration at all, even with user configuration, then it should
conflict with things it can't work with.
If it can be user configured to work with them, isn't by default, and is
started automatically, it should have a serious bug filed against it so
that it stops starting automatically or works in a compatible mode by
default.
If, like every package I have looked at, it does nothing at all until
it's configured by the user then there is /no/ conflict of any sort with
other packages.
For the last case, though, many maintainers will accept a contributed
README.<package> file that discusses the conflicts you found and your
solution to the problem. That way others can benefit from your efforts.
There still isn't any reason *in the general case* for the conflict you
are talking about. OTOH, for two or three specific packages there may be
conflicts.
You were not clear about the targeted scope of your objection, given the
'etc' appended after any specific set of package names.
Daniel
--
The best lack all conviction, while the worst
Are full of passionate intensity.
-- W.B. Yeats, _The Second Coming_
--
To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: