En esta entrada vamos a ver algunos comandos muy útiles para realizar tareas de troubleshotting en relación a las VPN’s IPSEC de un firewall Fortigate, pero antes de nada deberemos asegurarnos que tenemos configurado una ruta hacía la red destino del túnel y las reglas creadas en nuestro equipo para continuar con las siguientes comprobaciones. Damos por hecho en esta entrada que esta parte ya está configurada.
«¡Vamos al lio!»
El primer comando será para mostrar un resumen de todas las VPN’s IPSEC configuradas en el equipo:
fortigate # get vpn ipsec tunnel summary
'VPN-PRUEBA' IP-DESTINO:4500 selectors(total,up): 1/1 rx(pkt,err): 119330/0 tx(pkt,err): 1052/0En la información mostrada por este comando es importante observar los selectores para comprobar que la VPN IPSEC esté levantada (deben estar con el valor 1). También podemos ver si ha habido tráfico por cada túnel.
A continuación, vamos a analizar la Fase 1 del túnel con el siguiente comando:
fortigate # diagnose vpn ike gateway list name VPN-PRUEBA
vd: root/0
name: VPN-PRUEBA
version: 1
interface: wan1 7
addr: IP-ORIGEN:4500 -> IP-DESTINO:4500
created: 422478s ago
auto-discovery: 0
IKE SA: created 1/7 established 1/7 time 30/2491/9150 ms
IPsec SA: created 1/129 established 1/129 time 10/12/50 ms
id/spi: 4472 493371708fc/ad0864f899ef
direction: responder
status: established 29332-29332s ago = 30msDeberemos prestar atención en el campo «status» de la salida del comando para comprobar que esté funcionando correctamente. Si vemos que aparece «Established» la configuración de la Fase 1 está correcta, si por el contrario observamos «Connecting» deberemos revisar la configuración en ambos extremos del túnel para que sea la misma.
Podemos realizar mas pruebas con un trace:
execute traceroute-options source IP-TUNEL-ORIGEN
execute traceroute IP-TUNEL-DESTINOO también podemos verificar que los puertos 500 y 4500 no estén bloqueados en cualquier otro punto de nuestra red monitorizando el tráfico. Ya vimos en el artículo anterior como esnifar el tráfico en un firewall Fortigate
diagnose sniffer packet any 'host IP-DESTINO and port 4500' 4 0 lSi llegados a este punto todo está correcto pero el túnel sigue sin levantar deberemos revisar la Fase 2 del túnel con el siguiente comando:
fortigate # diagnose vpn tunnel list name VPN-PRUEBA
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=VPN-PRUEBA ver=1 serial=24 IP-ORIGEN:0->IP-DESTINO:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=10 ilast=0 olast=0 ad=/0 itn-status=4c
stat: rxp=119592 txp=1052 rxb=17818724 txb=129040
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=15
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=VPN-PRUEBA proto=0 sa=1 ref=2 serial=5
src: 0:10.0.0.0/255.0.0.0:0
dst: 0:192.168.131.0/255.255.255.0:0En la salida del comando anterior debemos prestar especial atención al campo «sa». Si el valor de este campo es «1» indicará que el túnel IPSEC está establecido y que el tráfico se cursará por la VPN. Por el contrario si aparece el valor «0» significa que la configuración de la Fase 2 no coincide en ambos extremos del túnel y será necesario revisar la configuración por los administradores de red.
Otro comando muy útil sería el siguiente para analizar la comunicación entre los peers, los proposal…
- Para versiones inferiores a 7.4.1:
diagnose debug reset
diagnose vpn ike log-filter dst-addr4 IP-DESTINO
diagnose debug application ike -1
diagnose debug enable- Para versiones superiores a 7.4.1:
diagnose vpn ike log filter rem-addr4 IP-DESTINO
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enablePara deshabilitarlo:
diagnose debug disableEn resumen, con estos comandos podremos verificar el estado del túnel y comprobar si hay algún problema en alguna de las fases del mismo para que podamos solucionarlo lo antes posible.
