Posts etiquetados ‘Troubleshooting’

Si tenéis que hacer troubleshooting de un tráfico rechazado en un Fortigate, podéis sufrir una pequeña pesadilla para saber que está ocurriendo. Resulta que el logado de tráfico en este firewall es un tanto peculiar y puede dar más de un quebradero de cabeza. Funciona así:

Si la regla es de tráfico permitido, sólo quedarán registrado en los ficheros de logs aquellos paquetes permitidos en la regla y que atraviesen correctamente el firewall. Si el paquete es rechazado por cualquier motivo (porque no esté permitido en la regla o se rechace por otro motivo que no se encuentre entre las funcionalidades UTM con log propio) no queda registrado este Reject en ninguna parte y no podemos saber si la regla está mal, si el paquete original no está llegando o si el firewall se lo esta comiendo porque tiene hambre.

Para saber que porras pasa con nuestro paquete, Fortigate dispone de dos comandos que nos facilitarán la vida enormemente: Diagnose Sniffer Packet y Diagnose Debug Flow.

Diagnose Sniffer Packet

Es el equivalente al tcpdump en el universo Fortinet y nos permite visualizar los paquetes registrados a nivel de kernel por cualquiera de las interfaces del firewall o por todas a un tiempo. Se ejecuta desde el CLI con el siguiente formato:

diagnose sniffer packet {interface | all}  ‘net z.z.z.z/p and/or host x.x.x.x and/or port yyy’  [options]

Para realizar una búsqueda más precisa y no ver un montón de lineas a lo Matrix tenemos las opciones:

  • net/prefix : Muestra todo lo existente para una red
  • host : Muestra sólo lo relativo a un host.
  • port: Muestra sólo lo relativo a un puerto concreto
  • and/or: Permite combinar varios de los filtros anteriores.

Las opciones son:

  • 1: Imprime la cabecera de los paquetes
  • 2: Imprime la cabecera y la informacion de capa IP de los paquetes
  • 3: Imprime la cabecera y la informacion desde capa TCP/Ethernet de los paquetes (si está disponible)
  • 4: Imprime la cabecera de los paquetes con el nombre de la interfaz
  • 5: Imprime la cabecera y la informacion de capa IP de los paquetes con el nombre de la interfaz
  • 6: Imprime la cabecera y la informacion desde capa TCP/Ethernet de los paquetes (si está disponible)con el nombre de la interfaz

Ejemplos:

diagnose sniffer packet any ‘net 10.0.0.0/8 and host 172.16.16.14 and port 3389′

diagnose sniffer packet any ‘host 10.4.131.97 and host 172.16.16.14 and port 3389′ 4

Diagnose Debug Flow

Es una herramienta que nos permite ver el camino que sigue un paquete dentro de el Fortigate, las reglas que aplica al mismo, las rutas …

Se ejecuta a través de CLI y os adjunto algunos ejemplos que os permitirá su uso según queráis filtrar las reglas aplicadas a una IP.

# diagnose debug enable
# diagnose debug flow show console enable
show trace messages on console
# diagnose debug flow filter add 10.10.20.30
# diagnose debug flow trace start 100

El resultado es:

id=36871 trace_id=1132 msg=”vd-root received a packet(proto=17, 10.10.20.30:1029->192.168.110.11:161) from internal.”
id=36871 trace_id=1132 msg=”allocate a new session-00012042″
id=36871 trace_id=1132 msg=”find a route: gw-172.20.120.2 via wan1″
id=36871 trace_id=1132 msg=”find SNAT: IP-172.20.120.230, port-54409″
id=36871 trace_id=1132 msg=”Allowed by Policy-5: SNAT”
id=36871 trace_id=1132 msg=”SNAT 10.10.20.30->172.20.120.230:54409″

Creo que la salida es lo suficientemente intuitiva para que la comprendáis fácilmente.

EDIT: Para ver aún más detalle de lo que ocurre en el paquete:

#diag deb flow show function enable 
#diagnose debug flow show iprope enable 
#diagnose debug flow filter daddr 1.1.1.0 1.1.1.255 
#diag deb flow trace start 100 
#diag deb enable

El resultado:

