From owner-freebsd-security Wed Aug 11 23:58:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from tinker.com (troll.tinker.com [204.214.7.146]) by hub.freebsd.org (Postfix) with ESMTP id 7F90314E69 for ; Wed, 11 Aug 1999 23:58:26 -0700 (PDT) (envelope-from carol@tinker.com) Received: by localhost (8.8.5/8.8.5) Received: by mail.tinker.com via smap (V2.0) id xma016165; Thu Aug 12 01:39:57 1999 Received: by localhost (8.8.8/8.8.8) id BAA20230; Thu, 12 Aug 1999 01:54:44 -0500 (CDT) Message-ID: <37B27077.C4021672@tinker.com> Date: Thu, 12 Aug 1999 01:57:59 -0500 From: Carol Deihl Organization: Shrier and Deihl X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Power Cc: freebsd-security@FreeBSD.ORG Subject: Re: question about ipfw/natd References: <71281E6E6644D311882F005004D16880395A@camel.local.mha.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Vincent, The key to making this work is thinking about when the natd happens, so that you'll know what addresses you're working with. Here's an example of a setup I did some time ago, which may or may not match your situation, but I hope it will shed some light for you. We needed to translate addresses for some public servers. We placed them behind a FreeBSD box with ipfw/natd, using redirect_address statements in a natd.conf file. We did our natd on the *external* interface. Our ipfw rules were (schematically) like this (we used a shell file): $rule 1000 pass all from 127.0.0.1 to 127.0.0.1 # Anti-spoofing, block incoming with internal sources $rule deny log all from $i_net to any in via $oif # Stop RFC1918 nets and loopback on the outside interface $rule deny log all from 192.168.0.0:255.255.0.0 to any in via $oif $rule deny log all from 172.16.0.0:255.240.0.0 to any in via $oif $rule deny log all from 10.0.0.0:255.0.0.0 to any in via $oif $rule deny log all from 127.0.0.1 to any in via $oif # process through NAT $rule divert natd all from any to any via $oif # Allow inbound to public web servers that require NAT # Rule 1 for discussion below: $rule pass tcp from any $HIGH to $t_public $HTTP in via $oif # Rule 2 $rule pass tcp from any $HIGH to $t_public $HTTP out via $iif # Rule 3 $rule pass tcp from $t_public $HTTP to any $HIGH in via $iif established # Rule 4 $rule pass tcp from $r_public $HTTP to any $HIGH out via $oif established # ditto 1-4 for other services and other blocks of addresses requiring nat The sequence of processing for a sample web connection is this: 1. first packet comes in $oif (outside interface) 2. packet examined for anti-spoofing 3. packet translated by natd 4. packet (with translated address) passed across $oif by Rule 1 above 5. packet (still with translated address) passed across $iif (inside interface) by Rule 2 6. packet received by web server, generates reply packet 7. reply packet (with translated address) comes in $iif 8. reply packet (with translated address) passed across $iif by Rule 3 9. reply packet (with translated address) hits $oif on way out 10. reply packet goes through nat, gets translated to *outside* address 11. reply packet (with *outside* address) passed to outside across $oif by Rule 4 In our topology, note that Rules 1-3 refer to the translated (inside) address, while Rule 4 refers to the *outside* address (since the nat happens before that rule gets hit). Note that even if you're using RFC1918 nets on the inside, the RFC1918 rules above won't cause a problem, since they are applied only to packets that are coming *in* from the outside interface. Another thing that took me some time to figure out originally is this: The "in" and "out" are from the point of view of the *interface* involved, *not* relative to the "inside" or "outside" network. So, for packets that are transiting the gateway box headed into the internal network, these packets will be going *out* the internal interface to the internal network. Hope I've shed light, not confusion... Carol Vincent Power wrote: > > With ipfw/natd, I am having trouble blocking access to certain ports on > the ip's I have redirected with "natd -redirect_address". Can it be > done... and is there a reference to setting up this kind of > configuration? or does someone have a sample configuration file for this > type of setup? -- Carol Deihl - principal, Shrier and Deihl - mailto:carol@tinker.com Remote Unix Network Admin, Security, Internet Software Development Tinker Internet Services - Superior FreeBSD-based Web Hosting http://www.tinker.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message