From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: nft tproxy failed to redirect on one system Date: Tue, 22 Aug 2023 12:05:01 +0200 Message-ID: References: <20230811120043.0c3c6302@xcws1> <196291AF4921A1FE+20230821154807.270690a5@xcws1> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <196291AF4921A1FE+20230821154807.270690a5@xcws1> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Carl Lei Cc: netfilter@vger.kernel.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 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.