bugzilla-daemon at netfilter.org
2024-Aug-14 11:21 UTC
[Bug 1764] New: mapping IPv4 interval to IPv4 interval works for anonymous maps, but not for named maps
https://bugzilla.netfilter.org/show_bug.cgi?id=1764 Bug ID: 1764 Summary: mapping IPv4 interval to IPv4 interval works for anonymous maps, but not for named maps Product: nftables Version: git (please specify your HEAD) Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: karel at unitednetworks.cz I want to create IPv4 SNAT mapping from interval to interval (SNAT M:N where N will be different for each interval from M). It looks like this is possible by using anonymous maps, but not by using named maps. System: ******************************** uname -a Linux karel2 6.10.4-gentoo #1 SMP PREEMPT_DYNAMIC Mon Aug 12 11:07:42 CEST 2024 x86_64 AMD Ryzen 5 8600G w/ Radeon 760M Graphics AuthenticAMD GNU/Linux cd /usr/src/nftables git status HEAD detached at 80258b03 nothing to commit, working tree clean nft --version nftables v1.1.0 (Commodore Bullmoose) ******************************** Anonymous map example: ******************************** nft add table t nft add chain t c { type nat hook postrouting priority srcnat\; } nft add rule t c snat ip to ip saddr map { 192.0.2.0/24 : 198.51.100.0/24 } persistent nft list ruleset table ip t { chain c { type nat hook postrouting priority srcnat; policy accept; snat ip to ip saddr map { 192.0.2.0/24 : 198.51.100.0/24 } persistent } } ******************************** Named map example: ******************************** nft flush ruleset nft add table t nft add chain t c { type nat hook postrouting priority srcnat\; } nft add map t m { type ipv4_addr: ipv4_addr\; flags interval\; } nft add rule t c snat ip to ip saddr map @m persistent nft list ruleset table ip t { map m { type ipv4_addr : ipv4_addr flags interval } chain c { type nat hook postrouting priority srcnat; policy accept; snat to ip saddr map @m persistent } } nft add element t m { 192.0.2.0/24 : 198.51.100.0/24 } Error: Value must be a singleton add element t m { 192.0.2.0/24 : 198.51.100.0/24 } ^^^^^^^^^^^^^^^ ******************************** I am aware of possibility to use verdict maps and dynamically create chains for each NATed interval, but it looks like unecessary overhead and it should work directly with named maps if it works with anonymous maps. Just tried duplicate interval flag, but it did not help: ******************************** nft add map t m1 { type ipv4_addr: ipv4_addr\; flags interval, interval\; } nft add element t m1 { 192.0.2.0/24 : 198.51.100.0/24 } Error: Value must be a singleton add element t m1 { 192.0.2.0/24 : 198.51.100.0/24 } ^^^^^^^^^^^^^^^ ******************************** -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240814/cbfcf050/attachment.html>
bugzilla-daemon at netfilter.org
2024-Aug-15 21:45 UTC
[Bug 1764] mapping IPv4 interval to IPv4 interval works for anonymous maps, but not for named maps
https://bugzilla.netfilter.org/show_bug.cgi?id=1764 --- Comment #1 from Pablo Neira Ayuso <pablo at netfilter.org> --- TLDR; Try this: table ip t { map m { type ipv4_addr : interval ipv4_addr flags interval elements = { 192.0.2.0 : 198.51.100.0/24 } } chain c { type nat hook postrouting priority srcnat; policy accept; snat to ip saddr map @m persistent } } I can post a patch to improve error reporting, to provide a hint. == Now looking further at this issue... Maybe this syntax can be revisited while retaining backwards compatibility, I can propose this instead: table ip t { map m { type ipv4_addr : ipv4_addr flags interval : interval elements = { 192.0.2.0/24 : 198.51.100.0/24 } } chain c { type nat hook postrouting priority srcnat; policy accept; snat to ip saddr map @m persistent } } however, if lhs is singleton, then I will need syntatic sugar like this 'singleton' keyword (which does not exist): table ip t { map m { type ipv4_addr : ipv4_addr flags singleton : interval elements = { 192.0.2.0 : 198.51.100.0/24 } } chain c { type nat hook postrouting priority srcnat; policy accept; snat to ip saddr map @m persistent } } otherwise this would need to print: flags : interval because no flags in the left hand side (ie. singleton values only) Another possibility is to push both interval flags to the type type interval lipv4_addr : interval ipv4_addr thanks. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240815/251f2302/attachment.html>
bugzilla-daemon at netfilter.org
2024-Aug-16 06:56 UTC
[Bug 1764] mapping IPv4 interval to IPv4 interval works for anonymous maps, but not for named maps
https://bugzilla.netfilter.org/show_bug.cgi?id=1764 --- Comment #2 from Karel Rericha <karel at unitednetworks.cz> --- type ipv4_addr : interval ipv4_addr Works! Sry I did not find it anywhere in docs or examples. Anyway this syntax is misleading and inconsistent. Specifying interval for map key by flag and for map value by type parameter is not good idea. BTW I guess same bad situation is there with concatenations (say you want singleton in the middle of concatenation). IMHO best solution is the last one you proposing: a) for backwards compatibility keep interval flag logic as it is (and may be deprecate it in future) b) new syntax for interval should precede type specifier: nft add map t m { type interval ipv4_addr: interval ipv4_addr } nft add set t s { type interval ipv4_addr . inet_service . interval ipv4_addr } This is much easier to read and comprehend. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240816/2eecc500/attachment.html>
Possibly Parallel Threads
- [Bug 1179] New: vmap and sets cause "BUG: invalid range expression type set"
- [Bug 1327] New: Cannot use named set for matching IPv4 networks
- [Bug 1185] New: counter flag proposal for sets and maps
- [Bug 1184] New: disable implicit concatenating of elements of sets with flag interval
- [Bug 1249] New: set update with timeout 0s removes timeout