Date: Mon, 26 Feb 1996 15:04:06 -0700 From: Nate Williams <nate@sri.MT.net> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <199602262204.PAA01109@rocky.sri.MT.net> In-Reply-To: <199602262153.PAA16062@brasil.moneng.mei.com> References: <199602262112.OAA00842@rocky.sri.MT.net> <199602262153.PAA16062@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > I can't do this on my box, since I don't know which interface is going > > > > to be used for my outgoing PPP connections until after the interface is > > > > completely up. That's the disadvantage of keeping the system running > > > > all the time no matter what the network affair is. The current system > > > > won't allow me to do this now. > > > > > > Why not? Stick a few rules with a variable in a script that is called when > > > the interface is started. > > > > When I start, I don't know that it will succeed? When my link goes > > down, it usually means my ISP is having problem and will continue to > > have problems for a couple hours. During that time, a home user will > > dial in to the system. This user may take the ppp0 slot since the > > outside connection isn't used. > > So.... I must be missing something. You don't (or shouldn't) CARE if > someone takes the ppp0 slot. You have the flexibility to do it by address, > and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I > recall. I admitted this below. But, it's *much* harder than it needs to be for now gain now. > And if it's not, you should still be able to write some rules that solve > your problem. I guess I'm not seeing why you think this is such a problem. It's more work. But, in retrospect I could have solved the problem with the time I spent answering email. :) > > See my comment. Since we have the ability to close the loophole, my > > concern is to minimize support headaches now. Make the default behavior > > less likely to bit the casual user, and make them shoot themselves in > > the foot by enabling it so they don't ask me questions. :) > > I think we agree, but you are "solving" the problem by breaking the tool. We aren't breaking anything. The tool simply blocks packets based on what you want it to do. If you want it to block *all* packets, then tell it to. I don't want it to do anything unless I tell it to. That's the purpose of the tool. > > It's not punching any hole in the code. *ALL* of the firewall products > > I've used (not extensive by any means) are open by default and require > > the user to explicitly close them. If a user mis-configures the > > firewall it's their problem in all of the other products, why is it now > > FreeBSD's problem to make the users 'smarter'? > > I've never seen a firewall product that is open by default. That is an > oxymoron. A firewall is *always* open by default. You determine what it is to firewall against. All of them haven't told me how to make policy, or force me to 'revert' behavior. Firewalls don't make policy, they enforce policy. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602262204.PAA01109>