Date: Tue, 25 Jul 2000 23:55:08 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: Mike Hoskins <mike@adept.org> Cc: Stephen Montgomery-Smith <stephen@math.missouri.edu>, freebsd-security@FreeBSD.ORG Subject: Re: Problems with natd and simple firewall Message-ID: <20000725235508.D307@pool0460.cvx20-bradley.dialup.e> In-Reply-To: <Pine.BSF.4.21.0007251214390.27676-100000@snafu.adept.org>; from mike@adept.org on Tue, Jul 25, 2000 at 12:23:15PM -0700 References: <397D4062.4A1FFFE2@math.missouri.edu> <Pine.BSF.4.21.0007251214390.27676-100000@snafu.adept.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 25, 2000 at 12:23:15PM -0700, Mike Hoskins wrote:
> On Tue, 25 Jul 2000, Stephen Montgomery-Smith wrote:
>
> > > ${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}
> > Yes, I had the same idea over dinner. Trouble is, it doesn't work.
> > I tried it.
>
> Note that I'm not arguing this couldn't be clearer or that, possibly, the
> code needs cleaned up in some way. I'm not arguing for or against such
> statements - I haven't looked at the code, so I'm trying to offer advice
> based only upon ipfw(8) and my lowly interpretation thereof...
>
> With that in mind, consider the above rules...
>
> A packet from an external host attempting to communicate with an inside,
> privately addressed host will undergo the following:
>
> * from outside machine to outside IP (in oif)
> * from outside IP to inside IP (divert)
> * delever to inside IP (out iif)
>
> Given this behavior, the above rules will obviouslly not work, because the
> 'deny all from ANY' rule will deny packets from 'outside IP to inside IP'
> which must take place according to the behavior described above.
Not following you. And I am not sure why that does not work (coulda
sworn I've done it like that in the past and don't presently have a
setup to test it easily).
Here's how I see packets that are supposed to pass go,
1) From an outside machine they come in oif.
2) Skip the first rule since 192.168.0.0/16 does not match.
3) Match divert rule and passed to NAT.
4) Enter rule list again after NAT rule and match a pass rule
somewhere below the two shown.
5) Now, enter the list again to leave after being sent through
routing, they are associated with the internal interface, iif.
6) Since we are associated with iif, they don't match the first rule
even though addresses match.
6) They also don't match the divert rule for the same reason.
7) They match some rule below and fly on out the interface.
Where is my logic/understanding wrong?
--
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?20000725235508.D307>