Date: Thu, 10 Mar 2016 12:24:19 -0800 From: Julian Elischer <julian@freebsd.org> To: Don Lewis <truckman@FreeBSD.org>, fjwcash@gmail.com Cc: freebsd-ipfw@freebsd.org Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules Message-ID: <56E1D7F3.5040101@freebsd.org> In-Reply-To: <201603092101.u29L0wwH011694@gw.catspoiler.org> References: <201603092101.u29L0wwH011694@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/03/2016 1:00 PM, 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. >>> >>>> 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! actually it doesn't... it starts at the next rule NUMBER which may be a different thing. > 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. > > > _______________________________________________ > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56E1D7F3.5040101>