Date: Tue, 25 Sep 2001 19:40:10 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: fj@batmule.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: misc/30255: [PATCH] Packets reinjected by natd but denied by ipfw generates annoying errors Message-ID: <32094.1001439610@critter> In-Reply-To: Your message of "Tue, 25 Sep 2001 20:29:33 %2B0300." <20010925202933.A57333@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010925202933.A57333@sunbay.com>, Ruslan Ermilov writes: >On Tue, Sep 25, 2001 at 07:14:48PM +0200, Poul-Henning Kamp wrote: >> >> >State-Changed-From-To: open->closed >> >State-Changed-By: ru >> >State-Changed-When: Tue Sep 25 07:24:17 PDT 2001 >> >State-Changed-Why: >> >> >With my MAINTAINER hat on, I don't like this option. >> > >> >This error usually indicates a misconfigured firewall. >> >It is almost always possible to write firewall rules >> >that do not result in EACCES from firewall. >> >> I think you're being too harsh here Ruslan. While it may theoretically >> be possible to write such rules, I have myself often found it simpler >> and faster to reject on the "backside" of natd. >> >Just give me one real example where it's really useful, and I'll probably >agree. > >> Considering what is proposed is an option I think it should be committed. >> >OK, how about this instead? > >I can change the code so that it logs various warnings at >different syslog(3) levels. Then what gets logged may be >controlled via syslog.conf(5). I think that is always a good idea, but this particular switch makes more sense as a direct option I think... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32094.1001439610>