Re: Extensions for ICMP[6] with sport, dport

[Rick van Rein <rick@openfortress.nl>]

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