kern/157796: [ipfw] IPFW in-kernel NAT nat loopback / Default
Router Changes Unexpectedly
Ian Smith
smithi at nimnet.asn.au
Mon Jun 13 06:37:10 UTC 2011
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
More information about the freebsd-ipfw
mailing list