Date: Mon, 20 Dec 1999 00:41:41 +0300 From: Dmitriy Bokiy <ratebor@pro.icp.ac.ru> To: Sanford Owings <sowings@pasteur.EECS.Berkeley.EDU>, freebsd-security@FreeBSD.ORG Subject: Re: Firewall and NAT, step-by-step? Message-ID: <428.991220@pro.icp.ac.ru> In-Reply-To: <199912150008.QAA10142@mamba.CS.Berkeley.EDU> References: <199912150008.QAA10142@mamba.CS.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
As (strangely) I couldn`t find the apropriate link in the archive here`s the answer from Carol Deihl: > 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 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/ I add only that you can happily do without recv and xmit in favour of "via in"/"via out" which are clearly more intuitive. -Dmitriy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?428.991220>