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@xxxxxxxxxxxx> 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.
