Conexión VPN + RADIUS + AzureMFA + Enrutamiento IP

Con este artículo voy a poner fin a una serie de configuraciones VPN, autenticación Radius + MFA, etc.. y lo último que quería comentar es como enviar o definir rutas estáticas hacia los clientes VPN configurados con Split-Tunneling.

Voy a empezar por definir que es Split-Tunneling, básicamente consiste en que los clientes VPN puedan salir a Internet utilizando su propia conexión a Internet y el tráfico dirigido hacia la red local ser hará mediante el túnel VPN. Si por el contrario, no tuviéramos configurado Split-Tunneling, todo el tráfico de los usuarios conectados se cursaría mediante la conexión VPN (Internet y Red Local Remota). Esta última configuración (sin Split-Tunneling), nos permite definir reglas de filtrado, inspección de tráfico malicioso, etc.. Además, esta configuración evita el tráfico local y VPN al mismo tiempo, permitiendo únicamente que todo el tráfico se curse por el túnel VPN. Pero por otro lado, podríamos sobrecargar las conexiones de nuestros CPDs sino estamos correctamente dimensionados, como siempre, todo tiene su “depende“.

Pero hoy, no me voy a ceñir a tener una VPN sin Split-Tunneling, sino todo lo contrario, a comentar dos entornos de clientes VPN y como se configuran las rutas “estáticas” necesarias para enviar tráfico a la red local mediante la conexión VPN. Trataré de comentar esta configuración sobre el siguiente esquema de red, teniendo una conexión VPN en On-Premises y desde Azure:

Empezaremos por una configuración de una VPN en Azure (VPN Azure con Autenticación Radius), si configuramos la VPN de forma manual (los datos de configuración los tenemos en el fichero XML que nos descargamos con el cliente VPN de Azure):

Fichero XML

Configuración de una VPN con Azure con lo datos del fichero XML

Si ahora nos conectamos con esta configuración de VPN, nos conectará sin problema , pero no tendremos tráfico hacia ninguna subred de Azure porque no tenemos ninguna ruta de red en nuestra tabla de enrutamiento (subred de Azure 172.19.0.0 y 172.22.0.0/24 y se aprecia que no las tenemos configuradas):

Si ahora configuramos la VPN con el cliente descargado de Azure y nos conectamos, veremos una advertencia de que necesitamos privilegios para completar una solicitud de una ejecución de una dll (cmroute.dll) que será la que actualizará nuestra tabla de enrutamiento cada vez que nos conectemos a la VPN):

Si ahora vemos nuevamente nuestra tabla de enrutamiento (route print) veremos que ya tenemos inyectadas en nuestra tabla de enrutamiento las subredes declaradas en Azure.

Nota: cuando nos descargamos el cliente VPN de Azure y descomprimimos el fichero descargado, podemos encontrarnos con un fichero XML donde tenemos la configuración de la VPN y vemos las tablas de rutas que a posteriori tiene que inyectarnos en nuestra tabla de enrutamiento:

Una vez instalado el cliente VPN y accedemos a la siguiente ruta %AppData%\Microsoft\Network\Connections\Cm\guid-conexión veremos la DLL cmroute.dll y un fichero de texto (routes.txt) donde tenemos la subredes que tenemos en Azure. De ahí, que cuando creemos alguna nueva subred IP, tenemos que volver a descargarnos nuevamente el cliente VPN, porque este fichero vendrá actualizado con las nuevas subredes (pero podemos actualizarlo a mano o, si quieres hacerlo de forma masiva en tus equipos puedes hacerlo vía GPO o Intune, evitando tener que desplegar nuevamente el cliente VPN):

Como hemos visto, la tabla de enrutamiento se inyecta cuando nos conectamos a la VPN mediante al DLL cmroute.dll.

Hasta aquí todo correcto, pero que ocurre si queremos conectarnos desde Azure a servicios que tenemos en On-Premises (conectados mediante una VPN Site-to-Site) para acceder a servidores locales? Si probáis, veréis que no tenéis acceso:

El problema sigue siendo el mismo, el cliente VPN de Azure no tiene información sobre rutas de subredes IP que tenemos en otro sitio que no sea Azure, pero .. esto no quiere decir que no podamos conectarnos a recursos de On-Premises utilizando la conexión VPN Point-to-Site de Azure, pero antes tenemos que hacer algunos ajustes en nuestra topología:

• La configuración de la VPN Site-to-Site entre Azure y On-Premises se tiene que modificar en el extremo de On-Premises, porque tenemos que añadir en la Fase 2 de IPSec en las subredes de los clientes VPN de Azure (sino, no tendremos tráfico) para cada subred local
• Si tenemos varias subredes IP en On-Premises, es posible que tengamos que actualizar las rutas de enrutamiento de los enrutadores locales para que sepan como llegar a la subred de los clientes VPN
• Actualizar el fichero routes.txt de los clientes VPN para que tengan las subredes IP de On-Premises