id=20085 trace_id=16 func=print_pkt_detail line=4751 msg=”vd-root received a packet(proto=1, 2.2.2.1:1->1.1.1.4:2048) from port1. type=8, code=0, id=1, seq=1969.”
id=20085 trace_id=16 func=init_ip_session_common line=4902 msg=”allocate a new session-001088ad”
id=20085 trace_id=16 func=iprope_dnat_check line=4645 msg=”in-[port1], out-[]”
id=20085 trace_id=16 func=iprope_dnat_tree_check line=835 msg=”len=0″
id=20085 trace_id=16 func=iprope_dnat_check line=4658 msg=”result: skb_flags-00800000, vid-0, ret-no-match, act-accept, flag-00000000″
id=20085 trace_id=16 func=vf_ip4_route_input line=1587 msg=”Match policy routing: to 1.1.1.4 via ifindex-33″
id=20085 trace_id=16 func=vf_ip4_route_input line=1597 msg=”find a route: flags=00000000 gw-1.1.1.4 via VPNIfaz”
id=20085 trace_id=16 func=iprope_fwd_check line=701 msg=”in-[Interna], out-[VPNIfaz], skb_flags-00800000, vid-0″
id=20085 trace_id=16 func=__iprope_tree_check line=543 msg=”gnum-100004, use addr/intf hash, len=2″
id=20085 trace_id=16 func=__iprope_check_one_policy line=1697 msg=”checked gnum-100004 policy-593, ret-matched, act-accept”
id=20085 trace_id=16 func=__iprope_user_identity_check line=1523 msg=”ret-matched”
id=20085 trace_id=16 func=__iprope_check_one_policy line=1893 msg=”policy-593 is matched, act-accept”
id=20085 trace_id=16 func=iprope_fwd_auth_check line=753 msg=”after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-593″
id=20085 trace_id=16 func=fw_forward_handler line=697 msg=”Allowed by Policy-593:”
id=20085 trace_id=16 func=ipsecdev_hard_start_xmit line=122 msg=”enter IPsec interface-VPNIfaz”
id=20085 trace_id=16 func=esp_output4 line=1149 msg=”IPsec encrypt/auth”
id=20085 trace_id=16 func=ipsec_output_finish line=519 msg=”send to 2.2.2.20 via intf-VPNIfaz”

 

Espero que os sirva!

Saludillos.

Anuncios

Hoy, de hecho ahora mismo, he tenido que realizar la actualización de un cluster de cortafuegos UTM-1 que se encuentra configurado en full ha (o full hihg avaiability) desde su versión R70 a R75. De hecho la versión final es la R75.20 pero no es posible realizarla directamente y hay que dar el paso intermedio a la R75.

Como está siendo un infierno, os describo a continuación los pasos que deben darse, los problemas encontrados y su resolución.

Tenemos un clúster full ha con dos nodos. Fw1 es el nodo activo tanto de firewall como de management y es el que tiene una mayor prioridad y Fw2 es el nodo pasivo de ambos elementos que asumirá los roles sólo en caso de fallo del nodo principal.

Backup de los elementos:

Lo primero que debemos hacer es un backup completo de ambos nodos, así como de la base de datos de políticas en un equipo externo a los mismos. Así, nos curamos en salud y nos ahorramos disgustos.

1)      Backup de la configuración del equipo a través de la administración web de secureplatform. Esto nos guarda los datos básicos de red del equipo. Aseguraos de tener cerradas todas las GUIs de Smartdashboard o fallará.

2)      Exportado de la política en versión R70 – > #$FWDIR/bin/upgrade_tools/upgrade_export <nombredelfichero>

3)      Exportado de la política en versión R75

  • Para ello, descargamos las migration tools correspondientes a R75 del usercenter y las subimos al appliance principal (bien por SCP bien por FTP) a una carpeta temporal. “/var/tmp” es un buen punto.
  • Damos permiso de ejecución a las migration tools: #chmod a+x *
  • Generamos el fichero de políticas: #migrate export <nombrefichero>

Aseguraos de descargar las políticas generadas bien por FTP, bien por SCP.

4)      Ejecutad el verificador de actualización para comprobar que no existen errores a corregir. Este se encuentra en las migration tools. Si da un error, corregidlo antes de empezar.

Bien, hasta ahora, nada fuera de lo normal de cualquier actualización.

Actualización:

Los pasos son:

1)      Realizar un failover del tráfico al nodo secundario:

#cphaprob -d STOP -s problem -t 0 register

Para dar marcha atrás (por si fuera necesario)

# cphaprob -d STOP unregister

Nota: este paso supone un microcorte

2)      Entrar con Smartdashboard en el management secundario. Al entrar nos dirá que el nodo activo es fw1 y que si queremos cambiarlo. Hacemos que el management secundario sea el activo.

3)      Actualizamos el nodo principal, cargando el correspondiente paquete a través de la interfaz de administración web del nodo fw1. Ojo, en este paso, es recomendable realizar un snapshot y una actualización segura. Es más lento pero nos salvaguardará de errores en la actualización, asegurando la marcha atrás.

4)      Accedemos con la consola de dashboard de R75 al nodo fw1. Colocamos el objeto de clúster a versión R75 e instalamos políticas. Recordad desmarcar la opción de “For firewall cluster install on all members” o fallará.

5)      Actualizamos vía web el nodo fw2 con la imagen correspondiente. Al ejecutar un cpstop para actualizar, el tráfico pasará al nodo fw1 con un microcorte.

6)      Una vez sincronizado, abrimos smartdashboard en fw1. Instalamos políticas en ambos nodos.

