Hi Florian,
>> - ICMP-contained content must be NAT-reversed, unlike tunnel content
> nf_nat takes care of this automatically.
Hmyeah, I know. I am really trying with stateless NAT, which I know is not the general advise. Intending to push p2p applications, I fear that things like a TCP SYN from two ends at the same time are asking for trouble.
>> ip protocol icmp
>> icmp protocol { tcp, udp, sctp, dccp }
>
> What would that do? "ip protocol" of embedded ip header?
Yes, that's what I meant with this.
>> icmp th daddr set
>> icmp th dport map @my-nat-map
>
> th daddr looks weird to me, but syntax could
> be changed later.
Yes, I made a mistake. It should have said "icmp ip daddr set".
On a side note, I found a good reason for "th daddr" instead of "@th,16,16" that goes beyond readability: its typing can be used in a map with inet_service, unlike @th,16,16 which is a variably-sized integer.
>> If this ends up being kernel work, then I'm afraid I will have to let go.
>
> It can probably be done using fixed offsets for this
> specific case but its likely a lot of work wrt. dependency
> checking and providing readable syntax for "nft list" again.
Thanks for warning me upfront. I will try to stay away from it then until I really have the time.
Best,
-Rick
