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