From owner-freebsd-bugs Sun Sep 30 0:34:38 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from cicero1.cybercity.dk (cicero1.cybercity.dk [212.242.40.4]) by hub.freebsd.org (Postfix) with ESMTP id 707F337B403; Sun, 30 Sep 2001 00:34:29 -0700 (PDT) Received: from prefect.unknown.dk (dag.batmule.dk [212.242.86.227]) by cicero1.cybercity.dk (Postfix) with ESMTP id 5838B15FD0C; Sun, 30 Sep 2001 09:34:06 +0200 (CEST) Received: (from fj@localhost) by prefect.unknown.dk (8.11.3/8.11.1) id f8U7Y5D98054; Sun, 30 Sep 2001 09:34:05 +0200 (CEST) (envelope-from fj) From: Flemming Jacobsen Message-Id: <200109300734.f8U7Y5D98054@prefect.unknown.dk> Subject: Re: misc/30255: [PATCH] Packets reinjected by natd but denied by ipfw generates annoying errors In-Reply-To: <20010926092210.A20611@sunbay.com> from Ruslan Ermilov at "Sep 26, 2001 9:22:10 am" To: ru@FreeBSD.ORG (Ruslan Ermilov) Date: Sun, 30 Sep 2001 09:34:05 +0200 (CEST) Cc: fj@batmule.dk, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 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