Date: Wed, 9 Mar 2016 11:20:00 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: fjwcash@gmail.com Cc: freebsd-ipfw@freebsd.org Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules Message-ID: <201603091920.u29JK0jq011362@gw.catspoiler.org> In-Reply-To: <CAOjFWZ5=ffj-mHWDvmsc=JDVSKc8Ttck-Ukg-RqUpuOcUsTdOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Mar, Freddie Cash wrote:
> On Wed, Mar 9, 2016 at 10:09 AM, Don Lewis <truckman@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-unsubscribe@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603091920.u29JK0jq011362>