Una vez realizados todos estos ajustes, volvemos a lanzar la conexión VPN y tendremos la nueva ruta activa

Si ahora lanzamos nuevamente un ping (si lo tenemos permitido), veremos que ya tenemos respuesta:

Otra cosa será la latencia que tengamos entre ambos extremos:

• Cliente VPN –vNet Azure: tomando como referencia una conexión desde España hacia Azure (Norte de Europa) tenemos 50ms de media
• Cliente VPN – vNet Azure- On-Premises: tomando como referencia una conexión desde España hacia Azure (Norte de Europa) tenemos 50ms de media y luego el tramo entre Azure y On-Premises otros 50ms, por lo que desde el cliente VPN tendremos 100ms

Pero como vemos es posible tener conectada la VPN de Azure y acceder a recursos de On-Premises, ahora será cuestión de ir colocando los servicios más utilizados en Azure para no sufrir las latencias comentadas.

En este ejemplo siempre he utilizado lo que nos ofrece Azure por defecto, una VPN Site-to-Site y Point-to-Site con sus servicios por defecto. Vemos que es posible, de donde salen las rutas estáticas y como podemos ajustarlas en base a nuestras necesidades. El problema que le veo, es que la rutas estáticas si las tenemos que crear manualmente (cmroute.dll lo hace por ti pero .. es manual), sino somos administradores locales .. (eso se puede ajustar, la cosa va mediante el grupo de Operadores de Red)

Dicho esto, si tenemos que hacer un despliegue masivo de clientes VPN, es posible que nos veamos con alguna dificultad por este motivo (que se puede ajustar, pero por defecto, tendríamos algún problema para los usuarios no administradores).

Pues ahora os voy a contar esto mismo pero con una configuración local, vamos, teniendo un servidor Windows como servidor VPN y como se pueden automatizar la entrega de rutas estáticas mediante un servidor DHCP (aquí os dejo un artículo del 2014 donde he hablado de esto: https://www.santiagobuitragoreis.com/como-asignar-rutas-estaticas-desde-un-servidor-dhcp-opcion-121/). Solo me voy a ceñir a dos configuraciones que tenéis que realizar para este despliegue:

• DHCP Relay: el servidor VPN reenviará las solicitudes DHCP de los clientes VPN a un servidor DHCP que tengamos en la red
• Rutas estáticas sin clase: configuración de la opción 121 del servidor DHCP

En el servidor VPN podemos definir que ser un servidor DHCP externo quien entregue la direcciones IP a los clientes VPN, para ello tenemos que definir un Agente de retransmisión DHCP especificando la dirección IP del servidor DHCP al cual queremos enviarle las solicitudes DHCP de los clientes VPN:

Y en el servidor DHCP, podemos configurar quien serán los servidores DNS para la resolución de nombres de los clientes VPN entre otras cosas, pero además, podemos definir las rutas  estáticas necesarias para configurar nuestro Split-Tunneling. Para esto, tenemos una opción, la 121 que es la gran desconocida para muchos administradores: Rutas estáticas sin clase. Lo que haremos será definir las subredes Internas o de Azure (internas desde el punto de vista del túnel VPN) a las que tendrá acceso el cliente VPN una vez conectado:

• Destino: red de destino o de un host en concreto
• Máscara de subred: especificaremos la máscara de subred para la red de destino o para el host (255.255.255.255)
• Enrutador: la dirección IP interna del servidor VPN

Así con todas las subredes IP a las que queráis que vuestros usuarios tengan acceso desde la conexión VPN

Antes he comentado que, unos de los “problemas” de la conexión de Azure es su configuración/instalación y sus permisos de administrador (y la inyección de rutas estáticas). Pues bien, con el tema de las rutas salvado, ahora quedaría configurar la conexión VPN de los usuarios… pues si tienen Windows 10 pueden hacerlo sin privilegios de administrador configurándola vía PowerShell y ejecutando este sencillo comando:

Add-VpnConnection -Name “Nombre–Conexión” -ServerAddress “vpn.dominio.com” -TunnelType “Sstp,Ikev2” -EncryptionLevel “Required” -AuthenticationMethod “Eap” -SplitTunneling

Una vez configurada la VPN desde un cliente, si nos conectamos .. bingo!! ya tiene todas las subredes IP  a las que queremos que accedan inyectadas en su tabla de enrutamiento de forma transparente para el usuario:

Comentaros que, también en esta configuración se puede llegar a las subredes de Azure con las correspondientes modificaciones.

Es una configuración muy útil el poder inyectar rutas estáticas sin clase desde el DHCP y no solo para las conexiones VPN, sino también para este tipo de escenarios que había comentado en su momento: Cómo asignar rutas estáticas desde un servidor DHCP (Opción 121)

(Esquema de Visio creado en el 2014, como hemos cambiado 🙂 )

Creo que se entiende bien, podemos darle muchísima utilidad a esta opción 121 de nuestros servidores DHCP.

Ahora, como siempre, os toca a vosotros probarlo!!!