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).
> 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?
> 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.
