netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Antonio Ojea <antonio.ojea.garcia@gmail.com>, netfilter@vger.kernel.org
Subject: Re: Query on nftables DNAT for localhost-to-localhost traffic in IPv6 or without route_localnet
Date: Tue, 12 Aug 2025 14:18:20 +0200	[thread overview]
Message-ID: <aJsxDCRGVSQjGh6f@calendula> (raw)
In-Reply-To: <aJsi1_zrVmQyHyw0@strlen.de>

On Tue, Aug 12, 2025 at 01:17:43PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > >This seems to do the trick:
> > 
> > To simplify this example below, would it be possible to extend nft_fib
> > to attach DST_METADATA in prerouting to modify the ip6_route_input_lookup()
> > behaviour? This is similar to the conntrack template, but for routing.
> 
> skb_valid_dst() doesn't consider DST_METADATA as a valid dst, afaics the
> dst is then discarded and we end up in the same code paths.
>
> But I think we could extend nft_fib to attach a route/dst.

Then ip6_route_input_lookup() needs to be updated, and it would be
good if there is a flag somewhere to specify that the existing route
is intentional to skip this:

        skb_dst_drop(skb);
        skb_dst_set_noref(skb, ip6_route_input_lookup(net, skb->dev,
                                                      &fl6, skb, flags));

> But at this time I don't want to spend time on enabling such hacks
> (lo-to-remote-dst-nat) unless there is a good use case for it.

I am not familiar with this use-case.

  reply	other threads:[~2025-08-12 12:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 22:59 Query on nftables DNAT for localhost-to-localhost traffic in IPv6 or without route_localnet Antonio Ojea
2025-08-04  8:25 ` Florian Westphal
2025-08-11 20:08   ` Pablo Neira Ayuso
2025-08-12 11:17     ` Florian Westphal
2025-08-12 12:18       ` Pablo Neira Ayuso [this message]
2025-08-18 16:11         ` Antonio Ojea

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=aJsxDCRGVSQjGh6f@calendula \
    --to=pablo@netfilter.org \
    --cc=antonio.ojea.garcia@gmail.com \
    --cc=fw@strlen.de \
    --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 NNTP newsgroup(s).