Date: Sun, 30 Sep 2001 09:34:05 +0200 (CEST) From: Flemming Jacobsen <fj@batmule.dk> To: ru@FreeBSD.ORG (Ruslan Ermilov) Cc: fj@batmule.dk, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: misc/30255: [PATCH] Packets reinjected by natd but denied by ipfw generates annoying errors Message-ID: <200109300734.f8U7Y5D98054@prefect.unknown.dk> In-Reply-To: <20010926092210.A20611@sunbay.com> from Ruslan Ermilov at "Sep 26, 2001 9:22:10 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote: > On Tue, Sep 25, 2001 at 08:56:45PM +0200, Flemming Jacobsen wrote: > [...] > > 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. > > > Unless you run natd(8) in verbose mode. Running natd in verbose mode is not compatible with production. I still think that if a denied packet is worth logging ipfw should do it. Natd has no way of knowing (or being told) if a deny is significant or trivial. > > + 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 is usually caused by a default rule 65535 which is "deny ip > from any to any", and missing rules to allow for inbound traffic, > resulting in many questions on -questions asking why natd(8) is > not working. A good example is PR kern/30775. In my case it's usually "no this server only serves port xxx traffic to that net". > > + 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. > > > : -verbose | -v > : Do not call daemon(3) on startup. Instead, stay attached to > : the controlling terminal and display all packet alterations > : to the standard output. This option should only be used for > : debugging purposes. People still want to turn it off when they realize that the message is useless. > > 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. > > > May I have a look at your rules with comments? Perhaps in private. No. That's a matter of principle. > > 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. > > > And you use a single natd(8) process to service all 5 interfaces? > Again, I would like to see an example with comments, and an > example when this causes a EACCES from firewall which is > unavoidable. It probably is theoretically avoidable. That's not the point. The point is being able to write the rules with a mindset which maximises the chance of getting it right. Having to jump through hoops just to keep useless messages away is plain stupid. Both in terms of implementation time/effort and getting-it-right probability. > I do have an example of a real firewall setup which I developed > a year ago, which I can post for demonstration purposes. This > firewall provides both "external" and "internal" policies. > > Meanwhile, I'm going to commit the following patch. With it, > you can program your syslog.conf(5) to not log warning from > natd(8). Hmmm, would it not drop the following very usefull line: Sep 30 05:15:12 <daemon.warn> benji natd[531]: denied [TCP] xxx.127.45.35:2613 -> yyy.242.86.227:515 If yes, then I don't think your patch solves the problem. 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?200109300734.f8U7Y5D98054>