Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Mar 2016 11:37:42 -0800
From:      Michael Sierchio <kudzu@tenebras.com>
To:        Don Lewis <truckman@freebsd.org>
Cc:        Freddie Cash <fjwcash@gmail.com>,  "freebsd-ipfw@freebsd.org" <freebsd-ipfw@freebsd.org>
Subject:   Re: ipwf dummynet vs. kernel NAT and firewall rules
Message-ID:  <CAHu1Y739s7JySU1ho3HzgpSQ65V-wdRYRYLsH3=qSoNu2=MUQg@mail.gmail.com>
In-Reply-To: <201603091920.u29JK0jq011362@gw.catspoiler.org>
References:  <CAOjFWZ5=ffj-mHWDvmsc=JDVSKc8Ttck-Ukg-RqUpuOcUsTdOw@mail.gmail.com> <201603091920.u29JK0jq011362@gw.catspoiler.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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 <truckman@freebsd.org> wrote:

> 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.
>
> _______________________________________________
> 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"
>



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?CAHu1Y739s7JySU1ho3HzgpSQ65V-wdRYRYLsH3=qSoNu2=MUQg>