Jeremy Sowden <jeremy@xxxxxxxxxx> wrote: > Support for shifted port-ranges was added to iptables for DNAT in 2018. > This allows one to redirect packets intended for one port to another in > a range in such a way that the new port chosen has the same offset in > the range as the original port had from a specified base value. > > For example, by using the base value 2000, one could redirect packets > intended for 10.0.0.1:2000-3000 to 10.10.0.1:12000-13000 so that the old > and new ports were at the same offset in their respective ranges, i.e.: > > 10.0.0.1:2345 -> 10.10.0.1:12345 > > This patch-set adds support for doing likewise to nftables. In contrast > to iptables, this works for `snat`, `redirect` and `masquerade` > statements as well as well as `dnat`. Could you rebase and resend the kernel patches now that the refactoring patches have been merged? I'd like to have another look at it now that the fixes and refactoring ones are in. Background: I wonder if going with NF_NAT_RANGE_PROTO_OFFSET is really a good idea or not, because it seems rather iptables-kludgy. But if its not much work it might be simpler to jsut go along with it. An alternate approach would be to support addition in nft, so one could do: dnat to tcp dport + 2000 ... to get such a 'shift effect'. [ yes, the bison parser might not like this syntax, I made it up for illustrative purposes. ] Something like this would also allow to emulate TTL/HL target of iptables, ATM we can set a fixed value but cannot add or decrement them. Thanks.
