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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[email protected]"
