From owner-freebsd-ipfw@freebsd.org Wed Mar 9 19:31:42 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70FDDACA022 for ; Wed, 9 Mar 2016 19:31:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AFC31D60 for ; Wed, 9 Mar 2016 19:31:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u29JOfQE011384; Wed, 9 Mar 2016 11:25:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603091925.u29JOfQE011384@gw.catspoiler.org> Date: Wed, 9 Mar 2016 11:24:41 -0800 (PST) From: Don Lewis Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules To: fjwcash@gmail.com cc: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 19:31:42 -0000 On 9 Mar, Don Lewis wrote: > On 9 Mar, Freddie Cash wrote: >> On Wed, Mar 9, 2016 at 10:09 AM, Don Lewis 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. I just read the fine man page and is says that after re-injection the packet starts with the next rule ... cool!