Date: Wed, 9 Mar 2016 13:00:58 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: fjwcash@gmail.com Cc: freebsd-ipfw@freebsd.org Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules Message-ID: <201603092101.u29L0wwH011694@gw.catspoiler.org>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603092101.u29L0wwH011694>