Cisco FTD: Troubleshooting S2S VPN – Verificar VPN S2S
En seguridad de redes los túneles VPN sitio-a-sitio son de los enlaces más frecuentes con los que un administrador de redes se topará. Estos tienen la capacidad de encriptar todo el trafico que pasa a través de ellos añadiendo asi una capa de seguridad extra a la comunicación. Hoy en dia se da por hecho que un equipo perimetral como los firewalls debe contar con la capacidad de establecer estos túneles sin impactar el rendimiento de sus demas funciones.
Read more: Cisco FTD: Troubleshooting S2S VPN – Verificar VPN S2SCisco Firepower Threat Defense es la nueva serie de Firewalls de siguiente generación lanzados por Cisco a partir de su adquisicion de SourceFire propietarios de los firewalls Firepower en el 2013. Desde entonces la plataforma Firepower ha ido evolucionando y desarrollandose a partir de una fucion entre los equipos de la generación pasada Cisco Adaptative Security Apliance (ASA) y los nuevos Firepower.
La función resultó en equipos con planos de control y datos administrados por el motor LINA (ASA) es decir las características de capa 1-4 son como lo fueron en los Cisco ASAs; mientras tanto, características en capa de aplicación como: IPS, IDS, URL filtering, Anti Malware etc son orquestadas por el motor SNORT de Firepower.
Con el panorama anterior nos podemos hacer una idea que el manejo de las VPN sitio a sitio recae sobre el motor LINA, es decir que si venimos de administrar Cisco ASA podremos correr y verificar VPN S2S en Firepower tal como si lo hicieramos en ASA. En la siguiente lista podremos encontrar los comandos básicos para la verificación y el troubleshooting de VPN sitio a sitio en Cisco Firepower:
Verificar Security Associations – Fase 1
>system support diagnostic-cli
FTD#show crypto isakmp sa
En este ejemplo podemos ver 2 túneles Sitio a Sitio, 1 IKEV1 y 1 IKEV2, hemos ocultado la informacion sensible de la salida del comando, pero podemos apreciar para la sección de IKEv1 la cantidad de Security Associations creados (Active SA), el estado en el que se encuentra (MM_ACTIVE), el role del equipo (initiator). Para el caso de IKEv2 nos muestra el estado de la sesión 56 (Session-id 56), el tipo de encriptación del túnel, el estado (UP-ACTIVE), la cantidad de tunnel selector creados para este caso 2 (CHILD count) y el role del equipo (RESPONDER). Como información adicional en IKEv2 podemos ver las redes remotas y locales que son encriptadas por el túnel. Se puede decir que la información mostrada es de Fase 1 de negociación entre los peers.
En caso de solo necesitar la información de tuneles IKEv1 o IKEv2 se pueden ejecutar los siguientes comandos:
FTD#show crypto ikev1 sa
FTD#show crypto ikev2 saVerificar los tuneles IPSec creados – Fase 2
Para esta fase la negociación entre los peers consiste de esquemas de encriptación de los paquetes utilizando IPSec (transform set) para ello IPsec se apoya del encapsulamiento en ESP (Encapsulating Security Payload) por ello podemos ver estadísticas generales de todos los túneles creados con el comando ipsec stats:
FTD#show crypto ipsec stats
Como se puede apreciar, nos arroja estadísticas de salida y entrada de paquetes comprimidos, encriptados, fragmentados. Más a detalle nos muestra las solicitudes de eliminación de security associations (Inbound SA delete requests, Outbound SA delete request).
Otro comando útil para verificar los túneles es ipsec sa, el cual nos muestra estadísticas de encapsulamiento IPSec en cada traffic selector (redes intersantes) de la VPN, como por ejemplo:
FTD#show crypto ipsec sa
De esta salida podemos identificar un traffic selector para las redes: 10.1.1.0/24 a la red 10.10.242.0/24, su access-list es creada al momento de configurar la VPN a través del FMC, se logra apreciar los peers en ambos extremos del túnel al lado del puerto que se consume (UDP 4500). Un punto muy importante a tener en cuenta son la cantidad de paquetes que se encapsulan, encriptan y se desencriptan por el túnel, esto nos da una idea si esta pasando tráfico a través del mismo. Como pueden apreciar es uno de los comando mas informativos a cerca de la conexión entre los equipos.
A este comando se le puede especificar que peer queremos verificar al ingresa la dirección IPv4 del peer de la siguiente forma:
FTD#show crypto ipsec sa peer <Hostname or A.B.C.D>Verificar la configuracion de los túneles en el running-config
El siguiente comando funciona perfecto cuando requerimos vericar la configuración realizada, de esta manera nos podemos enterar si se nos escapó algún comando:
FTD#show running-config tunnel-groupLa salida de este comando nos muestra los atributos configurados para el túnel, en especial el tipo de autenticación del túnel que en muchos casos es por Pre-shared Key.
Reiniciar tunnel VPN S2S
En caso de querer forzar un túnel a realizar nuevamente la negociación entre los peers desde Fase 1 el comando utilizado es el siguiente:
FTD#clear crypto ikev1 sa <IP-adrress>
FTD#clear crypto ikev2 sa <IP-adrress>Para reiniciar un tunel en Fase 2 el comando utilizado es:
FTD#clear crypto ipsec sa peer <IP-address>Si lo que queremos es limpiar las estadísticas de fase 2 el siguiente comando bastara para reiniciar los contadores:
FTD#clear crypto ipsec sa countersDebugging de problemas
Como mencionaba con anterioridad, las funciones de VPN en los firepower los maneja el motor LINA quiere que los comandos de debugging de los ASA también son válidos en FTD, sin embargo, a pesar que se puedan utilzar y arrojen información útil para el troubleshooting de algún evento, aun no contiene toda la información deseada como lo podemos ver en un ASA, por lo que desde mi punto de vista, el debugging de VPN se debe completar con la GUI a través de la siguiente ventan:
Será en esta ventana donde podamos observar los errores al momento de establecer una VPN S2S o incluso VPN remota. De igual forma dejo por acá los comandos de debugs:
debug crypto ikev2 platform 127
debug crypto ikev2 protocol 127
debug crypto ikev1 127También se puede intentar crear una captura con packet tracer desde la interfaz inside hacia la outside y revisar si el tráfico que pasa a través de la VPN no esta siendo bloqueado por algun otro componente del FTD:
FTD#cap test include-decrypted trace trace-count 100 interface INSIDE match ip host 1.1.1.1 host 2.2.2.2En este ejemplo el trafico interesante de nuestra red local es 1.1.1.1 y de la red remota 2.2.2.2, le decimos que incluya los paquetes desencriptados y corremos la captura.
Con los comandos:
#show cap
#show cap test trace packet-number 1 <-- Verificamos el procesamiento del paquete 1 cuando pasa por los filtros del FTD (traza)En conclusión, nos podemos apoyar de las erramientas que disponiamos de los equipos de previa generación para realizar el troubleshooting adecuado a nuestros enlaces VPN. Espero que les haya gustado mi pequeño tutorial sobre verificación de VPN Site-to-site nos vemos en el proximo blog. Saludes troubleshooters! :D.
