enlace con servidor por medio de fortiview

[Kevin_09x]

El servidor de apliaciones 192.168.0.20 debe tener salida total a internet para funcionar correctamente. El 28 de febrero el servidor dejo de tener acceso a internet. Por lo que los Equipos de Redes, Soporte Tecnico y Arquitectura han validado los siguientes escenarios:

• Redes ha validado que las reglas del Firewall no estan bloqueando el servicio. Incluso ven trafico en la reglas.
• Soporte Tecnico ha validado que la interfaz de red tenga los datos correctos (IP, mascara de red, puerta de enlance, y DNS).
• Arquitectura nota que cuando lanza un ping a google.com desde el servidor este no resuelve la IP.
• Redes observa que en el Fortiview tiene trafico de salida a internet pero no de regreso.
• Arquitectura y Redes deciden cambiar la ip del Servidor por la 192.168.0.21 y notan que el servidor empieza a tener salida a internet normalmente, sin embargo no se puede cambiar la ip del servidor a ser productivo.

el problema no se ha solucionado.

[Markus_M]

Hi Kevin,

translating to English here - a server lost internet connectivity.

You should test with generating traffic from the server and see on firewall what happens to it.

ICMP or a static IP-website will do nicely.

On FortiGate CLI you can run for icmp:

diag sniff packet any 'icmp' 4 0 a

or for the static IP webserver (for example https://fnac-updates.fortinet.net/ resolves to 67.217.100.26)

diag sniff packet any 'host 67.217.100.26' 4 0 a

You will see the packets going in on some port and packets going out on another port. That should be as expected. You should in case of HTTPS also see a TCP handshake plain text in the sniffer and see if you get any response. If there is no response to a packet that goes through the FortiGate on the correct interfaces, don't search on this FortiGate (but behind it).

If the packets travel to unexpected interfaces, you might have a routing issue.

If the packets do not go out at all, you have no matching firewall policy. This also might be a routing issue.

This can be seen with tracing the packet and the routing decision:

diag debug console timestamp enable

diag debug flow filter addr 67.217.100.26

diag debug flow show iprope enable

diag debug enable

diag debug flow trace start 20 (and then generate traffic).

Best regards,

Markus