Manual para IpSec (Fortinet)

🧠 Manual con Propósito – Diagnóstico de Servicio IPsec en FortiGate [Editar]

🎯 Objetivo general:
Identificar con precisión en qué punto está fallando un servicio corporativo que depende de un túnel IPsec.

🧩 Estrategia:
Validar desde la capa física hasta el tráfico encriptado, siguiendo una lógica de diagnóstico causa-efecto en cada fase.

---

🔁 Fase 1 – Validación del Servicio de Internet [Editar]

1️⃣ Configuración de Interfaces WAN, LAN y Túneles

Objetivo: Verificar que las interfaces estén correctamente configuradas con sus respectivas IPs, roles y permisos de acceso. Validar si existe conectividad saliente o entrada desde las redes LAN, WAN o túneles.

Comando: show system interface

[... contenido omitido por longitud, se deja completo en Moodle ...]

¿Qué validamos aquí?

  • 🟢 Que la interfaz WAN tenga IP pública correctamente asignada (ej. 10.103.24.51).
  • 🟢 Que la interfaz LAN esté activa y tenga direcciones secundarias si hay servicios configurados con NAT.
  • 🟢 Que existan interfaces de túnel si se usa IPsec (como naf.root, ssl.root, TO_CENTRAL).
---

2️⃣ Validación del IP Pool – IP Pública Asignada

Objetivo: Confirmar que la IP pública esté correctamente definida en el IP Pool para NAT.

Comando: show firewall ippool

config firewall ippool
    edit "NAT"
        set startip 181.209.206.9
        set endip 181.209.206.9
    next
end

¿Qué validamos aquí?

  • ✅ Que la IP pública está correctamente declarada para NAT.
  • ✅ Que está disponible para ser utilizada en políticas de salida o túneles.
---

3️⃣ Validación de ARP – Equipos LAN Asociados

Objetivo: Verificar si hay equipos activos y asociados por MAC en la red LAN y WAN.

Comando: get system arp

Address             Age(min)    Hardware Addr           Interface
192.168.42.211    0              4a:cd:f2:c6:8b:de           lan
10.103.24.33               0              b4:43:26:00:dd:e5           wan
...

¿Qué validamos aquí?

  • 🔎 Que hay equipos LAN activos respondiendo al gateway del FortiGate.
  • 🔎 Que hay resolución ARP hacia la red WAN o hacia el proveedor.
---

4️⃣ Prueba de Conectividad hacia Internet

Objetivo: Verificar si el FortiGate puede salir a Internet usando la IP pública declarada en el IP Pool.

Comando: execute ping-options source 181.209.206.9
Comando: execute ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=26.6 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=26.5 ms
...
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

¿Qué validamos aquí?

  • 🌐 Que el FortiGate tiene salida a Internet real desde su IP pública.
  • ⚙️ Que no hay problemas con el enrutamiento, NAT o ACLs de salida.
---

📌 Conclusión de la Fase 1

Con esta validación inicial aseguramos que el FortiGate está correctamente configurado a nivel de interfaces, NAT y conectividad externa. Si falla la salida a Internet o el túnel IPsec, este es el primer paso a revisar antes de pasar a la validación de Fase 2 (VPN IPsec).

🔐 Fase 2 – Validación del Túnel IPsec (FortiGate) [Editar]

4️⃣ Verificar estado del túnel (CLI y GUI)

Comandos:

get ipsec tunnel list
get vpn ipsec tunnel summary

NAME=TO_CENTRAL REMOTE-GW=181.209.206.37:0
    P2NAME=TO_CENTRAL PROXY-ID-SOURCE=192.168.42.0/255.255.255.0 PROXY-ID-DESTINATION=192.168.3.0/255.255.255.0 STATUS=up TIMEOUT=24430

'TO_CENTRAL' 181.209.206.37:0 selectors(total,up): 1/1 rx(pkt,err): 11669491/0 tx(pkt,err): 13845725/17

¿Para qué sirve? Comprueba si el túnel está UP. Confirma que las fases 1 y 2 están activas y que el tráfico está fluyendo correctamente.

  • ✅ Verifica tráfico recibido/enviado y errores.
  • ✅ Confirma la negociación de subredes (selectors).

Fallos comunes:

  • PSK incorrecta
  • IP remota errónea o caída
  • Falta de políticas o rutas

5️⃣ Revisar configuración de Fase 1 (IKE)

show vpn ipsec phase1-interface

edit "TO_CENTRAL"
    set interface "wan"
    set local-gw 181.209.206.9
    set remote-gw 181.209.206.37
    set peertype any
    set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
    set psksecret ENC <clave_encriptada>
next

¿Para qué sirve? Define los parámetros de seguridad entre IPs públicas. Es la fase base de todo túnel IPsec.

  • ✅ Cifrado, autenticación y clave compartida (PSK)
  • ✅ IP pública remota para pruebas directas

Errores comunes:

  • Diferencias de algoritmos
  • Clave PSK mal configurada
  • IP pública mal escrita

6️⃣ Revisar configuración de Fase 2 (IPsec SA)

show vpn ipsec phase2-interface

edit "TO_CENTRAL"
    set phase1name "TO_CENTRAL"
    set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256
    set src-name "TO_CENTRAL_local"
    set dst-name "To_Central_Remote"
next

¿Para qué sirve? Define las subredes que pueden cruzar el túnel. Aunque el túnel esté UP, sin esta configuración correcta no habrá tráfico.

Errores comunes:

  • Subredes mal declaradas
  • Errores de máscara (/24, /16)
  • Configuración incompleta en uno de los extremos

