From owner-freebsd-ipfw@freebsd.org Wed Mar 9 21:01:09 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 ECC11AC8060 for ; Wed, 9 Mar 2016 21:01:09 +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 D341C754 for ; Wed, 9 Mar 2016 21:01:09 +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 u29L0wwH011694; Wed, 9 Mar 2016 13:01:02 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603092101.u29L0wwH011694@gw.catspoiler.org> Date: Wed, 9 Mar 2016 13:00:58 -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 21:01:10 -0000 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. >> >>> 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! Ignoring dummynet for a moment since I haven't added those rules back ... DNS lookups break when I set net.inet.ip.fw.one_pass=0. This machine is running BIND as a DNS forwarder and I have this rule to allow DNS lookups in and out: pass udp from me to any 53 out via re0 keep-state If BIND has the results of a lookup cached, then I get the expected query results from an internal host when I set net.inet.ip.fw.one_pass=0, but if the results are not cached I get ";; connection timed out; no servers could be reached" when I do a lookup on an internal host, and running the query on the firewall machine also does not work. If BIND has the query cached, I am able to download from servers on the internet to an internal host, so that indicates that NAT is functioning, but it shouldn't be involved in DNS lookups.