nft tproxy failed to redirect on one system

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.

Btw: sent to wrong address, re-sent to list...

Quoted 10 lines · On Fri, 11 Aug 2023 12:00:43 +0800 Carl Lei <[email protected]> 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?

Quoted 17 lines · Carl Lei

Btw: sent to wrong address, re-sent to list...

Quoted 11 lines · On Fri, 11 Aug 2023 12:00:43 +0800 Carl Lei <[email protected]> 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.

Quoted 4 lines

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.

Quoted 19 lines · On Tue, 22 Aug 2023 12:05:01 +0200 Pablo Neira Ayuso <[email protected]>…

Quoted 18 lines · Carl Lei

Btw: sent to wrong address, re-sent to list...

Quoted 12 lines · On Fri, 11 Aug 2023 12:00:43 +0800 Carl Lei <[email protected]> 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.

Quoted 8 lines

Quoted 4 lines

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?

Sorry I forgot that in my first email, indeed I replied to myself several times and already provided versions, but I did not realize I sent to a wrong address. My used versions are (copying from my previous mails):

"they are both running Arch Linux, the good system running kernel 6.4.8-arch1-1, the bad system I tried both 6.4.4 and 6.4.9; nftables version both 1:1.0.7-2; the proxy program on 1081 is also identical, running identical config."

Quoted 2 lines

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

I will try ASAP to make a reproducer.