Community Ask Me Anything- Configuración, troubleshooting y mejores prácticas: AnyConnect Remote Access VPN en ASA and FTD

[Cisco Moderador]

-Este tipo de evento era formalmente conocido como Pregunte al Experto-

Esta sesión continua la conversación del reciente evento de Ask Me Anything “Cómo trabajar seguro de forma remota”

En este evento usted podrá preguntar y clarificar sus dudas de las mejores prácticas de configuración y troubleshooting para AnyConnect secure mobility cliente en Cisco Adaptive Security Appliances (ASA) y Firepower Threat Defense (FTD), así como de su integración con otros dispositivos y tecnologías del portafolio de seguridad de Cisco, como ISE y Duo. 

La sesión brinda la oportunidad de aprender y realizar preguntas relacionadas a los distintos aspectos de la implementación de AnyConnect (usando SSL and Ikev2), ncluyendo temas de (pero no limitados a) licencias de emergencia, configuración, deployment y troubleshooting de AnnyConnect, mismas que ayudan a que su organización se encuentre segura y protegida en situaciones críticas.

Haga sus preguntas del lunes 6 al viernes 17 de Abril del 2020.

Detalles de los Expertos

Gustavo Medina es un Systems Sales Engineer en el equipo de ventas de Enterprise Networking. Cuenta con más de 10 años de experiencia en seguridad y redes empresariales. Durante su carrera se ha enfocado en diversas áreas y tareas, desde escalaciones técnicas en l TAC de Cisco, hasta los programas de adopción y la revisión de evaluaciones de las certificaciones de Cisco. Cuenta con las certificaciones de CCNA, CCNP, CCSI y CCIE de seguridad (#51487).

Jason Grudier es un Technical leader en el quipo de VPN en el TAC de Raleigh, USA. Ha trabajado en el grupo de VPN de Cisco en los últimos seis años. Antes de unirse el equipo, trabaja como ingeniero de redes en Labcorp. Se especializa en la configuración y troubleshooting de AnyConnect en todas las plataformas de Cisco, así como en DMVPM, GETVPN, Radius, LDAP y Certificate authentications.

Dinesh Moudgil es un ingeniero High Touch Technical Support (HTTS) en el equipo de seguridad de Bangalore, India. Ha trabajado con diversas tecnologías de seguridad de Cisco por más de 6 años, con un enfoque en Cisco Next Generation Firewalls, Intrusion Prevention Systems, Identity Management and Access Control (AAA) y VPNs. Cuenta con las certificaciones de seguridad de Cisco CCNP, CCDP y CCIE #58881, al igual que con otras externas como Ace, PCNSE y VCP.

Pulkit Saxena es un ingeniero High Touch Technical Support (HTTS) que ha brindado más de 7 años de experiencia en la industria al equipo de seguridad de Cisco. Tiene experiencia en distintos firewalls, soluciones VPNs, AAA y Next Generation IPS, así como en la entrega de diversos entrenamientos. Pulkit cuenta con múltiples certificaciones, ya sea de Cisco o Juniper (como CCIE en Seguridad y JNCIA).

Gustavo, Jason, Dinesh y Pulkit pueden no lograr contestar a todas las dudas en el evento debido al volumen esperado. Para continuar la conversación, visite la categoría de Seguridad.

Al publicar una pregunta en este evento, usted otorga permiso para que su post sea traducido a todos los idiomas de la Comunidad de Cisco.

Encuentre más eventos en: https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=comunidad-espanol

** ¡Los puntos de utilidad fomentan la participación! **
Por favor asegúrese de dar uno a las respuestas a sus preguntas.

[Pulkit Saxena]

Hola Giovanni

Gracias por tus palabras y amabilidad.

¿Puedes compartirnos una captura de pantalla de eso, en donde veamos el nombre de perfil y el nombre de dominio completo al mismo tiempo?

Pulkit

[jgrudier]

Parece que el almacenamiento en caché está habilitado en el archivo preferences.xml. Para estar seguros, si vas a ProgramData/cisco/cisco secure mobility client/profile y abres el archivo profilename.xml que has configurado, envía la parte inferior que comienza con eso. Modifica esta parte porque no es no es bueno tener audiencias en todas partes 😊. Si la dirección del host y el nombre del host no son iguales, cámbialos de tal manera que sean iguales.

secret.cisco.com
secret.cisco.com

Se convertiría
blah.blah.com
blah.blah.com

Entonces sabemos que es el mismo valor. Si son diferentes, simplemente cambia cada uno a algo al azar.

También hay un campo que permite al usuario ingresar a este cuadro. 

true
Si este parámetro se establece en false (falso), los usuarios no podrán cambiar lo que llena el perfil xml.
Si el almacenamiento en caché está habilitado y el usuario ingresa el FQDN, en lugar de seleccionar el nombre de host (HostName) en el perfil xml; en la próxima conexión, mostrará la última conexión y el nombre de host (HostName).
En esta carpeta, verás un archivo preferences.xml donde puedes deshabilitar la caché.
C:\Users\\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client

Finalmente, ¿tiene más de un archivo profile.xml en la carpeta de perfiles?

Si es así, llenarás múltiples entradas en el cuadro de conexión AnyConnect del usuario.

[Cisco Moderador]

Gracias a ambos,

Permítanme intentar proporcionarles más información como lo solicitaron:
Esta es la parte inferior de un perfil XML de ejemplo:

	<ServerList>
		<HostEntry>
			<HostName>COMPANY NAME - CLIENT (COUNTRY)</HostName>
			<HostAddress>https://vpn.company.com</HostAddress>
			<UserGroup>emea_client</UserGroup>
		</HostEntry>
	</ServerList>

Por lo tanto, tenemos un nombre de host (que se muestra como nombre de perfil) diferente de la dirección del host.

La experiencia del usuario es la siguiente:

• Cuando un usuario ya ha iniciado sesión en Windows y selecciona el nombre del perfil e inicia sesión, todo sale según lo planeado

    

• Al usar en su lugar SBL, el trabajador remoto se conectar primero a través de la pantalla SBL, seleccionando el perfil, pero cuando inicia sesión en Windows, el usuario ve el FQDN y no el perfil seleccionado.

Hasta ahora, incluso con este problema visual, el usuario está conectado donde debería estar.

El problema ocurre cuando el usuario cierra sesión y necesita iniciar sesión nuevamente mientras está conectado a Windows. En este caso, el agente verá el nombre de perfil normal con un FQDN que apunta correctamente a nuestro firewall pero que no contiene la URL completa del perfil y, por lo tanto, obviamente no permite ninguna conexión.

En este caso, el error de visualización es un problema porque las personas se confunden si tienen que elegir el nombre de perfil o el FQDN incorrecto que se muestra en la lista de perfiles :)

