netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Glen Huang <heyhgl@gmail.com>
To: netfilter@vger.kernel.org
Cc: ecklm94@gmail.com
Subject: Why tproxy to 127.0.0.1:port doesn't make packets go through the input chain with iifname lo?
Date: Sun, 14 May 2023 15:24:03 +0800	[thread overview]
Message-ID: <B4205731-F80B-4A87-B932-8749C51A06FB@gmail.com> (raw)

Hi,

I think I mostly understand how TPROXY works, thanks to Máté’s super helpful article [1].

However, I still don’t understand how the "to address:port” part work. Given this rule:

nft add rule nat prerouting iifname lan tproxy to 127.0.0.1:1234 meta mark set 1 accept

And this policy based routing:

ip rule add mark 1 lookup 100
ip route add local default dev lo table 100

When does a packet arriving on “lan" get redirected to 127.0.0.1:1234? Is it before or after the routing decision? It seems it should be after, but from trace, it shows that the packet goes through the input chain and its iifname is lan. Since tproxy redirects it to 127.0.0.1, shouldn’t it be “lo" instead?

I wonder what the flow chart is like? My current guess is that packets arriving on “lan" first get routed to “lo", because of the mark and the policy routing, then tproxy redirects it to 127.0.0.1:1234, but again, this is probably wrong given iifname being lan. I also wonder do <addr> and <interface> have to match in "tproxy to <addr>:port “ and "dev <interface> table 100”? What the flow chart is like if they don’t?

PS: In my case, lan is actually an XFRM interface, not sure if that matters.

Could someone offer some pointers? Thanks in advance.

[1] https://gsoc-blog.ecklm.com/iptables-redirect-vs.-dnat-vs.-tproxy/

             reply	other threads:[~2023-05-14  7:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-14  7:24 Glen Huang [this message]
2023-05-20 14:19 ` Why tproxy to 127.0.0.1:port doesn't make packets go through the input chain with iifname lo? Eckl, Máté
     [not found]   ` <CAKcfE+bo1hJXF4M1rm2KfWGZ7meYKtfWfGBd6+Rktd2XiUMfdg@mail.gmail.com>
2023-05-20 23:07     ` Glen Huang
     [not found]       ` <CAKcfE+bewEQq2BPNAwaHM99NDwmDMRtu9qPcAdkC=5J5k+7tvg@mail.gmail.com>
2023-05-22 14:52         ` Glen Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B4205731-F80B-4A87-B932-8749C51A06FB@gmail.com \
    --to=heyhgl@gmail.com \
    --cc=ecklm94@gmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).