Interoperabilidad entre AnyConnect y OpenDNS Roaming Client

Introducción

Este documento describe algunas de las limitaciones actuales y soluciones alternativas disponibles para hacer que AnyConnect y OpenDNS Roaming Client funcionen juntos. Los clientes de Cisco confían en el cliente VPN AnyConnect para disfrutar de una comunicación segura y cifrada con sus redes corporativas. Del mismo modo, el cliente de roaming de OpenDNS ofrece a los usuarios la capacidad de utilizar servicios DNS de forma segura con la ayuda de servidores públicos de OpenDNS. Ambos clientes añaden un completo conjunto de funciones de seguridad en el terminal y, por lo tanto, es importante que interoperen entre sí.

Prerequisites

Conocimientos prácticos del cliente de roaming de AnyConnect y OpenDNS.

Familiaridad con la configuración de cabecera de ASA o IOS/IOS-XE (grupo de túnel/política de grupo) para AnyConnect VPN.

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cabecera ASA o IOS/IOS-XE
• Terminal que ejecuta AnyConnect VPN Client y OpenDNS Roaming Client

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• ASA headend running release 9.4
• Windows 7
• Cliente AnyConnect 4.2.00096
• Cliente de roaming OpenDNS 2.0.154

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). If your network is live, make sure that you understand the potential impact of any command.

Antecedentes

OpenDNS está desarrollando un complemento de AnyConnect con el equipo de Cisco AnyConnect para que esté disponible en el futuro. Aunque no se han establecido fechas, esta integración permitirá al cliente de roaming trabajar con el cliente AnyConnect sin las soluciones alternativas abordadas. Esto también permitirá que AnyConnect sea un mecanismo de entrega para el cliente de roaming. 

Funcionalidad

Gestión de DNS de AnyConnect

La cabecera VPN se puede configurar de un par de maneras diferentes para manejar el tráfico desde el cliente AnyConnect.

1. Configuración completa del túnel (tunnel-all): fuerza el envío de todo el tráfico desde el terminal a través del túnel VPN cifrado y, por lo tanto, el tráfico nunca deja el adaptador de interfaz pública en texto sin cifrar
2. Configuración del túnel dividido:

a. Tunelización dividida-incluida: el tráfico destinado solamente a subredes o hosts específicos definidos en la cabecera VPN se envía a través del túnel, el resto del tráfico se envía fuera del túnel en texto claro

b. Tunelización dividida-excluida: el tráfico destinado solo a subredes o hosts específicos definidos en la cabecera VPN se excluye del cifrado y deja la interfaz pública en texto no cifrado, el resto del tráfico se cifra y solo se envía a través del túnel

Cada una de estas configuraciones determina cómo el cliente AnyConnect gestiona la resolución DNS, en función del sistema operativo del terminal. Se ha producido un cambio en el comportamiento del mecanismo de control de DNS en AnyConnect para Windows, en la versión 4.2 después de la corrección para CSCuf07885.

Windows 7+

Configuración de túnel completo (y túnel dividido con DNS de túnel completo habilitado)

Antes de AnyConnect 4.2:

Sólo se permiten las solicitudes DNS a servidores DNS configurados en la directiva de grupo (servidores DNS de túnel). El controlador de AnyConnect responde a todas las demás solicitudes con una respuesta de "no existe tal nombre". Como resultado, la resolución de DNS solo se puede realizar mediante los servidores DNS de túnel.

AnyConnect 4.2+

Se permiten las solicitudes DNS a cualquier servidor DNS, siempre que se originen desde el adaptador VPN y se envíen a través del túnel. El resto de las solicitudes se responden con una respuesta de "no existe ese nombre" y la resolución de DNS solo se puede realizar a través del túnel VPN

Antes de la corrección de CSCuf07885, AC restringía los servidores DNS de destino; sin embargo, con la corrección de CSCuf07885 , restringía qué adaptadores de red pueden iniciar solicitudes DNS.

Configuración de split-include (DNS de túnel completo deshabilitado y sin split-DNS)

