Bug 61685

If ipfilter with ipnat is active on a particular interface and the ipfw
ruleset contains rules that send inbound packets on the same interface to
dummynet, they actually pass through ipnat twice, creating a bogus NAT table
entry, which later causes all outbound packets belonging to the same
connection to leave that interface effectively un-NATed (in the common case
of that interface being the external interface of a firewall with NAT, they
leave it with a private source IP address).

Fix: Packets that enter ip_input() in sys/netinet/ip_input.c are first passed
through ipfilter (and NATed) before they reach ipfw. If a packet is sent to
dummynet, it later re-enters ip_input(), where it is decided right at the
beginning that this packet has come from dummynet. Execution then jumps to
the label "iphack:", which is right before the ipfilter section, so the
packet is NATed for the second time on the same interface. Fix: jump after
the ipfilter section instead of in front of it.

The following patch seems to fix the problem:

How-To-Repeat: Try to setup a firewall using ipfilter/ipnat and ipfw with dummynet rules
for inbound packets on the external interface at the same time. Create an
ipnat rdr rule to redirect traffic on some port on the external interface to
a host on the internal network. Notice that you cannot establish any
connection to it from the outside. If you have a look with tcpdump, you will
find that the internal host's reply packets (e.g. TCP SYNACK) leave the
external interface with an internal (i.e. un-NATed) source IP address.