Date: Tue, 25 Sep 2001 20:56:45 +0200 (CEST) From: Flemming Jacobsen <fj@batmule.dk> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: ru@FreeBSD.ORG, 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: <200109251856.f8PIukg93964@prefect.unknown.dk> In-Reply-To: <32094.1001439610@critter> from Poul-Henning Kamp at "Sep 25, 2001 7:40:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <20010925202933.A57333@sunbay.com>, Ruslan Ermilov writes:
> >On Tue, Sep 25, 2001 at 07:14:48PM +0200, Poul-Henning Kamp wrote:
> >> >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.
See below.
> >> 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...
Right.
My position is that the "natd[pid]: failed to write packet back
(Permission denied)" message is utterly useless. Because:
+ It doesn't tell anything about what packet.
+ The FW author told ipfw to deny the packet, thus it stands
to reason that all "interesting" denys would be logged by
ipfw anyway.
+ It confuses people becauses it's not obvious why it is
generated. To the general user it could be a resource problem
or a configuration problem which caused unintended dropping
of packets. I've gotten questions about this in the Danish
BSD community a number of times, always followed by a "how do
I turn it off" when I explain the reason.
I think I've seen questions on freebsd-security as well.
As to the "misconfigured FW" argument, I can only say that I
disagree.
Writing FW rulesets is errorprone, and being able to write the
rules in a way that follows your "view" of the net makes it
easier to avoid mistakes.
The FW for my personal DSL line is an example of this.
I've got a /28 routed to the net connected to the Ethernet
interface of the DSL router. Some of these addresses belong to
jails on the FW, while others are NATed to IPs on the inside or
DMZ interface.
In order to group the rules per interface (that makes sense for
me) I divert to natd early, and then use skipto's to the
appropriate rule group. (Almost) all rules will use internal IPs
which fits my wiew of the net.
If I had to wait till after all denys before nat'ing I would
end up having to duplicate many rules as I would have one for
internal-internal traffic and one for external-internal traffic,
plus keeping track of which natd to divert to where would be a
nightmare.
Another example is a FW at work with 5 interfaces some with
RFC1918 IPs and some which use live IPs. If I didn't NAT
early (to get the IPs in the packets to match the adresses of the
boxes), I don't think I would be able to write a ruleset which
would be able to work, because none of the segments trust the
others completely.
Regards
Flemming
--
Flemming Jacobsen Email: fj@batmule.dk
---=== If speed kills, Windows users may live forever. ===---
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?200109251856.f8PIukg93964>