El controlador de AnyConnect no interfiere con la resolución DNS nativa. Por lo tanto, la resolución de DNS se realiza en función del orden de los adaptadores de red, y AnyConnect es siempre el adaptador preferido cuando se conecta VPN. Por lo tanto, una consulta de DNS se enviará primero a través del túnel y, si no se resuelve, la resolución intentará resolverla a través de la interfaz pública. La lista de acceso split-include tendrá que incluir la subred que cubre los servidores DNS del túnel. A partir de AnyConnect 4.2, las rutas de host para los servidores DNS del túnel se agregan automáticamente como redes de inclusión dividida (rutas seguras) mediante el cliente AnyConnect y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.

Configuración de exclusión dividida (DNS de túnel completo deshabilitado y sin DNS dividido)

El controlador de AnyConnect no interfiere con la resolución DNS nativa. Por lo tanto, la resolución de DNS se realiza en función del orden de los adaptadores de red, y AnyConnect es siempre el adaptador preferido cuando se conecta VPN. Por lo tanto, una consulta de DNS se enviará primero a través del túnel y, si no se resuelve, la resolución intentará resolverla a través de la interfaz pública. La lista de acceso split-exclude no debe incluir la subred que cubre los servidores DNS de túnel. A partir de AnyConnect 4.2, las rutas de host para los servidores DNS de túnel se agregan automáticamente como redes split-include (rutas seguras) por el cliente AnyConnect y, por lo tanto, esto evitará errores de configuración en la lista de acceso split-exclude.

DNS dividido (DNS de túnel completo deshabilitado, split-include configurado)

Anterior a AnyConnect 4.2

Las solicitudes DNS que coincidan con los dominios split-dns pueden tunelizar servidores DNS, pero no se permiten a otros servidores DNS. Para evitar que estas consultas de DNS internas se filtren por el túnel, el controlador de AnyConnect responde con "no existe ese nombre" si la consulta se envía a otros servidores DNS. Por lo tanto, los dominios split-dns solo se pueden resolver a través de los servidores DNS de túnel.

Las solicitudes DNS que no coincidan con los dominios split-dns se permiten a otros servidores DNS, pero no a los servidores DNS de túnel. Incluso en este caso, el controlador de AnyConnect responde con "no existe tal nombre" si se intenta realizar una consulta para dominios no split-dns a través del túnel. Por lo tanto, los dominios sin split-dns solo se pueden resolver a través de servidores DNS públicos fuera del túnel.

AnyConnect 4.2+

Las solicitudes DNS que coincidan con los dominios split-dns se permiten en cualquier servidor DNS, siempre que se originen en el adaptador VPN. Si la consulta es originada por la interfaz pública, el controlador de AnyConnect responde con un 'no tal nombre' para forzar a la resolución a utilizar siempre el túnel para la resolución de nombres. Por lo tanto, los dominios split-dns solo se pueden resolver a través del túnel.

Las solicitudes DNS que no coincidan con los dominios split-dns se permiten en cualquier servidor DNS siempre que se originen en el adaptador físico. Si el adaptador VPN origina la consulta, AnyConnect responde con "no existe tal nombre" para forzar a la resolución a intentar siempre la resolución de nombres a través de la interfaz pública. Por lo tanto, los dominios sin split-dns solo se pueden resolver a través de la interfaz pública.

Mac OS X

Configuración de túnel completo (y túnel dividido con DNS de túnel completo habilitado)

Cuando AnyConnect está conectado, solo los servidores DNS de túnel se mantienen en la configuración DNS del sistema y, por lo tanto, las solicitudes DNS solo se pueden enviar a los servidores DNS de túnel.

Configuración de split-include (DNS de túnel completo deshabilitado y sin split-DNS)

AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, teniendo prioridad sobre los servidores DNS públicos, lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel. Dado que la configuración de DNS es global en Mac OS X, no es posible que las consultas DNS utilicen servidores DNS públicos fuera del túnel como se documenta en CSCtf2026 . A partir de AnyConnect 4.2, las rutas de host para los servidores DNS del túnel se agregan automáticamente como redes de inclusión dividida (rutas seguras) mediante el cliente AnyConnect y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.

Configuración de exclusión dividida (DNS de túnel completo deshabilitado y sin DNS dividido)

AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, teniendo prioridad sobre los servidores DNS públicos, lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel. Dado que la configuración de DNS es global en Mac OS X, no es posible que las consultas DNS utilicen servidores DNS públicos fuera del túnel como se documenta en CSCtf2026 . A partir de AnyConnect 4.2, las rutas de host para los servidores DNS del túnel se agregan automáticamente como redes de inclusión dividida (rutas seguras) mediante el cliente AnyConnect y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.

DNS dividido (DNS de túnel completo deshabilitado, split-include configurado)

Si split-DNS está habilitado para ambos protocolos IP (IPv4 e IPv6) o sólo está habilitado para un protocolo y no hay ningún conjunto de direcciones configurado para el otro protocolo:
Se aplica un split-DNS real similar a Windows. True split-DNS significa que las solicitudes que coinciden con los dominios split-DNS sólo se resuelven a través del túnel, no se filtran a los servidores DNS fuera del túnel.

Si split-DNS está habilitado sólo para un protocolo y se asigna una dirección de cliente para el otro protocolo, sólo se aplica "DNS fallback for split-tunneling". Esto significa que AC solo permite solicitudes DNS que coincidan con los dominios split-DNS a través del túnel (otras solicitudes son contestadas por AC con una respuesta "rechazada" para forzar la conmutación por fallas a servidores DNS públicos), pero no puede hacer cumplir que las solicitudes que coincidan con dominios split-DNS no se envíen en forma clara, a través del adaptador público.

Linux

Configuración de túnel completo (y túnel dividido con DNS de túnel completo habilitado)

Cuando AnyConnect está conectado, solo los servidores DNS de túnel se mantienen en la configuración DNS del sistema y, por lo tanto, las solicitudes DNS solo se pueden enviar a los servidores DNS de túnel.

Configuración de split-include (DNS de túnel completo deshabilitado y sin split-DNS)

AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, teniendo prioridad sobre los servidores DNS públicos, lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel.

Configuración de exclusión dividida (DNS de túnel completo deshabilitado y sin DNS dividido)

AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, teniendo prioridad sobre los servidores DNS públicos, lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel.

DNS dividido (DNS de túnel completo deshabilitado, split-include configurado)

Si split-DNS está habilitado, solo se aplica "DNS fallback for split-tunneling". Esto significa que AC solo permite solicitudes DNS que coincidan con los dominios split-DNS a través del túnel (otras solicitudes son contestadas por AC con una respuesta "rechazada" para forzar la conmutación por fallas a servidores DNS públicos), pero no puede hacer cumplir que las solicitudes que coincidan con dominios split-DNS no se envíen en forma clara, a través del adaptador público.

Cliente OpenDNS Roaming

El cliente de roaming es un software que administra los servicios DNS en el terminal y utiliza los servidores DNS públicos de OpenDNS para proteger y cifrar el tráfico DNS.

Idealmente, el cliente debería estar en un estado protegido y cifrado. Sin embargo, si el cliente no puede establecer una sesión TLS con el servidor de resolución pública OpenDNS (208.67.222.222), intenta enviar tráfico DNS sin cifrar en el puerto UDP 53 a 208.67.222.222. El cliente de roaming utiliza exclusivamente la dirección IP de resolución pública de OpenDNS 208.67.222.222 (hay algunas otras como 208.67.220.220, 208.67.222.220 y 208.67.220.222). Una vez instalado, el cliente de itinerancia establece 127.0.0.1 (localhost) como servidor DNS local y anula la configuración actual de DNS por interfaz. La configuración actual de DNS se almacena en archivos resolv.conf locales (incluso en Windows) dentro de la carpeta de configuración de cliente de roaming. OpenDNS realizará una copia de seguridad incluso de los servidores DNS que se detecten a través del adaptador AnyConnect. Por ejemplo, si 192.168.92.2 es el servidor DNS en el adaptador público, OpenDNS creará el resolv.conf en la siguiente ubicación:

C:\ProgramData\OpenDNS\ERC\Resolver1-LocalAreaConnection-resolv.conf
nameserver 192.168.92.2

