Re: nft tproxy failed to redirect on one system

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Aug 21, 2023 at 03:48:07PM +0800, Carl Lei wrote:
> Btw: sent to wrong address, re-sent to list...
> 
> On Fri, 11 Aug 2023 12:00:43 +0800
> Carl Lei <me@xecycle.info> wrote:
> 
> > Sorry for being incomplete, but I added nftrace before these rules and
> > saw packets went through the same chain of rules, first hitting tproxy
> > in mangle, then meta mark 42 counter accept in input-new-isolated.
> > But on one system it works for local programs AND network-received
> > packets, on another system it works only for local programs.  On the
> > bad system the packets instead gets directed to whatever program
> > originally listening on the original port, or rejected; e.g. I have
> > an nginx listening on 0.0.0.0:80 but no programs on 443, then curl
> > http in a vm connected to vbr0 goes to my nginx, and curl https gets
> > rejected.  I expect them to go to that program listening on 1081.  
> 
> Looked closer at the trace, I found that on the bad system, when the
> packet goes back to input rules, its trace id changed; on the good
> system it does not change.  Perhaps this explains it, but I don't know
> why it was changed?

Could you provide more detailed information on your setup? You refer
to a system where this works fine and another where this does not, but
you do not specify kernel and userspace versions?

Some simple script with 'ip netns' as a reproducer might also help
that might help people jump in a provide feedback.

Thanks.