Espero que esto les brinde toda la información que necesitan sobre nuestra configuración y posibles pistas sobre lo que está sucediendo.

Nota: todas estas capturas de pantalla se eliminaron de nuestra información interna, pero se tomaron de una prueba en vivo que acabo de realizar.

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Gustavo Medina]

Hola chicos,

Parece que se debe a:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp53403

Pueden seguir este blog para este tipo de problemas.

Atentamente,
Gustavo

[Cisco Moderador]

Hola Gustavo

Muchas gracias, parece ser exactamente lo que está sucediendo en nuestro caso.
¿Sabes si hay una versión de AnyConnect sin este problema?

Hasta el momento:

     la versión 4.7.04056 se ve afectada
     la versión 4.8.03036 se ve afectada

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Dinesh Moudgil]

Hola Giovanni

En este punto, el error está en el estado asignado y se espera que se corrija en versiones posteriores.

Gracias,
Dinesh

[Cisco Moderador]

Cómo usar un packet-tracer con RA VPN vpn-filter

Suponga que 10.10.10.10 es la dirección VPN y que la dirección interna es 192.168.10.3

     ¿Cuál debería ser la sintaxis de packet-tracer?
     ¿La entrada externa del packet-tracer corresponderá a la lista de acceso a la interfaz externa?

Atentamente,
Viral Patel

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por patelvc7601. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Gustavo Medina]