El cliente de roaming cifrará cada paquete configurado en OpenDNS; sin embargo, no inicia ni utiliza un túnel de cifrado a 208.67.222.222. El cliente de roaming tiene una función opcional de aplicación de capa IP que abrirá una conexión IPSec para bloquear direcciones IP con fines no DNS. Esto se desactivará automáticamente en presencia de una conexión AnyConnect activa. También se enlaza a 127.0.0.1:53 para recibir consultas generadas localmente en el equipo. Cuando el punto final necesita resolver un nombre, las consultas locales se dirigen a 127.0.0.1 debido a la invalidación, y luego el proceso dnscrypt-proxy subyacente del cliente de roaming las reenvía a los servidores públicos OpenDNS a través del canal cifrado.

Si no se permite que DNS fluya a 127.0.0.1:53, el cliente de roaming no podrá funcionar y ocurrirá lo siguiente. Si el cliente no puede alcanzar los servidores DNS públicos o la dirección enlazada 127.0.0.1:53, pasará a un estado de fallo-apertura y restaurará la configuración DNS en los adaptadores locales. En segundo plano, continúa enviando sondeos a 208.67.222.222 y puede pasar al modo activo si se restablece la conexión segura.

Limitaciones

Habiendo analizado la funcionalidad de alto nivel de ambos clientes, es evidente que el cliente de roaming necesita tener la capacidad de cambiar la configuración de DNS local y enlazarse a 127.0.0.1:53 para reenviar consultas a través del canal seguro. Cuando VPN está conectado, las únicas configuraciones donde AnyConnect no interfiere con la resolución de DNS nativo son split-include y split-exclude (con split-tunnel-all DNS deshabilitado). Por lo tanto, actualmente se recomienda utilizar una de esas configuraciones, cuando el cliente de roaming también está en uso. El cliente de roaming permanecerá en un estado no protegido/no cifrado si se usa la configuración tunnel-all o se habilita split-tunnel-all DNS, como se muestra en la imagen.

Solución Aternativa

Si la intención es proteger la comunicación entre el cliente de roaming y los servidores OpenDNS mediante el túnel VPN, se puede utilizar una lista de acceso de exclusión dividida ficticia en la cabecera VPN. Esto será lo más parecido a una configuración de túnel completa. Si no existe tal requisito, entonces se puede utilizar split-include donde la lista de acceso no incluye los servidores públicos OpenDNS, o split-exclude cuando la lista de acceso incluye los servidores públicos OpenDNS.

Además, al utilizar el cliente de roaming, no se pueden utilizar los modos split-DNS, ya que esto provocará una pérdida de la resolución DNS local. El DNS split-tunnel-all también debe permanecer inhabilitado; sin embargo, es soportado parcialmente y debe permitir que el cliente de roaming se convierta en cifrado después de la conmutación por fallas. 

Configuraciones

Tráfico OpenDNS de túnel

Este ejemplo utiliza una dirección IP ficticia en la lista de acceso split-exclude. Con esta configuración, toda la comunicación con 208.67.222.222 se realiza a través del túnel VPN y el cliente de roaming funciona en un estado cifrado y protegido.

ciscoasa# sh run access-li split
access-list split standard permit host 2.2.2.2

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Excluir el tráfico OpenDNS del túnel VPN

Este ejemplo utiliza la dirección de resolución de OpenDNS en la lista de acceso de exclusión dividida. Con esta configuración, toda la comunicación con 208.67.222.222 ocurre fuera del túnel VPN, y el cliente de roaming opera en un estado cifrado y protegido.

ciscoasa# sh run access-li split
access-list split standard permit host 208.67.222.222

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Este ejemplo muestra una configuración split-include para una subred 192.168.1.0/24 interna . Con esta configuración, el cliente de roaming seguirá funcionando en un estado cifrado y protegido ya que el tráfico a 208.67.222.222 no se envía a través del túnel.

ciscoasa# sh run access-li split
access-list split standard permit 192.168.1.0 255.255.255.0

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Note: Split-tunnel-all-dns must be disabled in all of the  scenarios

Verificación

Cuando la VPN está conectada, el cliente de roaming debe mostrar protección y cifrado, como se muestra en esta imagen: