From owner-freebsd-questions Fri Jun 12 00:42:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA26855 for freebsd-questions-outgoing; Fri, 12 Jun 1998 00:42:27 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA26845 for ; Fri, 12 Jun 1998 00:42:21 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.5/8.8.8) with SMTP id AAA29255; Fri, 12 Jun 1998 00:42:20 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Fri, 12 Jun 1998 00:42:19 -0700 (PDT) From: Doug White To: carl.p.edwards@usa.net cc: freebsd-questions@FreeBSD.ORG Subject: Re: NAT and IPFW security In-Reply-To: <19980607145830.13113.qmail@www02.netaddress.usa.net> 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 On Sun, 7 Jun 1998 carl.p.edwards@usa.net wrote: > Hi, > > Consider this network: > > --------------- > | I-net router | > | 123.123.123.1 | > --------------- > | > | > | --------------------------- ----------- > | | "eagle" | | "sparrow" | > >----| 123.123.123.2 10.1.1.1 |------| 10.1.1.2 | > | | [ed0] [ed1] | | | > | --------------------------- ----------- > | > | > | --------------- > | | "falcon" | > >----| 123.123.123.3 | > * --------------- Excellent ASCII-gram, thanks! > All computers are running FreeBSD 2.2.6. The server "eagle" is running > NAT. The way I figured is that if "falcon" was set to have 123.123.123.2 > as its default gateway rather than 123.123.123.1 a user on falcon would > be able to access "sparrow" simply by telnetting or whatever to > 10.1.1.2. Now if this rule was applied on "eagle": Not true. Net10 is hidden behind eagle; falcon would have to know to route 10.x through eagle, which invokes the natd translation. > 1000 deny all from 123.123.123.1/24 to 10.1.1.1/24 via ed0 The problem with this rule is that it will defeat the natd trnaslation by blocking the generated packets. I think. I don't know if the `via' info is kept after the reinjection of the natd-translated packets. > I'm not 100% clear on how IPFW and NAT works together so any help would > be appreciated. ipfw simply provides the conduit to natd. The `divert' rule is the key to gluing the two together. Packets that match the divert rule get natd-translated, then reinjected into the packet stream at the top, but ignore divert rules on their second pass through. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message