Supongo que con IPSec / IKEv1, ya que no es compatible con NAT, debe configurar manualmente las rutas desde su máquina o usar un túnel de capa 2 (como l2tp) para hablar con los dispositivos de la red te estás conectando a Con IKEv2 es compatible con NAT, por lo tanto, no se requiere la tunelización / enrutamiento de la capa 2 (excepto con configuraciones realizadas por un administrador en la puerta de enlace de VPN una vez).
Encontré esta pregunta aquí: enlace
IPsec se ha desarrollado para IPv6, que ya no conoce NAT y el uso de IPsec para IPv4 siempre ha sido una especie de pirateo. No tener NAT para los llamados guerreros del camino que usaban IPv4 era un no-go. La única forma de hacerlo funcionar en la 90 era usar L2TP, porque L2TP funciona sobre UDP y NAT es posible.
Mi comprensión es entonces esto:
L2TP se usa con IKEv1 para los "guerreros del camino" / personas que necesitan conectarse de forma remota a una red. Evita la limitación de que IKEv1 no tenga NAT o requiera que el cliente configure su propia tabla de enrutamiento para hablar con los clientes en la red remota
IKEv2 admite NAT, lo que permite al trabajador remoto comunicarse con los clientes en la red remota, por lo que no se requiere L2TP. IKEv2 también tiene muchas otras ventajas.
L2TP probablemente no se use para las VPN de sitio a sitio, o para el modo de transporte, ya que los administradores configuran las tablas de enrutamiento o las comunicaciones se realizan internamente.
L2TP no se usa solo ya que no hay cifrado, por lo que IPSec está asegurado a una puerta de enlace (con IKEv1), luego L2TP toma el control en la puerta de enlace a través de la conexión IPSec para hablar dentro de la red.
Técnicamente podría utilizar L2TP con IKEv2, simplemente no es necesario. También tendría un impacto en el rendimiento, y probablemente otros inconvenientes, sin beneficio.