Fortigate -> SDwan -> may_dirty

Estos cacharros hacen cosas muy raras (y no es de ahora). Imaginaros la siguiente escena, un firewall con dos conexiones, una hacia una MPLS y otra hacia internet (y una tercera conectada a la red local), nada del otro mundo.

3 formas de llegar al datacenter …

1.-Usando la MPLS (la «por defecto»)
2.-Usando una VPN por internet contra el firewall del datacenter (la «por si las moscas»)
3.-Usando una VPN por 5G con un fortiextender contra el mismo firewall del datacenter (por internet, con una velocidad de mierda (la que da el 5G)).

Todo esto es un interface SDwan, así que de manera lógica el firewall decide hacia donde enruta el tráfico.

Ahora la película, un mantenimiento en el datacenter, el firewall central y la mpls se desconectan.

Así que, el firewall se queda sin la opción 1, despues sin las 2 y la 3 … el firewall no sabe por donde tiene que sacar el tráfico. El solito decide intentar sacarlo hacia Internet (usando la ruta por defecto). Vale, hasta ahí lo compro.

El firewall del datacenter vuelve a la vida, internet y mpls.

Lo lógico seria que, en cuanto detecte la conexión (que no es que la detecte, es que las ips que hay puestas para los SLAs empiecen a contestar de nuevo) la Sdwan decida volver a la normalidad, esto es … trafico por la MPLS.

Y la cosa es que fue así, para el 90% de las conexiones. Sospecho que todas las que se reiniciaron, pero las que estaban iniciadas ya (y fallando) se quedaron tostadas.

Y aún peor, en vez de dar información, el log simplemente ignoraba la regla de la SDwan (que básicamente es un 10.0.0.0/8 to 10.0.0.0/8 any accept) y hacia match en la de la salida a internet (10.0.0.0/8 to any any (con nat)).

Aunque esto apestaba a SDwan, necesitaba que el tráfico funcionara, y mientras los del soporte me decían algo … Cree una regla antes de la de nat para que el tráfico interno hiciese match … algo como 10.0.0.0/8 to 10.0.0.0/8 icmp accept no nat.

Y la cosa empezó a funcionar. Después el soporte aclaró la situación.

Resulta que, cuando comienzas una conexión, esta se crea en la correspondiente tabla (diagnose sys session list). Y, una vez que la conexión esta iniciada, se la sudan los problemas (cosa que no entiendo, joder … si la conexión no se puede establecer por cualquier problema, ¿para que la mantienes abierta?).

Y aún peor … porque lo único que fallaban eran los pings (un test con un ping continuo, contesta hasta que el remoto deja de estar alcanzable, y cuando vuelve a estarlo … ni puto caso).

Bueno, eso … y que no descarta un bug (6.4.5 build 5651).

No me convence la explicación, la verdad … pero bueno, con mi regla al menos la cosa funcionaba.

Se pueden cerrar esas sesiones, es un poco lioso … primero tienes que hacer el filtro para verlas

diagnose sys session filter src x.x.x.x

Y una vez que lo tengas te las cepillas usando

diagnose sys session clear -> OJO, si no pones el filtro antes, te las cargas todas.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-filters-to-clear-sessions-on-a-FortiGate/ta-p/191368?cmd=displayKC&dialogID=48659605&docType=kc&docTypeID=DT_KCARTICLE_1_1&externalId=FD31635&sliceId=1&stateId=0%200%2048661386

En fin … cosas raras, no entiendo porque no añaden mas información a los logs, esto de la SDwan no es nada intuitivo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.