Date: Wed, 24 Dec 2003 08:39:45 -0500 From: Leo Bicknell <bicknell@ufp.org> To: freebsd-hackers@freebsd.org Subject: Re: natd + ipfw question Message-ID: <20031224133945.GA74426@ussenterprise.ufp.org> In-Reply-To: <20031223122808.A7604@xorpc.icir.org> <20031223201712.GA33497@ussenterprise.ufp.org> References: <20031223165439.GA23721@ussenterprise.ufp.org> <20031223201712.GA33497@ussenterprise.ufp.org> <20031223122808.A7604@xorpc.icir.org> <20031223165439.GA23721@ussenterprise.ufp.org> <20031223201712.GA33497@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Original broken case:
In a message written on Tue, Dec 23, 2003 at 03:17:12PM -0500, Leo Bicknell=
wrote:
> > ipfw add 1000 divert natd ip from any to any recv fxp0
> > ipfw add 1001 divert natd ip from any to any xmit fxp0
In a message written on Tue, Dec 23, 2003 at 12:28:09PM -0800, Luigi Rizzo =
wrote:
> The names are reasonably intuitive...
[snip]
> the flow diagram near the beginning of the ipfw manpage should
> clarify things a bit (i agree that the wording of 'recv/xmit/via'
> section is a bit confusing, so if you have better suggestions they
> are welcome)
I did some more poking with my broken rules above. With them natd
appears to get the packet each way once (based on nat debugging
turned on), so it's not my first fear that the packets would go
through twice without in and out with these rules. Natd simply
(per it's debugging) doesn't change anything. 1918 space in, 1918
space out. If I add the "in" and "out" keywords it magically starts
working.
Now, if I understand the diagram right a packet might be processed
by rule 1000 twice, since recv matches on input or output, but I
don't actually ever see received packets (I think) since the xmit
side isn't doing the outbound part of the nat (if the packet leaves
with 1918 space source, insted of my outside source, I'll never get
it back).
Now that I've used IPFW2 for something more complicated than simple
host filtering I see that the syntax and structure makes something
like a firewall/nat box for any moderately interesting config way
too complicated with way too many pitfalls. This whole "the packet
may hit your rule between 0 and 4 times, depending on a pile of
stuff" just doesn't fly, and add in the need for "one_pass=3D0" to
make dummynet traffic shaping work right, which adds some complication
to the firewall rules and things are just all kinds of strange.
That's no knock on the authors, backwards compatability is important,
and a lot has been grafted onto IPFW since it started (like divert/nat
and the dummynet stuff). I'll strongly recomend though that IPFW3
have a whole new, from the ground up, redesigned config language.
:) And yes, I'm willing to help.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/6ZcgNh6mMG5yMTYRAhcdAJ0QYYB+XmmE2F4xMkhAXx0XZ6MgzwCdG96Z
5sXZP1l/jIY5FReA/p6K4t8=
=qHsl
-----END PGP SIGNATURE-----
--BOKacYhQ+x31HxR3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031224133945.GA74426>