Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jul 2000 22:50:53 -0700
From:      "Crist J. Clark" <cristjc@earthlink.net>
To:        Stephen Montgomery-Smith <stephen@math.missouri.edu>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Problems with natd and simple firewall
Message-ID:  <20000724225053.B258@pool0653.cvx20-bradley.dialup.e>
In-Reply-To: <397C8F30.8DFCE0E9@math.missouri.edu>; from stephen@math.missouri.edu on Mon, Jul 24, 2000 at 01:47:12PM -0500
References:  <397C8F30.8DFCE0E9@math.missouri.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 24, 2000 at 01:47:12PM -0500, Stephen Montgomery-Smith wrote:
> I recently tried to get natd to work with the default
> rc.firewall that comes with FreeBSD 4.1RC, and it didn't
> work.  I found the problem, from looking at the web site
> http://www.mostgraveconcern.com/freebsd/sheet.cgi?ipfw
> which has a cure, but I wonder if there are other ways
> to fix it.
> 
> In any case, the rc.firewall is currently seriously
> deficient.

The rules in rc.firewall are not meant to be used as is or with simply
plugging in your IP addresses and interface names. If you do this, as
you found out, things may not work.

> Here is the setup: my external network has
> net:mask = 12.34.56.0/24
> and my internal network has 
> net:mask = 192.168.1/24
> 
> Now, suppose I have established a connection:
> 192.168.1.2:4444 to 34.56.78.90:22
> natd changes this to
> 12.34.56.78:4444 to 34.56.78.90:22
> 
> Now a piece of tcp comes in:
> 34.56.78.90:22 to 12.34.56.78:4444 via outside-interface
> natd converts this to
> 34.56.78.90:22 to 192.168.1.2:4444 via outside-interface
> 
> which immediately gets killed by the rule in rc.firewall:
> 
> 	# Stop RFC1918 nets on the outside interface
> 	...........
> 	${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
> 
> The web site fixes this by changing the line to:
> 
> 	${fwcmd} add deny all from any to 192.168.0.0/16 out via ${oif}
> 
> Is this the corect way to deal with this?  Does this leave the computer
> open to spoofing?  Is there some clever dynamic rule that could fix
> this?  

Why not just block the RFC1918 addresses on the outer interface
_before_ the divert rule?


	# Stop RFC1918 nets on the outside interface
	...........
 	${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}

	$fwcmd add divert natd all from any to any via ${natd_interface}

Seems simple enough? No downside I can see.
-- 
Crist J. Clark                           cjclark@alum.mit.edu


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?20000724225053.B258>