Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?56E1D7F3.5040101>