On Thu, Oct 11, 2018 at 7:30 AM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> ad^2 <adsquaired@xxxxxxxxx> wrote:
> > Has anyone witnessed this? I have Nftables setup with prerouting,
> > postrouting and forwading rules that work well. Until it doesn't.
> > As you can see from the trace below the postrouting rule is not
> > natting the packet. ip saddr 192.168.254.1 out eth1 should be an
> > Internet routable address.
> > Stopping and starting nftables (flushing rules) does not help. I then
> > reboot the server and everything starts working again.
>
> Does 'conntrack -F' help (instead of reboot)?
>
> It might be related to fix:
>
> commit f94e63801ab2791ed64c409d0f751f6a0c953ead
> ("netfilter: conntrack: reset tcp maxwin on re-register"), which
> causes conntrack to no longer pick up packets of established
> connections (and without conntrack, nat won't work).
I will try to break it again and will let you know. There's a bunch of
tests that are run creating and deleting rules ( a lot ) to see how it
scales. I have a feeling this is the root cause. We will see.
>
> > Something else to note. After things are working again I setup nftace
> > again expecting to see the correctly translated address on eth1.
>
> > Packets again don't flow through. When I remove the trace statements
> > (handles) packets flow again. I do not know if this is the expected
> > behavior or not.
>
> Its not. Trace rules should have no side effects.
> Can you provide a small ruleset that reproduces this bug?
This definitely happens. Heres the ruleset - h.t.t.p.s: // pastebin.
com /eXTA10WA
>
> > trace id 18162e6e ip myfw postrouting packet: oif "eth1" @ll,0,112
> > 6365045784477331379336991475712 ip saddr 192.168.254.1 ip daddr
> > 64.233.177.106
>
> Note that even postrouting might not yet show the to-be-rewritten
> address, the snat rewrite occurs at postrouting, but it depends on
> the base hook chain priority.
>
> If you add a hook at prio 300 then the packets' address should
> have been rewritten.
I updated the prio on the postrouting chain to 300 but I still see the
internal source address. Running tcpdump on the external interface
shows the packet leaving without being natted (with the following
traces active).
nft insert rule ip myfw postrouting tcp dport 80 counter nftrace set 1 accept
nft insert rule ip myfw prerouting tcp dport 80 counter nftrace set 1 accept.
As soon as I delete the traces and run the same curl command the
packets leave translated.
Let me know what else you need from me.
Thx in advance.