7)      Abrimos Policy > Management high Availability y pulsamos el botón sincronizar.

Parece fácil y sencillo ¿verdad? Pues nada más lejos de la realidad.

Problemas, problemas, problemas.

Justo después de sincronizar, si refrescamos el estado de ambos cortafuegos, aparece el nodo fw2 como unreachable. Si tratas de comprobar la SIC de este nodo, se indica lo siguiente:

“SIC Status for : Not Communicating Authentication error [error no. 147] ** Check that peer SIC is configured properly and that system date and time on the SmartCenter Server and peer are synchronized.

Tratamos de resetar la SIC de este nodo pero no hay cambios, no se puede conectar.

Si cerramos el smartdashboard, no podremos conectar de nuevo con fw1 apareciendo un error:

“Connection cannot be initiated make sure the server “xx.xx.xx.xx” is up and running and you are defined as a GUI Client”

Si realizamos: # ps aux | grep cpca  el resultado aparecerá como cpca – readonly

Lo que ocurre es que durante la actualización se ha perdido un certificado de CA en el nodo principal fw1 y es por esto por el que no podemos conectar al smartdashboard o al otro nodo.

Para corregirlo ejecutamos en el nodo fw1:

#cd $CPDIR/conf

# cp sic_cert.p12 sic_cert.p12old

#cpca_client revoke_cert -n “CN=cp_mgmt”

#cpca_client create_cert -n “CN=cp_mgmt” -f $CPDIR/conf/sic_cert.p12

#cpstop

#cstart

Esto regenera los certificados y nos permitevolver a conectar al smartdashboard. OJO: ESTO PROVOCA CORTE TOTAL ya que paramos los servicios del nodo que gestiona el tráfico y el cluster no está montado.

Pero, ¿Qué pasa con el nodo secundario? Pues que aún no lo hemos conectado. Para ello:

Ejecutamos en ambos nodos #fw unloadlocal esto vuelve a PROVOCAR CORTE TOTAL  pero es necesario dado que las políticas no nos permiten conectar ambos nodos del cluster puesto que en este momento fw2 no forma parte del cluster. Reestablecemos la SIC e instalamos políticas. En este punto el firewall está operativo.

Sólo nos queda sincronizar ambos management, pero el del nodo 2 no se deja. Pese a que la SIC está establecida y funcionando, la sincronización de managements nos dice que el fw2 está unreachable. Para corregir esto:

#cpstop

#cd $FWDIR/conf/mgha

# rm ./*

#cd ..

#rm applications.C* CPMIL*

#cpstart

Ahora podemos realizar la sincronización y todo vuelve a la normalidad. Ya sólo queda la actualización a R75.20. Que cthulhu nos coja confesados.

Saludillos

Hace unas semanas tuve que que arreglar el desaguisado que había causado un administrador irresponsable. Intentando liberar espacio de disco, tuvo la “genial” idea de mover algunos logs de exchange sin utilizar el procedimiento anteriormente publicado en este blog.

Cuando por fin ampliamos los discos y restauramos los logs (al menos había sido precavido y sólo los había movido) dos de los grupos de almacenamiento de mailbox no levantaban correctamente quedando en estado de error. Al tratar de resincronizar, el error indicaba la falta de un fichero de log cuya numeración no se encontraba entre los existentes.

Lo primero que debemos hacer es ejecutar un comando que nos permitirá conocer el estado real de la replicación de los grupos de almacenamiento. get-storagegroupcopystatus. Estos procedimientos siempre se ejecutan desde la Shell de Exchange.

La salida tendrá el formato:

Name Summary CopyQueue ReplayQueue LastInspectedLogTime
StorageGroup1 Healthy 0 0 6/14/2007 4:42:01 p.m.

Los resultados que nos indican que existen problemas con la base de datos son que en cualquiera de las dos colas aparezca un número distinto a 0 o que en Summary aparezca “error”  Podemos hacer que los datos en ambos nodos coincidan pero para ello tenemos que asegurarnos que la base de datos del nodo principal no está corrupta y que el servicio de correo funciona con normalidad.

Para poder regenerar los datos de forma que se encuentren sincronizados entre ambos nodos el procedimiento que se debe de ejecutar desde el nodo pasivo:

  • Paramos la replicación: Suspend-StorageGroupCopy –id ‘clustermailbox\grupoalmacenamieto’
  • Eliminamos la base de datos del nodo secundario y restauramos desde el nodo 1:Update-storagegroucopy -id ‘clustermailbox\grupoalmacenamieto’ -DeleteExistingFiles
Hay que tener en cuenta que la base de datos almacenada en el nodo pasivo se eliminará durante el procedimiento, por si deseáis realizar antes una copia de seguridad.
Durante la ejecución,
Tras esto, activamos de nuevo la replicación de los grupos de almacenamiento y comprobamos que ya no existe error.