Hola patelvc7601

Después de 9.9(1), agregamos la opción descifrada al paquete de seguimiento, también es posible simular un paquete que pasa a través de un túnel VPN. El paquete "descifrado" (decrypted) simulado se compararía con un túnel VPN existente y se aplicarían las políticas de túnel asociadas.

Para su ejemplo, la sintaxis sería:

packet-tracer input outside tcp 10.10.10.10 5050 192.168.10.3 decrypted

El túnel debe establecerse cuando ejecute el comando anterior, de lo contrario recibirá una advertencia.

Atentamente,
Gustavo

[Cisco Moderador]

Buenos días de nuevo,

De antemano una disculpa por hacerles una pregunta que tiene referencias cruzadas con Cisco ISE.

En el caso de que necesitemos restringir los usuarios de acceso remoto según el país de origen, entiendo que:

• Firepower tiene un flujo de geolocalización y puede crear reglas ACP basadas en ellas, pero no para el tráfico que termina en el firewall (como lo es RA VPN).
• El uso de Cisco ISE como autenticación primaria RADIUS puede usar el atributo Tunnel-Client-Endpoint en las reglas de autenticación/autorización, que proporcionarían la IP pública utilizada por un cliente que se conecta.
• Cisco ISE no tiene flujo de datos de geolocalización que yo sepa.

Con base en estas consideraciones, pensé que más tarde buscaría exportar la lista de direcciones IP de geolocalización Firepower y crear objetos de condición en Cisco ISE (a través de la API REST), luego coincidiría si Tunnel-Client-Endpoint vuelve a caer en el objeto de país específico autorizado para el acceso.

Ahora, esto nos permite plantearnos las siguientes preguntas:

1. ¿Se pueden exportar los datos de geolocalización IP a través de la API REST desde FMC?
2. ¿Es posible de alguna manera crear una condición en ISE para que una IP esté en una de las subredes listadas en un objeto? (No lo creo)
3. ¿Existen tales funcionalidades en ISE o Firepower en la hoja de ruta?

¡Les agradezco!

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Dinesh Moudgil]

Hola Giovanni

1) Puedes obtener la información de mapeo de los archivos "ipv4_country_code_map" y "ipv6_country_code_map" ubicados en el siguiente directorio "/var/sf/geodb" en el FMC

root@fmcv66:/var/sf/geodb# cat ipv4_country_code_map
y
root@fmcv66:/var/sf/geodb# cat ipv6_country_code_map

El resultado se genera con direcciones IP y códigos de país asociados. Encontrarás más información sobre los códigos de país en https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes

Si deseas conocer el código del país de FMC, puedes ejecutar este comando perl en el FMC como root:

root@fmcv66:/var/sf/geodb# perl -MFlyLoader -e 'my $t="country_code_continent_code_map";my @c=("country_name","country_code");my $n=0;my $s="*"x20;foreach my $row (@{SF::SFDBI::connect()->selectall_arrayref("SELECT ".join(",", @c)." from $t WHERE country_code=242")}){print "$s ".++$n.". $s\n";my $i=0; foreach (@{$row}){printf "%9s: %s\n",@c[$i++],$_}}'
******************** 1. ********************
country_name: fiji
country_code: 242
root@fmcv66:/var/sf/geodb#

También tenemos la siguiente API para recuperar objetos de geolocalización:

GET geolocation
Request Type: GET

Descripción: recupera el objeto de geolocalización asociado con la ID especificada. Si no se especifica ninguna ID, recupera la lista de todos los objetos de geolocalización.

URL: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations
URL para GET por ID: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations/{object_UUID}

Para 2) y 3)

De ninguna manera soy un experto en ISE, pero generalmente se realiza una verificación basada en una condición como un atributo o grupo de identidad en lugar de una lista. No creo que esto sea compatible por el momento, pero si hay un cambio de información, actualizaré el hilo.

Atentamente,
Dinesh Moudgil

[Cisco Moderador]

Gracias Dinesh

Agradezco tu apoyo, me mantendré atento a su actualización.

