natd + ipfw question

[Leo Bicknell]

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=0" 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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20031224/b8ec6cdc/attachment.bin