Cómo solucionar el fallo de verificación de ruta inversa en Fortinet con una ruta presente en la tabla de enrutamiento a través de la interfaz de entrada

En este artículo, abordaremos el problema de fallo en la verificación del camino inverso (RPF) en dispositivos FortiGate, un tema crucial para garantizar la correcta sincronización y flujo de tráfico en redes que utilizan FortiOS. Este fallo puede surgir incluso cuando la ruta está presente en la tabla de enrutamiento. Proporcionaremos un análisis detallado y una solución recomendada para resolver esta cuestión.

Descripción del problema

Este artículo describe el escenario donde se observa un fallo en la verificación del camino inverso a pesar de que la ruta está presente en la tabla de enrutamiento a través de la misma interfaz de entrada.

Alcance

FortiOS, FortiGate.

Diagnóstico paso a paso

Al ejecutar los flujos de depuración, se observa lo siguiente para el tráfico descartado:

trace_id=2 func=print_pkt_detail line=5920 msg="vd-root:0 received a packet(proto=6, 192.168.200.1:60896->10.10.10.1:443) tun_id=10.100.1.1 from VPN_12. flag [S], seq 485006843, ack 0, win 65535"
trace_id=2 func=init_ip_session_common line=6110 msg="allocate a new session-0015ab87"
trace_id=2 func=iprope_dnat_check line=5480 msg="in-[VPN_12], out-[]"
trace_id=2 func=iprope_dnat_tree_check line=824 msg="len=0"
trace_id=2 func=iprope_dnat_check line=5505 msg="result: skb_flags-02000008, vid-0, ret-no-match, act-accept, flag-00000000"
trace_id=2 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop"
                

La tabla de enrutamiento para la dirección IP 192.168.200.1 se ve de la siguiente manera:

FGT # get router info routing-table details 192.168.200.1
Routing table for VRF=0
Routing entry for 192.168.200.0/24
Known via "static", distance 10, metric 0, best
           * directly connected, VPN_01
           * directly connected, VPN_02
           * directly connected, VPN_11
           * directly connected, VPN_12
                

A pesar de tener la ruta en la tabla de enrutamiento a través de la interfaz VPN_12, FortiGate está descartando paquetes. Es importante comprobar si la ruta está instalada en la tabla de enrutamiento del kernel con los siguientes comandos:

get router info kernel
diagnose ip route list
                

Ejemplo de salida:

FGT# get router info kernel 
tab=254 vf=0 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->192.168.200.0/24 pref=0.0.0.0
gwy=0.0.0.0 flag=00 hops=0 oif=80(VPN_01)
gwy=0.0.0.0 flag=00 hops=0 oif=94(VPN_02)
gwy=0.0.0.0 flag=00 hops=0 oif=77(VPN_11)
                

Como la ruta falta en la tabla de enrutamiento del kernel para VPN_12, el tráfico se descarta en FortiGate debido al fallo de verificación RPF.

Solución recomendada

En el escenario anterior, la ruta no llegó a la tabla de enrutamiento debido a que el límite de ECMP estaba establecido en 3. Para comprobar la configuración, podemos usar los siguientes comandos:

FGT # config sys setting 
FGT (settings) # get | grep ecm
                

Esto devolverá la siguiente información:

v4-ecmp-mode        : source-ip-based
ecmp-max-paths      : 3
                

Como se permiten solo 3 rutas, la cuarta ruta no se añade al kernel, provocando que FortiGate termine descartando el tráfico. La ruta aparece en la tabla de enrutamiento, pero no se añade al kernel. En caso de haber más de 255 rutas, la 256.ª ruta tampoco se incluirá en la tabla de enrutamiento del kernel, lo que causará el mismo problema (la ruta está presente en la tabla de enrutamiento, pero el flujo de depuración muestra RPF debido a que la ruta no está presente en la tabla de enrutamiento del kernel).

Esto está diseñado así, ya que FortiGate solo soporta 255 ecmp-max-paths. Para más detalles sobre esto, se recomienda abrir un ticket con el equipo de soporte de Fortinet.

Comandos CLI utilizados

get router info routing-table details
get router info kernel
diagnose ip route list
config sys setting
get | grep ecm
                

Buenas prácticas y recomendaciones

Es recomendable mantener documentadas las configuraciones de las rutas y observar periódicamente los límites de ECMP y la configuración del kernel para evitar problemas de rendimiento.

Notas adicionales

Revisar la arquitectura de red y considerar la posibilidad de aumentar el límite de caminos ECMP si se espera un crecimiento en el número de rutas, o utilizar mecanismos alternativos de enrutamiento.