Rick van Rein <rick@xxxxxxxxxxxxxxx> wrote:
> - Encapsulated traffic travels in reverse compared to a tunnel
> - ICMP-contained content must be NAT-reversed, unlike tunnel content
nf_nat takes care of this automatically.
>
> I would argue that these provide (not 100% hard) reasons to treat ICMP differently from tunnels. Possibly syntaxes, in line with what "nft" does now, could say things like
>
> ip protocol icmp
> icmp protocol { tcp, udp, sctp, dccp }
What would that do? "ip protocol" of embedded ip header?
> icmp th daddr set
> icmp th dport map @my-nat-map
th daddr looks weird to me, but syntax could
be changed later.
Dependency generation and delineraization would
likely be more of a challenge.
> 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.
