El ESP descifra sin problemas y el paquete interno sigue sin ir a ninguna parte

El contador de recepción de ESP sube, el túnel sigue activo y la aplicación nunca ve el paquete. El descifrado se ejecutó, la verificación de integridad pasó y entonces el receptor tuvo que decidir qué es realmente la carga protegida. Es en ese último paso donde aparece una discrepancia de formato, y desde fuera no se parece en nada a un problema de cortafuegos.

Qué ves cuando la etiqueta miente

Nada en el registro del cliente lo distingue de un agujero negro de enrutamiento. Ambos producen un tiempo de espera de la aplicación junto a un túnel sano, y por eso los contadores reciben la culpa primero.

Un contador de recepción que sube es una buena noticia de verdad: los paquetes llegan y se autentican. No es prueba de que el paquete interno tuviera sentido para algo por encima de la capa criptográfica.

El tipo vive en el tráiler

En el modo túnel IPsec habitual, la carga protegida por ESP contiene un paquete IP interno completo. El campo de cabecera siguiente del tráiler identifica qué es esa carga, y no es un puerto TCP, ni un número de protocolo de la cabecera externa, ni forma parte del campo inicial de SPI y número de secuencia. RFC 4303 sección 2.6 lo define como el campo de tipo de carga, que es un nombre preciso para un trabajo preciso.

Los valores que encontrarás son pequeños y vale la pena recordarlos: IPv4 es 4 (0x04) e IPv6 es 41 (0x29).

Esos números proceden de las asignaciones de números de protocolo de la IANA, no de una convención local. Un emisor que declara IPv4 mientras encapsula un paquete IPv6 ha producido una inconsistencia de formato, y ninguna regla de cortafuegos repara bytes que contradicen su propia etiqueta.

Cómo distinguirlo de los sospechosos habituales

La mayoría de los paquetes perdidos no son defectos de codificación. Comprueba primero los selectores, porque un selector de tráfico que excluye el prefijo IPv6 descarta el tráfico antes de que nada se encapsule. Después comprueba el enrutamiento y luego el filtrado local en el host receptor. Solo cuando eso queda descartado, una discrepancia de formato de carga pasa a ser una explicación plausible.

Una captura cifrada no lo resolverá, porque la cabecera siguiente protegida está dentro de la carga cifrada. Necesitas diagnósticos de la implementación o un punto de observación descifrado admitido, y ambos requieren autorización antes de usarse.

Si nadie puede aportar esa evidencia, no tienes un fallo de formato. Tienes una teoría, y los selectores siguen siendo la mejor apuesta.

Qué no es la reparación

No desactives las comprobaciones de integridad para que el tráfico pase. No reescribas paquetes cifrados en un enrutador intermedio, porque no puede funcionar y corromperá el flujo mientras parece útil en una captura. No abras una regla de cortafuegos de aplicación más amplia con la teoría de que se está bloqueando un puerto. Nada de eso toca la discrepancia de etiqueta.

Si una discrepancia confirmada procede de una implementación par, guarda una reproducción mínima y saneada y llévala al canal admitido de esa implementación.

Verifica el flujo, no el contador

Tras la corrección, prueba el flujo IPv6 real de extremo a extremo: una petición de aplicación por el túnel, su respuesta y el par de direcciones que observa cada lado. Un contador ESP que sube solo demuestra que los paquetes se reciben y se autentican. No dice nada sobre si el paquete interno era utilizable.

Anota ambos resultados en el ticket. Movimiento del contador más un flujo que funciona es una reparación; movimiento del contador por sí solo es exactamente lo que tenías antes de empezar.