Ya ha pasado un tiempo desde mi última publicación en la página, sin embargo estamos retomando labores en publicar y seguir trayendoles nuevo contenido sobre soporte de redes, colaboración y en general de TI.
En este post hablaremos de un caso de soporte bastante común entre usuarios del cliente Cisco Anyconnect. Recordemos que este cliente es usado por los Firewalls ASA y los NGFW Firepower de Cisco, el cliente puede ser utilizado tanto en windows, MAC OS, linux, android y Iphone; aunque en algunas ocasiones por politicas internas, las conexiones VPN no se realizan desde la computadora local sino que es necesario conectarse a un servidor remoto para establecer la sesión.
La siguiente imagen describe el escenario anterior:
Bajo este esquema, el servidor windows es administrado por el usuario de RDP, aunque a primera vista no parece un problema para el uso de aplicaciones instaladas en el server, el cliente anyconnect puede detectar qué tipo de usuario esta loggeado en windows para permitir o no conexiones VPN para dicho usuario. Esta característica se encuentra en su archivo profile, el cual es un archivo XML con las configuraciones locales del cliente.
El archivo se encuentra en la dirección: “C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile”
La clave “<WindowsVPNEstablishment>LocalUsersOnly</WindowsVPNEstablishment>” es quien controla que tipo de usuarios se pueden conectar a través del cliente.
Es usual ver el siguiente error en el cliente Anyconnect: “VPN establishment capability for a remote user is disabled. A VPN connection will not be established.” cuando se intenta realizar conexiones VPN con usuario RDP.
Para permitir usuarios remotos es necesario cambiar el valor de esta clave “LocalUsersOnly” por “AllowRemoteUsers”, se recomienda realizar estos cambios con una copia del archivo XML de preferencia con nuevo nombre.
El nuevo archivo XML modificado deberá de subirse al group policy de la VPN remota en el firewall sea ASA o Firepower, ya que de no reemplazar el archivo en el group policy este seguirá descargandose cada vez que se conecte al perfil de VPN, lo que sobre escribirá la configuracion previamente guardada. Aunque existen hacks como el del blog expta que reemplazan el archivo de profile antes del error de conexion de anyconnect.
El cambio del profile en Firepower Management Center se realiza de la siguiente manera:
1- Cargamos el archivo profile XML desde el Object Management de FMC, dirigiendonos a Objects -> Object management -> VPN -> Anyconnect Files
2- Asignamos el profile XML al group policy deseado:
3- Guardamos cambios y desplegamos la configuración. En este punto la VPN remota tomará los cambios y la proxima vez que se realice una conexión VPN los clientes actualizarán su archivo profile local.
Para finalizar, es recomendable desinstalar e instalar nuevamente el cliente para eliminar cualquier archivo basura que haya quedado en windows.
Con esto concluimos el post y no olviden en comentar cualquier duda o sugerencia para nuestro blog, todo comentario constructivo es bienvenido. 🙂 Hasta la proxima!
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.
Cisco 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
Salida 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 sa
Verificar 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
Salida del comando 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
Salida del comando 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-group
La 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 counters
Debugging 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:
Debug Errores en FMC VPN S2S
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:
Tambié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.2
En 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.
Captura de paquetes sobre la interfaz INSIDE
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.
