Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Mar 2016 17:53:34 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Don Lewis <truckman@freebsd.org>
Cc:        fjwcash@gmail.com, freebsd-ipfw@freebsd.org
Subject:   Re: ipwf dummynet vs. kernel NAT and firewall rules
Message-ID:  <20160310165323.U61428@sola.nimnet.asn.au>
In-Reply-To: <201603092302.u29N2IYm012240@gw.catspoiler.org>
References:  <201603092302.u29N2IYm012240@gw.catspoiler.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, 9 Mar 2016 15:02:18 -0800, Don Lewis wrote:
 > On  9 Mar, 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.

I observe that in 99 cases out of 100, the default of 1 is undesired,
but it's too late to do anything but advise people - thanks Freddie!

[..]

 > >> I just read the fine man page and is says that after re-injection the
 > >> packet starts with the next rule ... cool!

Make sure the next rule has a higher number; in some (but not all?) uses 
of one_pass actually restart with the next higher-numbered rule.

[..]

 > It looks like the problem was an interaction between
 > net.inet.ip.fw.one_pass, my NAT rules, and my keep-state rules.  My nat
 > rule was:
 >   nat 123 ip4 from any to any via re0
 > so it was matching by outgoing DNS queries even though they didn't need
 > to be NATed.  I think that when net.inet.ip.fw.one_pass=1, the DNS
 > queries were totally being handled by NAT and not using the keep-state
 > rule at all.  I'm wondering if net.inet.ip.fw.one_pass=0 was interfering
 > with setting the ipfw dynamic state and the response packet was getting
 > blocked after it was reinjected by NAT.
 > 
 > In any case, changing my NAT rules to this make things work:
 > 
 >   nat 123 ip4 from internal/24 to any out xmit re0
 >   nat 123 ip4 from any to me in recv re0

'in recv' and 'out xmit' are always clearer than 'via', and someimes (as 
here) necessary.  Another way, assuming you want to NAT everything from 
internal net(s) would be:

     nat 123 ip4 from any to any out xmit re0 recv $internal_if

 > The "me" in the second rule should really be the address of re0, but
 > that's not readily available.

'me' is fine in most cases, unless you are having other addresses routed 
to you, eg an external /29 or such, if those addresses also match 'me'.

Glad you've got it sorted.

cheers, Ian



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20160310165323.U61428>