7️⃣ Validar rutas hacia red remota

get router info routing-table details 192.168.3.1

Routing entry for 192.168.3.0/24
    Known via "static", distance 254, metric 0
        directly connected, Null

Routing entry for 192.168.3.0/24
    Known via "static", distance 10, metric 0, best
    * via TO_CENTRAL tunnel 181.209.206.37

¿Para qué sirve? Permite validar el enrutamiento hacia la red remota.

  • La ruta Null actúa como blackhole para evitar loops.
  • La ruta TO_CENTRAL es la activa y usada si el túnel está UP.

Errores comunes:

  • Ruta ausente o con destino incorrecto
  • Ruta saliendo por WAN en lugar del túnel
  • Falta de blackhole (riesgo de loop)

8️⃣ Revisar políticas del firewall

show firewall policy

edit 4
    set name "vpn_TO_CENTRAL_local"
    set srcintf "lan"
    set dstintf "TO_CENTRAL"
    set srcaddr "TO_CENTRAL_local"
    set dstaddr "To_Central_Remote"
    set action accept
    set schedule "always"
    set service "ALL"
next

edit 5
    set name "vpn_TO_CENTRAL_remote"
    set srcintf "TO_CENTRAL"
    set dstintf "lan"
    set srcaddr "To_Central_Remote"
    set dstaddr "TO_CENTRAL_local"
    set action accept
    set schedule "always"
    set service "ALL"
next

¿Para qué sirve? Las políticas determinan si el tráfico puede cruzar el túnel. Aunque la VPN esté activa, sin políticas adecuadas, el tráfico será bloqueado.

Errores comunes:

  • Políticas mal ordenadas (no se ejecutan)
  • Falta de política de retorno
  • NAT activado por error

📌 Recomendación final:

Asegúrate de que las siguientes condiciones se cumplan:

  • 🔒 Claves y algoritmos coinciden en ambos extremos (Fase 1)
  • 🌐 Subredes correctamente definidas (Fase 2)
  • 🛣️ Rutas activas hacia red remota (Routing Table)
  • 🧱 Políticas simétricas y sin NAT

🌐 Fase 3 – Validación Remota y de Tráfico [Editar]

9️⃣ Ping a la IP Pública del Otro Extremo

execute ping 181.209.206.9

PING 181.209.206.9 (181.209.206.9): 56 data bytes
64 bytes from 181.209.206.9: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 181.209.206.9: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 181.209.206.9: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 181.209.206.9: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 181.209.206.9: icmp_seq=4 ttl=255 time=0.1 ms

--- 181.209.206.9 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.1/0.2 ms

¿Para qué sirve? Verifica que la IP pública remota esté activa y respondiendo. Es un indicador rápido de conectividad básica.

Fallos detectables:

  • IP remota apagada o fuera de servicio
  • Error al digitar la IP
  • El firewall remoto bloquea ICMP

🔟 Ping LAN a LAN (cruzando el túnel)

execute ping-options source 192.168.42.1
execute ping-options repeat-count 500
execute ping-options data-size 1500
execute ping-options adaptive-ping enable
execute ping 192.168.3.1

PING 192.168.3.1 (192.168.3.1): 1500 data bytes
1508 bytes from 192.168.3.1: icmp_seq=0 ttl=255 time=2.1 ms
1508 bytes from 192.168.3.1: icmp_seq=497 ttl=255 time=1.7 ms
1508 bytes from 192.168.3.1: icmp_seq=498 ttl=255 time=1.7 ms
1508 bytes from 192.168.3.1: icmp_seq=499 ttl=255 time=1.7 ms

--- 192.168.3.1 ping statistics ---
500 packets transmitted, 500 packets received, 0% packet loss
round-trip min/avg/max = 0.8/1.7/8.9 ms

¿Para qué sirve? Esta es la prueba más crítica. Confirma que el túnel transporta tráfico entre LANs. Las opciones simulan tráfico real (alto volumen y tamaño completo).

Fallos detectables:

  • Subred remota no publicada en Fase 2
  • Falta de política de retorno en peer
  • El host remoto está apagado

🧪 Fase 4 – Pruebas Avanzadas [Editar]

1️⃣1️⃣ Revisión de logs del túnel

diagnose debug application ike -1
diagnose debug enable

¿Para qué sirve? Muestra los mensajes de negociación IKE en tiempo real. Ideal para ver por qué falla la Fase 1 o la Fase 2.

Fallos detectables:

  • No proposal chosen – Algoritmos incompatibles
  • IKE negotiation failed – IP o PSK incorrecta
  • Tráfico denegado por políticas

1️⃣2️⃣ Traceroute entre LANs

execute traceroute 192.168.3.1

¿Para qué sirve? Muestra la ruta del tráfico. Si el primer salto es la IP remota LAN, el túnel está funcionando como debe.

Fallos detectables:

  • Tráfico saliendo por Internet (mala ruta)
  • Loops por rutas estáticas incorrectas
  • Pérdida en los primeros saltos

1️⃣3️⃣ Sniffer o captura de paquetes

diagnose sniffer packet any 'host 192.168.3.1' 4

# O para tráfico IPsec:
diagnose sniffer packet any 'port 500 or port 4500' 4

¿Para qué sirve? Permite ver si los paquetes están saliendo o entrando por el túnel. Se usa cuando el ping falla pero el túnel está UP.

Fallos detectables:

  • Paquetes enviados sin respuesta
  • Tráfico encapsulado pero no decapsulado
  • Ningún paquete por interfaz IPsec