Rules will only match if all components match. So you seem to understand that packets will be seen twice - once IN, once OUT. If you write
in recv EXT_IP out xmit EXT_IP the rule actions won't get executed twice on packets. On Wed, Mar 9, 2016 at 11:20 AM, Don Lewis <truck...@freebsd.org> wrote: > On 9 Mar, Freddie Cash wrote: > > On Wed, Mar 9, 2016 at 10:09 AM, Don Lewis <truck...@freebsd.org> wrote: > > > >> On 9 Mar, Franco Fichtner wrote: > >> > Hi Don, > >> > > >> > If you mean pf(4)-based NAT, there is a patch that originates from > >> > m0n0wall that handles the transition. We're using it in OPNsense > >> > for that reason. Here is the patch for 10.x, maybe that is what > >> > you're looking for: > >> > >> Nope, I'm using ipfw in-kernel NAT, which is not the default in > >> rc.firewall, but is easy to paste in next to or in place of the default > >> natd configuration. > >> > >> case ${firewall_nat_enable} in > >> [Yy][Ee][Ss]) > >> if [ -n "${firewall_nat_interface}" ]; then > >> if echo "${firewall_nat_interface}" | \ > >> grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; > then > >> firewall_nat_flags="ip > >> ${firewall_nat_interface} ${firewall_nat_flags}" > >> else > >> firewall_nat_flags="if > >> ${firewall_nat_interface} ${firewall_nat_flags}" > >> fi > >> ${fwcmd} nat 123 config log > ${firewall_nat_flags} > >> ${fwcmd} add nat 123 ip4 from any to any via > >> ${firewall_nat_interface} > >> fi > >> ;; > >> esac > >> > >> My suspicion is that if a packet matches the rule to pass it to dummynet > >> that it is bypassing NAT. > >> _______________________________________________ > >> freebsd-ipfw@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > >> > > > > ?Do you have the sysctl net.inet.ip.fw.one_pass set to 0 or 1? > > Aha, I've got it set to 1. > > > If set to 1, the a dummynet match ends the trip through the rules, and > the > > packet never gets to the NAT rules. Or, if a NAT rule matches, the trip > > through the rules ends, and it never get to the dummynet rules. > Depending > > on which you have first. > > Dummynet is first. > > > You'll need to set net.inet.ip.fw.one_pass?=0 in order to re-inject the > > packet into the rules after it matches a dummynet or NAT rule. Or, do > the > > NAT and dummynet rules on different interfaces to match different > traffic. > > How do I prevent the re-injected packets from being sent back into > dummynet? My NAT rule looks like it could have the same problem, but > that looks fixable. > > The NAT traffic should also pass through dummynet unless it is to or > from the /29 outside network. Locally originated traffic ("me") passing > through the external interface should also go through dummynet unless > the other host is on the /29. > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > _______________________________________________ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"