BALANCEO DE SESIONES VPN CON CERTIFICADOS DIGITALES EN ASA

   Este documento describe la práctica preferible y el escenario alternativo para la solución de acceso remoto del ASA-5500 realizando un balanceo de sesiones a través de un clúster y realizando la autenticación a través de certificados digitales.

   Para más información sobre este tipo de balanceo de sesiones VPN (clúster de alta disponibilidad) en ASA se pueden referir a la siguiente guía de configuración (favor de consultar cisco.com para versiones más recientes del documento):

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/vpnsysop.html#wp1048834

   Para más información sobre la configuración de certificados digitales en los equipos ASA, se puede consultar la siguiente guía (favor de consultar cisco.com para versiones más recientes del documento):

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/cert_cfg.html

I. Práctica preferible a través de un certificado unificado de cliente (Unified Client Certificate – UCC)

Pasos generales:

1) Obtener un UCC con múltiples SAN (Subject Alternate Name Extensions) para cada ASA FQDN/IP incluido.

En este sentido se necesita un certificado UCC con el Nombre Común (CN) para el FQDN del clúster y/o la dirección IP del mismo, y SANs para cada ASA que pertenece al clúster. Varios proveedores de certificados digitales PKI tales como Entrust, soportan la estructura UCC, también llamada Certificado SSL Unificado de Clientes con Múltiples Dominios (Unified Client Multi-Domain SSL Certificates).

Nota: El ASA no puede generar un Pedido de Firma de Certificado (CSR – Certificate Signing Request) con múltiples SANs (Esta funcionalidad se solicitó en el documento CSCso70867), por lo que es necesario solicitar al proveedor CA/PKI que él genere el pedido.

2) En el ASA principal se debe configurar un trustpoint apuntando al clúster, los comandos son los siguientes:

crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
enrollment terminal

Después hay que importar el certificado obtenido del proveedor por medio del comando:

crypto ca import certificate

Después de que se ejecuta dicho comando, el ASA solicita que se copie el certificado a la terminal en formato base-64.

3) Como siguiente paso hay que exportar el trustpoint como pkcs12 (esto permite que exporten tanto el certificado como las llaves de encripción)

Crypto ca export asa’cluster pkcs12 <contraseña>


Copiar la salida resultante y salvarla a un archivo de texto.

4) Después hay que importar el archivo pkcs en cada miembro del clúster.

Crypto ca import asa-cluster pkcs12 <contraseña>

5) Habilite SSL en las interfaces necesarias (ssl <interface>) y el comando ssl outside vpnloadbalanced apuntando al trustpoint importado.

6) Iniciar las sesiones de acceso remoto VPN (clientes IPSec, cliente SSL AnyConnect, Client-less SSL) a la IP virtual (VIP) o al FQDN del clúster.

II. Método alterno utilizando Certificados Múltiples (Wildcard Certificates)

1) Este método requiere un total de n+1 direcciones IP y/o DNS-FQDN y un total de n+1 certificados (donde n es el número de ASAs que pertenecen al clúster).

   Los certificados Múltiples no son recomendables comparados con los UCC. El proveedor Entrust da las siguientes dos razones principales:

  • UCC es un método más seguro que los certificados de comodín puesto que los certificados UCC de Entrust especifican exactamente los equipos y dominios que son protegidos.
  • UCC es      más flexible que los certificados de comodín puesto que no se limitan a un      solo dominio

   El siguiente ejemplo muestra cómo se implementa un clúster de 2 ASAs, utilizando 3 direcciones IP/DNS-FQDN y tres certificados (Uno para el clúster y uno para cada ASA miembro del mismo).

Ejemplo de configuración con dos ASA usando certificados múltiples

Dirección IP del cluster de VPN:      10.10.1.1
Dirección IP del ASA1:                10.10.1.2
Dirección IP del ASA2:                10.10.1.3


Configuración de DNS (dominio = company.com):

Equipo:          IP:
asa-cluster        10.10.1.1
asa1               10.10.1.2
asa2               10.10.1.3


Configuración del balanceo de VPN (en todos los ASA del clúster)

vpn load-balancing
redirect-fqdn enable
cluster ip address 10.10.1.1
participate

Resolución de nombre: La opción “redirect-fqdn enable” permite que el ASA redirecciones el tráfico con base en un nombre FQDN en lugar de una dirección IP. Esto requiere que el DNS utilice los registros correctos de dominio e IP y que el ASA sea el encargado de ejecutar la resolución. Todo esto es necesario con el fin de que no aparezcan ventanas de advertencia indicando una incongruencia entre el nombre del clúster y el certificado del ASA al que nos estamos conectando.

   Para probar que la resolución de nombre está trabajando en el ASA, se puede utilizar un ping al FQDN del cluster, y al FQDN de cada miembro. Todos los miembros del cluster ASA deben poder resolver esos nombres para que el re direccionamiento funcione.

   Como solución alternativa, es posible configurar los nombres en el ASA para resolver esos direccionamientos sin la necesidad de un DNS. Ejemplo:

