0

I am doing dynamic, short-lived UDP port forwarding based on source address to destination port tuples. This works fine using nftables with maps, lookups and appropriate rules (nat in a prerouting / nat dest chain and masq in postrouting / nat src chain).

However: when using NAT in nftables no rule lookup happens for follow up (established?) packets in a flow (see documentation). This means I cannot kill existing flow by dropping elements from a map and / or adding a filtering rule on maps.

I think the easiest way to handle this is to do stateless NAT. However a simple rule in a prerouting filter chain with priority raw like the following one (not using maps but variables to simplify the example) does not seem to work. I see the trace but no packets arrive at $target.

ip saddr $client ip protocol udp notrack ip daddr set $target nftrace set 1 return

Is there some documentation on how to build stateless NAT for nftables in detail that I'm missing? Do I need to add rules for the flow from $target back to $client as well?

Or is there a way to filter existing NAT flows that I'm not aware off, e.g. by adding aggressive connection tracking timeouts (not really sure if CT applies to NAT via nftables as well)?

Improve this question
2
  • Your current questions shrugs off stateful NAT and goes on stateless NAT and then gets additional problems to solve. So is the initial problem described "I cannot kill existing flow by dropping elements from a map and / or adding a filtering rule on maps." still the problem, or not anymore? And Given the little details provided, this would also (in addition to narrowing the scope by stating what's the actual question) require to provide a reproducible setup (see stackoverflow.com/help/minimal-reproducible-example ). Commented Mar 2, 2024 at 11:37
  • The original problem was killing existing NAT flows. This can be solved in at least two ways: filtering before connection tracking (raw priority) or filtering in forwarding. Digressing to stateless NAT did overload / stretch that question a bit, you're right! Commented Mar 3, 2024 at 18:01

1 Answer 1

Reset to default
0

Ok, it turns out the documentation is a tiny bit misleading. While it says, "No rule lookup happens for follow-up packets in the flow", it means that subsequent processing rules do not apply.

Adding a filtering chain at raw priority can still drop packets from an active NAT flow. The same goes for filtering in forward hooks (with changed dest ports, addresses etc).

While I'm still very interested in understanding how to model this stateless, adding filter rules in a prerouting filter chain with priority raw works.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.