From owner-freebsd-questions Wed Nov 1 14:16: 2 2000 Delivered-To: freebsd-questions@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 0991437B4C5 for ; Wed, 1 Nov 2000 14:15:49 -0800 (PST) Received: from rac4.wam.umd.edu (IDENT:root@rac4.wam.umd.edu [128.8.10.144]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id RAA06325; Wed, 1 Nov 2000 17:15:43 -0500 (EST) Received: from rac4.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac4.wam.umd.edu (8.9.3/8.9.3) with SMTP id RAA03405; Wed, 1 Nov 2000 17:15:43 -0500 (EST) Received: from localhost (culverk@localhost) by rac4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id RAA03401; Wed, 1 Nov 2000 17:15:43 -0500 (EST) X-Authentication-Warning: rac4.wam.umd.edu: culverk owned process doing -bs Date: Wed, 1 Nov 2000 17:15:43 -0500 (EST) From: Kenneth Wayne Culver To: cjclark@alum.mit.edu Cc: Ruslan Ermilov , freebsd-questions@FreeBSD.ORG Subject: Re: natd errors. In-Reply-To: <20001101134207.A19904@149.211.6.64.reflexcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I figured out a different way of doing that, but it doesn't matter, I'm just wondering if your changes fix the natd error I was getting. ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Wed, 1 Nov 2000, Crist J . Clark wrote: > On Wed, Nov 01, 2000 at 12:04:21PM -0500, Kenneth Wayne Culver wrote: > > On Wed, 1 Nov 2000, Ruslan Ermilov wrote: > > > > > On Wed, Nov 01, 2000 at 12:27:36AM -0800, Crist J . Clark wrote: > > > > On Wed, Nov 01, 2000 at 09:34:21AM +0200, Ruslan Ermilov wrote: > > > > > On Tue, Oct 31, 2000 at 04:24:12PM -0500, Kenneth Wayne Culver wrote: > > > > > > I just decided to make my firewall rules more strict, so I set my type to > > > > > > "simple" in rc.conf... and now I get this error > > > > > > Oct 31 16:16:07 culverk natd[139]: failed to write packet back (Permission > > > > > > denied) > > > > > > > > > > > This happens when ipfw blocks packets written back by natd(8). > > > > > > > > > > > my rules are the same rules as the "simple" specification in rc.firewall. > > > > > > > > > > > There was a problem with the stock "simple" firewall, which has now been > > > > > fixed in 4.1-STABLE (/etc/rc.firewall, rev 1.30.2.5). > > > > > > > > > > > Could someone tell me how to get rid of this error? > > > > > > > > > > > Make sure your rc.firewall is rev 1.30.2.5 or higher. > > > > > > > > Hmmm, I have a 1.30.2.6 file right here and it still looks to me like > > > > it does not have a chance of working for your average natd(8) setup. > > > > > > > If ${oip} and ${onet} are set to some real values, the "simple" firewall > > > should work. If they are set to some RFC1918 or draft-manning-dsua ones, > > > this (of course) will not work, and you will have to either delete two > > > "deny" rules (one before and one after the divert rule) that include your > > > ${onet}:${omask} network. Anything else? > > > > my oip and onet are real, and I still have the same problem... my iip and > > inet are not real however.. > > Not real? Are we using complex numbers in our addresses again? I guess > you mean they are not registered, globally-routable addresses, RFC1918 > addresses most likely. But yes, the default rc.firewall will not work > if this is the case. All the packets from your internal network will > get dropped by the RFC1918-blocking rules. That's why it will not work > for about 90% of the people doing NAT. > > My personal fix is to forget those rules since the way I write my > firewall rules, those packets fall on the floor anyways (I only pass > what I am expecting to get, rather than block what I do not > want). However, if you want to just make some minor adjustments to > rc.firewall, the patch below should help. Note that this adjustment > loses any egress filtering (since it does not make sense to bother > with when doing NAT), so it may not be suitable for non-NAT gateways. > > --- /usr/src/etc/rc.firewall Sat Sep 23 04:30:52 2000 > +++ rc.firewall Wed Nov 1 13:36:41 2000 > @@ -177,18 +177,18 @@ > ${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif} > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > + ${fwcmd} add deny all from any to 10.0.0.0/8 in via ${oif} > + ${fwcmd} add deny all from any to 172.16.0.0/12 in via ${oif} > + ${fwcmd} add deny all from any to 192.168.0.0/16 in via ${oif} > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) > # on the outside interface > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > + ${fwcmd} add deny all from any to 0.0.0.0/8 in via ${oif} > + ${fwcmd} add deny all from any to 169.254.0.0/16 in via ${oif} > + ${fwcmd} add deny all from any to 192.0.2.0/24 in via ${oif} > + ${fwcmd} add deny all from any to 224.0.0.0/4 in via ${oif} > + ${fwcmd} add deny all from any to 240.0.0.0/4 in via ${oif} > > # Network Address Translation. This rule is placed here deliberately > # so that it does not interfere with the surrounding address-checking > @@ -197,6 +197,11 @@ > # translated by natd(8) would match the `deny' rule above. Similarly > # an outgoing packet originated from it before being translated would > # match the `deny' rule below. > + # > + # That comment makes no sense. The rules above and below were > + # identical. Rules modified so this actually works for RFC1918 > + # addresses on the internal interface. - 2000/11/1, cjc > + # > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > @@ -204,20 +209,6 @@ > fi > ;; > esac > - > - # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > - > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) > - # on the outside interface > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > > # Allow TCP through if setup succeeded > ${fwcmd} add pass tcp from any to any established > > > -- > Crist J. Clark cjclark@alum.mit.edu > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message