Date: Sun, 18 Mar 2007 21:39:01 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Kian Mohageri <kian.mohageri@gmail.com> Cc: freebsd-net@freebsd.org, Mark Andrews <Mark_Andrews@isc.org>, freebsd-rc@freebsd.org Subject: Re: rc.order wrong (ipfw) Message-ID: <45FE13E5.9060902@FreeBSD.org> In-Reply-To: <45FDF284.3040008@gmail.com> References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kian Mohageri wrote:
> I agree VERY MUCH with this sort of approach. It would be a much
> cleaner solution than completely separate handling of all of these
> different problems. I'm trying to get an idea of what all of the major
> problems with the current order are, and these are the ones I'm aware of:
>
> - ipfw blocks by default (names unresolvable, rtsol breaks)
> - ipf/pf pass by default (services are unprotected)
>
> I think a firewall_boot script (similar to what you've proposed) could
> potentially solve all of these problems.
I'm glad that you like the idea in principal, however I'm sorry to say
that I don't see eye to eye with your suggestion of modifying the
early behavior instead of the late behavior.
I believe (for whatever that's worth) that firewalls (and firewall
rules) _should_ be loaded prior to the interfaces coming up. If
someone wants to have dynamic rules, rules that rely on name
resolution, or rules for non-physical (e.g., cloned) interfaces,
that's fine, but IMO those are the exception, not the rule.
Furthermore (and I'm betraying a prejudice here) I think that firewall
rules that rely on name resolution are absolutely nuts, and I say that
with many years of experience as a professional DNS and system
administrator.
Therefore I believe strongly that the default behavior should be
changed to load all firewalls (and rules) before netif, and that those
who want to do firewall-related things that require netif or routing
to be up should be the ones who have to opt in to the new script. That
said, I think you and I have expressed our opinions pretty clearly on
these points, so I'd suggest that we let someone else have a turn.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45FE13E5.9060902>