name 10.10.1.1 asa-cluster.example.com
name 10.10.1.2 asa1.example.com              
name 10.10.1.3 asa2.example.com    

   Después de esto, el ASA debe poder resolver asa-cluster.example.com, asa1.example.com, y asa2.example.com. Usted puede probar esto mandando un ping a los 3 direccionamientos. El ICMP puede no trabajar, pero el ASA debe poder darle una dirección IP para cada uno de los nombres. Si no lo hace, hay que revisar la configuración de los ASA, el re direccionamiento de FQDN no puede funcionar correctamente si los equipos no pueden resolver los nombres de manera adecuada.


Configuraciones de trustpoint

1) ASA1


crypto ca trustpoint myca
subject-name CN=asa1.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Como opción se podría utilizar la dirección IP: CN=<asa1 IP>

2) ASA2


crypto ca trustpoint myca
subject-name CN=asa2.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Como opción se podría utilizar la dirección IP: CN=<asa2 IP>

3) Trustpoint para el balanceo de carga, configurado en cualquier ASA y se puede importar al resto de los ASA en el clúster.


crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Como opción se podría utilizar la dirección IP: CN=<asa-cluster IP>

4) Exportar e importar el trustpoint del balanceo a los otros miembros de clúster.

Una vez que se autentica y enrola este trustpoint (los certificados raíz CA e ID están presentes), estos archivos pueden ser exportados a pkcs12 para importarse después a todos los miembro del clúster usando el siguiente procedimiento:


A) Exportar el trustpoint (los certificados y llaves) a un pkcs12 protegido por contraseña.

crypto ca export asa-cluster pkcs12 <contraseña>

Copiar la salida resultante y salvarla a un archivo de texto.


B) Importar el pkcs12 a otros ASA

crypto ca import asa-cluster pkcs12 <contraseña>


Pegar los datos del pkcs12.

Nota: El proceso de la exportación/de la importación emigra solamente los certificados/llaves desde un dispositivo a otro. Cualquier configuración necesaria del trustpoint debe ser realizada manualmente.

NOTA IMPORTANTE: En versiones anteriores a la 8.0(3), no era posible exportar un trustpoint que sólo contenía un certificado ID. Esto generaba problemas puesto que en ASDM el certificado ID y el certificado raíz CA se introdujeron en 2 trustpoints distintos. Esto fue corregido, por lo que si se llega a presentar un problema cuando se importa el certificado del clúster a uno de los miembros del mismo y el proceso indica que fue exitoso pero no se ve ningún certificado, muy probablemente se cometió un error en el procedimiento. Hay que regresar al ASA que generó el CSR para el clúster, autenticar y enrolar el trustpoint una vez más y volver a exportarlo. Refiérase al DDTS CSCsl59266 para más detalles.

n este momento los certificados del ASA-cluster están instalados y se pueden utilizar para identificar correctamente las peticiones SSL que entran en la dirección IP/FQDN principal del clúster.

Configuración de SSL para usar el certificado LB

ssl trust-point myca outside
ssl trust-point asa-cluster outside vpnlb-ip

III. Conexión VPN sin cliente a través de un navegador (Clientless SSL VPN)


Una conexión VPN sin cliente a través de un navegador sigue el siguiente proceso:

1). El cliente accede a https://asa-cluster.company.com y el ASA envía su Certificado ID al cliente.  Nota: Si se habilita la opción de autenticación de certificado del cliente, al cliente remoto se le solicita elegir uno de los certificados disponibles desde una ventana.

  • El emisor del certificado del ASA ya debe ser de confianza para el cliente y por lo tanto no debe generar advertencias.
  • El dominio utilizado (asa-cluster.company.com) está incluido en el certificado del clúster del ASA así que tampoco debe generar advertencia por la discordancia de nombres.


2) El ASA principal del clúster decide al mejor ASA para manejar la conexión (asa2 en este ejemplo) y envía una instrucción de re direccionamiento al cliente.


3) El cliente inicia silenciosamente la nueva conexión a https://asa2.company.com y ASA2 envía su certificado ID al cliente.

  • El emisor del certificado del ASA ya debe ser de confianza para el cliente y por lo tanto no debe generar advertencias.
  • El dominio utilizado (asa2.company.com) está incluido en el certificado del ASA2 así que tampoco debe generar advertencia por la discordancia de nombres.

4) La experiencia del cliente depende de la configuración de autenticación del ASA.

  • Solo AAA.- Indica al cliente a autenticarse en el portal de acceso y/o elegir un grupo (si esta opción está habilitada en la configuración del tunnel-group)
  • Autenticación solo con certificado digital.- El cliente se conecta directamente y ve el portal del webvpn, enlaces, etc. (Si se habilita un alias de grupo en el tunnel-group, se puede elegir un grupo al momento de acceder al sitio).
  • AAA + autenticación con certificado digital.- Se realiza la autenticación del certificado digital, después de esto se solicita información de acceso por AAA y se realiza la conexión. (Si se habilita un alias de grupo en el tunnel-group, se puede elegir un grupo al momento de introducir las claves de AAA).
Historial de versiones
Revisión n.º
1 de 1
Última actualización:
‎07-17-2011 01:36 PM
Actualizado por:
 
Etiquetas (1)
Etiquetas (3)
Comentarios

Muchas gracias por este documento