From owner-freebsd-ipfw@freebsd.org Thu Mar 10 06:53:39 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 CE345ACAF01 for ; Thu, 10 Mar 2016 06:53:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CAED230; Thu, 10 Mar 2016 06:53:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u2A6rYB2044049; Thu, 10 Mar 2016 17:53:35 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 10 Mar 2016 17:53:34 +1100 (EST) From: Ian Smith To: Don Lewis cc: fjwcash@gmail.com, freebsd-ipfw@freebsd.org Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules In-Reply-To: <201603092302.u29N2IYm012240@gw.catspoiler.org> Message-ID: <20160310165323.U61428@sola.nimnet.asn.au> References: <201603092302.u29N2IYm012240@gw.catspoiler.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: Thu, 10 Mar 2016 06:53:39 -0000 On Wed, 9 Mar 2016 15:02:18 -0800, Don Lewis wrote: > On 9 Mar, Don Lewis wrote: > > On 9 Mar, Don Lewis wrote: > >> On 9 Mar, Don Lewis wrote: > >>> On 9 Mar, Freddie Cash wrote: > >>>> > >>>> ?Do you have the sysctl net.inet.ip.fw.one_pass set to 0 or 1? > >>> > >>> Aha, I've got it set to 1. I observe that in 99 cases out of 100, the default of 1 is undesired, but it's too late to do anything but advise people - thanks Freddie! [..] > >> I just read the fine man page and is says that after re-injection the > >> packet starts with the next rule ... cool! Make sure the next rule has a higher number; in some (but not all?) uses of one_pass actually restart with the next higher-numbered rule. [..] > It looks like the problem was an interaction between > net.inet.ip.fw.one_pass, my NAT rules, and my keep-state rules. My nat > rule was: > nat 123 ip4 from any to any via re0 > so it was matching by outgoing DNS queries even though they didn't need > to be NATed. I think that when net.inet.ip.fw.one_pass=1, the DNS > queries were totally being handled by NAT and not using the keep-state > rule at all. I'm wondering if net.inet.ip.fw.one_pass=0 was interfering > with setting the ipfw dynamic state and the response packet was getting > blocked after it was reinjected by NAT. > > In any case, changing my NAT rules to this make things work: > > nat 123 ip4 from internal/24 to any out xmit re0 > nat 123 ip4 from any to me in recv re0 'in recv' and 'out xmit' are always clearer than 'via', and someimes (as here) necessary. Another way, assuming you want to NAT everything from internal net(s) would be: nat 123 ip4 from any to any out xmit re0 recv $internal_if > The "me" in the second rule should really be the address of re0, but > that's not readily available. 'me' is fine in most cases, unless you are having other addresses routed to you, eg an external /29 or such, if those addresses also match 'me'. Glad you've got it sorted. cheers, Ian