From owner-freebsd-ipfw@freebsd.org Wed Mar 9 19:37:44 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 09A9FACA39D for ; Wed, 9 Mar 2016 19:37:44 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE1EB62C for ; Wed, 9 Mar 2016 19:37:43 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-yk0-x230.google.com with SMTP id y66so25398744ykd.2 for ; Wed, 09 Mar 2016 11:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bPIvXonX6Ew3qZFngN9lpzMhd8rPO/5JegWR7iiWzYw=; b=CGsN3tbtUZkKrGrFcRpsKu975LLljkdzntO+fb+yIqTJyaKOOcaTzTJwDpHqCzPWa/ P3tbZCCgtcoev38pPAApE0ynCHrPixi+gzo1Sj2HOIaLkT8sOuBCfNw8Q/RfS54o53yE TgfL0jjV7hLL8WU6E/7f0ZD8ppj0Go2ZWeMkWi3cI0Qk5iywgjaArH5GNZ1JMfax4749 nIb0vjQD26Qd5rnu3Or/A4bdlmKaXQznpjm0BPir0bCJuJC5Sf5t8tHs1B1b1BMj8PcS vGPwre2IiJNN8nGRYPllmLr3IKMX0Z8oU5tMeGeKBUsWu4kmazabbwUNDovpoPTrcRwv O5NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bPIvXonX6Ew3qZFngN9lpzMhd8rPO/5JegWR7iiWzYw=; b=TTOLD6fXXy5MFDsEBN2Ei/Btgc4QTnpvcO0R9Y4ZMxXUqfCzcOQ0KpTeDBUhiiJnwB cobr1aEzFwPhRNAEIajk9GX/aOFiIKc34eonQShHpuw7PM31evNM2C35KSwyASnSRLqE J1nZ6ZDEXiZp72tQ8+YlG8mvEFvKnVzhKyG4z81JNh0nJnTE1cdp/WoS/7nxOIBHrRcz CrgOuiFxZEVifQHCtuwwDd+FAHlhuykFguTGnmDYbYQ3GmyoRUCMYPixVavqeJdPkngQ EDlugChuBAzGAyhoDCWyjDU+zxBWuWat07gpIPb0+HmVkyyosgKNwLyBPF368FVkV9EW x6LA== X-Gm-Message-State: AD7BkJLtvHNsyt0lIUFu516b2okkzitQidbybtNBjL8INMDg/wD6KrWjc/imWzikD360Jsn9r4cAB7AT8ARZVePW MIME-Version: 1.0 X-Received: by 10.37.31.87 with SMTP id f84mr19224139ybf.151.1457552262736; Wed, 09 Mar 2016 11:37:42 -0800 (PST) Received: by 10.37.77.193 with HTTP; Wed, 9 Mar 2016 11:37:42 -0800 (PST) In-Reply-To: <201603091920.u29JK0jq011362@gw.catspoiler.org> References: <201603091920.u29JK0jq011362@gw.catspoiler.org> Date: Wed, 9 Mar 2016 11:37:42 -0800 Message-ID: Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules From: Michael Sierchio To: Don Lewis Cc: Freddie Cash , "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:37:44 -0000 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 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. > > 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" >