¿Por qué solo se necesitan 3 políticas ip xfrm para un túnel IPsec?

Tengo un túnel IPsec de sitio a sitio funcionando entre una strongswaninstancia (v5.2.0) (sitio A) y un RouterOSenrutador (sitio B). Todo funciona bien, los hosts en las dos configuraciones de subredes privadas para el sitio A ( 10.10.0.0/16) y B ( 10.50.0.0/16) pueden comunicarse entre sí perfectamente.

Sin embargo, lo que no entiendo es la siguiente salida del ip xfrm policyenrutador del sitio A (IP públicas ofuscadas). Estas políticas fueron creadas por strongswan, no las instalé ni modifiqué manualmente:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

Hay una política para cada entrada y salida, pero solo una para reenviar (del sitio B al sitio A). Pero todavía puedo hacer ping con éxito, por ejemplo, 10.50.4.11desde 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

La parte interesante de este rastreo de ruta es que el enrutador del sitio A ( 10.10.0.2) solo se muestra en la ruta desde el objetivo de ping, mientras que el enrutador del sitio B ( 10.50.0.1) solo aparece en la lista para la ruta saliente.

Esto parece confirmar que en realidad no se necesita una política de reenvío en el enrutador del sitio A para reenviar 10.10.0.0/16a 10.50.0.0/16través del túnel IPsec, pero no entiendo por qué.

Gracias por cualquier explicación!

El núcleo no genera automáticamente las políticas fwd , sino que las instala el demonio de claves (strongSwan en este caso).

Se requieren para permitir que el tráfico se reenvíe hacia y desde los hosts detrás de la puerta de enlace VPN en modo túnel.

Para un paquete entrante que se dirige a una IP que no está instalada en la puerta de enlace , se busca una política fwd después del descifrado. Para el tráfico local , se busca una coincidencia en la política. Si no se encuentra ninguno, el paquete se descarta.

Para el tráfico saliente que no se generó en la puerta de enlace VPN , se busca una política fwd . Si el paquete no se cifró, no es un error si no se encuentra una política de fwd coincidente . Y si el tráfico se reenvía entre dos túneles, la política fwd entrante instalada con uno actuará como política fwd saliente para el otro y viceversa. Posteriormente, se busca una política de salida para decidir si se tuneliza el paquete. Es por eso que a menudo no se requiere una política de fwd en la dirección de salida.

Sin embargo, si hay, por ejemplo, una política fwd de caída / bloqueo con baja prioridad que coincida con todo (por ejemplo, para evitar que el tráfico de texto en claro pase la puerta de enlace si no hay túneles establecidos), se requiere explícitamente una política fwd en la dirección de salida, ya que la política de bloque de lo contrario, descarte todo el tráfico no cifrado. Es por eso que strongSwan comenzó a instalar políticas fwd en ambas direcciones con 5.5.0 .

Una versión anterior de esta respuesta indicó que la política fwd única (entrante) es simétrica (es decir, que src y dst funcionan en cualquier dirección). Eso no es cierto, pero como se explicó anteriormente en muchas situaciones, esto no importa.