Dynamic rules not being matched after divert...

[Sean Chittenden]

> >I'm setting up an ipfw2+natd gateway and am pretty convinced there's a
> >bug in the way that ipfw2 promotes dynamic rules to being fully
> >established.
> 
> I and others have said similar things, but we were simply wrong.
> The problem is that natd is already a stateful bugger,

Very aware that natd is stateful, that's how it does its translation
mappings.  This would be fine with me if divert actually aborted
processing of instructions after the divert rule and natd had some way
for me to see its state table.  Since it doesn't, however, and since
the packet would match a state entry in ipfw2 if it were given the
chance to, I consider this a bug (and not a feature as I read in the
archives).

> and when packets match a stateful rule in one direction (after
> natting, say) they cannot match the rule in the other direction --
> addresses won't match.  In one case you have the private address, in
> the other, the public address.

That's irrelevant: the packet has been translated when traversing the
firewall in either direction.  Packets even go so far as to update the
TTL count down timer on the existing dynamic rule for the connection.

> This has been discussed before.  I'm working on new examples for
> rc.firewall....

I read 'em: the discussions was half baked, at best and were far from
conclusive in terms of a secure rule set using ipfw2+natd.  Allowing
established connections is not secure.  I like that ipfw2 sends tcp
keep alives, something I'm almost certain that natd(8) doesn't do.


Luigi, ipfw(8) is incorrect, btw:

     divert port
             Divert packets that match this rule to the divert(4) socket bound
             to port port.  The search terminates.

Packets that have gone through natd(8) are being re-injected into the
rule set.  From ip_fw2.c ~line 1256:

 *      args->divert_rule (in/out)
 *              Skip up to the first rule past this rule number;
 *              upon return, non-zero port number for divert or tee.

This is consistent with what is found in natd(8):

          After translation by natd, packets re-enter the firewall at the rule
          number following the rule number that caused the diversion (not the
          next rule if there are several at the same number).


Let me know if it's okay if I commit a doc correction for the above. -sc

-- 
Sean Chittenden