kern/157796: [ipfw] IPFW in-kernel NAT nat loopback / Default Router Changes Unexpectedly

[Ian Smith]

On Mon, 13 Jun 2011, linimon at freebsd.org wrote:

 > http://www.freebsd.org/cgi/query-pr.cgi?pr=157796

Ozkan,

I'm not replying to your PR directly as this is purely speculative; I 
have no idea about your default route changing.  However your ruleset 
raises a couple of possible issues:

 > When a packet injects into ipfw in-kernel nat more then once,
 > operating systems behave abnormally.
 >
 > Let's inspect the ruleset below:
 >
 > ipfw table 12 add 10.0.14.1/32 33
 > ipfw table 13 add 193.X.128.30/32 33
 >
 > ipfw nat 33 config redirect_addr 10.0.14.1 193.X.128.30
 > ipfw nat 799 config ip 3.3.3.3 reverse
 >
 > 55000 nat tablearg ip from table(12) to not 3.3.3.3 via em3
 > 55000 nat tablearg ip from any to table(13) via em3
 > 55000 nat 799 ip from any to table(13) not via em3
 > 55000 nat tablearg ip from 3.3.3.3 to table(13)
 > 55000 nat tablearg ip from table(12) to 3.3.3.3
 > 55000 nat 799 ip from table(13) to 3.3.3.3

Firstly, if ipfw nat behaves the same as divert+natd in this respect, 
and assuming net.inet.ip.fw.one_pass=0 from your description, then any 
nat diversion would result in reentry of the ruleset at the next rule 
with a higher rule number, not at the next sequential rule with the same 
number.  I've never been certain whether that's also true with ipfw nat, 
but renumbering subsequent rules as 55001 etc would soon rule that out.

Secondly, I assume you're aware that 'via em3' on any outbound packets 
applies to packets that were either received on or are being transmitted 
on em3?  It's often better to disambiguate 'via' with 'recv' and 'xmit'.

HTH, Ian