From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Rick van Rein <rick@openfortress.nl>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Expressive limitation: (daddr,dport) <--> (daddr',dport')
Date: Mon, 8 Jun 2020 00:08:10 +0200 [thread overview]
Message-ID: <20200607220810.GA6604@salvia> (raw)
In-Reply-To: <5EDC7662.1070002@openfortress.nl>
Hi Rick,
On Sun, Jun 07, 2020 at 07:08:50AM +0200, Rick van Rein wrote:
> Hello,
>
> I seem to be running into an expressive limitation of nft while trying
> to do stateless translation. I prefer statelessness because it it is
> clearer for bidirectionality / peering, and saves lookup times.
>
> After nat64, I have a small set of IPv6 addresses and I would like to
> map their (daddr,dport) or better even (daddr,proto,dport) tuples to
> outgoing (daddr',dport'). Effectively, port forwarding for IPv6.
>
> Individual rules work, like this one side of a bidir portmap:
>
> nft add rule ip6 raw prerouting \
> ip6 daddr $PREFIX::64:75 \
> tcp dport 8080 \
> ip6 daddr set $PREFIX::100:20 \
> tcp dport set 80 \
> notrack
>
> I have problems doing this with the map construct, presumably because it
> does not atomically replace (daddr,dport) by (daddr',dport') but instead
> does two assignments with intermediate alterede state.
Right.
> This is bound to work in many cases, but it can give undesired
> crossover behaviours [namely between incoming IPs if they map to the
> same daddr' while coming from the same dport]:
>
> nft add rule ip6 raw prerouting \
> ip6 daddr set \
> ip6 daddr . tcp dport \
> map { $PREFIX::64:75 . 8080 : $PREFIX::100:20 } \
> tcp dport set \
> ip6 daddr . tcp dport \
> map { $PREFIX::100:20 . 8080 : 80 } \
So, you would consolidate this in one single rule? So there is one
single lookup to obtain the IP address and the destination port for
the stateless packet mangling.
> notrack
>
> So now I am wondering,
>
> 0. Is there a way to use maps as atomic setter for (daddr,dport)?
Not yet.
> 1. Can I reach back to the original value of a just-modified value?
You mean, the original header field that was just mangled? Like
matching on the former IP address before the mangling?
> 2. Is there a variable, or stack, to prepare with the old value?
But this is to achieve the atomic mangling that you describe above or
you have something else in mind? You would like to store the former IP
daddr in some scratchpad area that can be accessed later on, right?
Thanks.
next prev parent reply other threads:[~2020-06-07 22:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-07 5:08 Expressive limitation: (daddr,dport) <--> (daddr',dport') Rick van Rein
2020-06-07 22:08 ` Pablo Neira Ayuso [this message]
2020-06-08 10:02 ` Rick van Rein
2020-06-08 10:31 ` Pablo Neira Ayuso
2020-06-08 11:01 ` Rick van Rein
-- strict thread matches above, loose matches on Subject: below --
2020-06-01 16:08 Rick van Rein
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=20200607220810.GA6604@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rick@openfortress.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.