On 2023-03-24, at 15:18:56 +0100, Florian Westphal wrote: > Jeremy Sowden 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. Yup, no problem. > 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. J.
Attachment:
signature.asc
Description: PGP signature
