Date: Thu, 2 Nov 2000 10:03:35 +0200 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: cjclark@alum.mit.edu Cc: Kenneth Wayne Culver <culverk@wam.umd.edu>, freebsd-questions@FreeBSD.ORG Subject: Re: natd errors. Message-ID: <20001102100335.A81318@sunbay.com> In-Reply-To: <20001101134207.A19904@149.211.6.64.reflexcom.com>; from cjclark@reflexnet.net on Wed, Nov 01, 2000 at 01:42:07PM -0800 References: <20001101104131.A41690@sunbay.com> <Pine.GSO.4.21.0011011203390.27725-100000@rac5.wam.umd.edu> <20001101134207.A19904@149.211.6.64.reflexcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 01, 2000 at 01:42:07PM -0800, 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.
>
It WILL work in this case, it WILL NOT work if ${onet} is set to
not-routable addresses.
> 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
> + #
>
Wrong, the rules before and after are not the same, take a closure look.
Let's say you have:
iip=192.168.1.1 inet=192.168.1.0 imask=255.255.255.0 iif=int0
oip=1.2.3.4 onet=1.2.3.0 omask=255.255.255.0 oif=ext0
Then we will have:
deny all from any to 192.168.0.0/16 via ext0
...
divert natd all from any to any via ext0
...
deny all from 192.168.0.0/16 to any via ext0
1. Internal host sends a packet outside:
packet first enters a firewall as incoming through int0:
192.168.1.100 -> 2.2.2.2 in via int0 (will be passed)
packet then enters a firewall as outgoing through ext0:
192.168.1.100 -> 2.2.2.2 out via ext0 (will hit the `divert' rule)
packet is aliased by natd and passed to firewall again STARTING
FROM THE RULE WITH NEXT NUMBER:
1.2.3.4 -> 2.2.2.2 out via ext0 (will be passed)
2. External hosts replies to a packet:
packet first enters a firewall as incoming through ext0:
2.2.2.2 -> 1.2.3.4 in via ext0 (will hit the `divert' rule)
packet is de-aliased by natd and passed to firewall again STARTING
FROM THE RULE WITH NEXT NUMBER:
2.2.2.2 -> 192.168.1.100 in via ext0 (will be passed)
packet then enters a firewall as outgoing through int0:
2.2.2.2 -> 192.168.1.100 out via int0 (will be passed)
What am I missing here?
--
Ruslan Ermilov Oracle Developer/DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001102100335.A81318>