Date: Thu, 12 Aug 1999 01:57:59 -0500 From: Carol Deihl <carol@tinker.com> To: Vincent Power <vince@MHA.ca> Cc: freebsd-security@FreeBSD.ORG Subject: Re: question about ipfw/natd Message-ID: <37B27077.C4021672@tinker.com> References: <71281E6E6644D311882F005004D16880395A@camel.local.mha.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37B27077.C4021672>