Esto puede resolver un gran problema por el momento, he visto proveedores de autenticación de terceros enviar una condición de falla basada en la geolocalización, pero tal como está, no todas las soluciones de acceso remoto pueden ser autenticadas para estos proveedores, por lo que sería apropiado tenerlos fuera de la caja para Firepower o ISE.

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Cisco Moderador]

giovanni.augusto

Toma en cuenta que si estás utilizando Duo MFA (que es compatible con la VPN de acceso remoto basada en FTD) y tienen el plan Access or Beyond, pueden aplicar las políticas de Duo en función de la geolocalización del usuario. Por ejemplo, pueden restringir el acceso desde fuera de su país. También pueden hacerlo más granular, por ejemplo, impedirlo en general y eximir a ciertos usuarios que viajan o que se encuentren en el extranjero.

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por Marvin Rhoads. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Cisco Moderador]

Gracias Marvin

¿Funcionaría al usar DUO proxy con ISE, o funcionaría con DUO con la autenticación SAML directamente desde el FTD?

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.

[Gustavo Medina]

Hola chicos,

ISE no proporciona dicho servicio de forma nativa, pero puede integrarse con un MSM (Meraki Systems Manager debería funcionar) para proporcionar este servicio. Desde el propio FTD, se puede configurar un plano de control ACL para inhabilitar bloques no deseados. Como bien lo señala Dinesh Moudgil, esta información se puede obtenerde de FMC, del paquete geográfico en cisco.com, a partir de una fuente externa o usando ANSIBLE lo yo que personalmente preferiría:
https://developer.cisco.com/site/ftd-ansible/#!country/country

Ciertamente, de las opciones que menciona Marvin Rhoads, la opción DUO sería mi método preferido. Pueden hacer esto con el DUO proxy como se muestra aquí:
https://duo.com/docs/ciscoise-radius
https://duo.com/docs/cisco#cisco-ise-using-radius

Pero también es posible con SAML, no demasiado documentado, pero este video te explica todo:
https://youtu.be/W6bE2GTU0Is

Encantado de poder asistirles.
Gustavo

https://youtu.be/W6bE2GTU0Is

[Cisco Moderador]

Dinesh Moudgil, Gustavo Medina y Marvin Rhoads,
Gracias por sus sugerencias.

Marvin Rhoads: Exploraré la opción DUO tan pronto como tenga tiempo libre (!) Y posiblemente haré que funcione en paralelo con otro proveedor de SFI que utilizamos. ¿Sabes si la geolocalización funciona con la licencia gratuita para pruebas?

Gustavo Medina y Dinesh Moudgil: Me gustan todas las opciones sugeridas, la más inmediata para mí ahora parece usar un plano de control ACL en FTD con geolocalización y tengo algunas preguntas sobre esta opción:

1. ¿Se puede usar el plano de control ACL a través de flexconfig? Hasta donde yo sé han habido problemas en el pasado, supongo que se estos se han resuelto y que Cisco admite dicha configuración.
2. En el caso del plano de control ACL en FTD, ¿puedo usar directamente el objeto de geolocalización "SI" o tengo que crear y actualizar un objeto "LINA" para usarlo con flexconfig?
3. Con este escenario, ¿puedo aplicar esta ACL a un solo grupo de túneles? Hasta donde yo sé, esto se aplicará a todos los accesos remotos entrantes para este firewall, entonces, ¿eso significa que restringiríamos el acceso a cualquiera que se conecte a él o no?
4. Si la opción 3 es un sí (restricción para todos los usuarios que se conectan a un FW), ¿sería útil la nueva función VRF-lite de FTD 6.6 para crear múltiples interfaces y conectar el plano de control ACL a ese "restricted outside" específico?

Al escribir estas preguntas, vuelvo a plantearme si el plano de control de ACL parece menos evolutivo que la geolocalización en términos de autenticación, pero me gustaría tener su opinión sobre este tema.

Gracias

Nota: Esta pregunta es una traducción de un post originalmente generado en inglés por giovanni.augusto. Ha sido traducida por la Comunidad de Cisco para compartir la duda y solución en distintos idiomas.