bpf: nat: handle egressing ICMPv6 error messages with embedded ECHO / ECHO_REPLY #39661
Conversation
…QUEST If we're sending an ICMPv6 error message for an ICMPV6_ECHO_REQUEST packet, then this packet was previously received on the node. Therefore the ECHO session didn't originate locally, and so we don't need to apply SNAT and can just let the ICMPv6 error message pass through. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
If we're sending an ICMPv6 error message for an ICMPV6_ECHO_REPLY packet, then this packet was previously received on the node. Therefore the ECHO session originated locally, and we need to check for SNAT. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
fc652d9 to
9dc11f8
Compare
|
/test |
There was a problem hiding this comment.
Looks good to me in general, but could you elaborate more about the concrete situation where we hit this REPLY case? If the echo request is locally originated and if we trigger the ICMP error for the reply, the packet will go back to the peer, so we don't really see it I think.
Local endpoint sends an ECHO, which gets NATed when egressing the node. Remote endpoint sends a REPLY, which gets revNATed on ingress and delivered to the local endpoint. If the local endpoint then produces an ICMP error message for this REPLY, we need to apply NAT (== undo the RevNAT) on egress again. |
Following on to #38068, this adds support for
ECHO/ECHO_REPLYin egressing ICMPv6 error messages.One relevant scenario is an
DEST_UNREACHresponse for an inboundECHO.