On Wed, 27 Mar 2024, Panwei (William) wrote:
Thanks for your clarification. I'm much clearer about the problems now.
> > When you find out that the IKEv2 negotiation succeeds but ESP
> > traffic can't get through, what more information will you get
> > from sending the ESPping and not receiving a response?
>
> That there is a problem with proto=50... So:
> a) do UDP encap (maybe by manual config, if you are clueful)
> b) call network support and file a problem report.
I mean, when you find out that the IKEv2 negotiation succeeds but ESP traffic
can't get through, you can already guess there may be a problem with ESP packet.
Waiting for failure and timeouts afterwards, eg once the IPsec SA is up,
is costly and now you have to try to setup udp-encap or try ipv4. The
idea is to send an ESP-ping beforehand to your server that is known to
support this, and test for a reply. If you don't get it, initiate IKEv2
using IPv4 (basically also guaranteeing NAT and UDP-encap), not native IPv6.
If you want to use ESPping to determine the problem is really because of the
on-path firewalls or routers discard the ESP packets, you need to make sure the
IPsec peer also supports the ESPping.
It would be part of the client configuration I guess to try this.
If you want to do the traceroute to determine how far ESP actually gets, you
need to make sure every node supports the ESPping.
I think people meant to extend traceroute to use an ESP packet instead
of an ICMP or UDP packet. The machines in the middle do not need any
special support because any packet that hits TTL=0 should solicite
an ICMP response.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
