Saltar al contenido
Inicio / Azure / Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte III)

Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte III)

Continuando con los artículos anteriores de instalación de un firewall Fortinet en Azure (Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte I), Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte II)), vamos continuar con la tercera parte donde vamos a configurar la conexión VPN para nuestros clientes VPN. Este artículo configuraremos una conexión SSTP con el cliente de Fortinet y donde autenticaremos utilizando el MFA de Microsoft, el proceso será el siguiente:

  1. Configuración de un registro DNS público que tenga como IP la IP Pública del Firewall
  2. Importación de un certificado digital el cual utilizaremos para la conexión SSTP
  3. Instalación de la extensión NPS para nuestro servidores Radius y configuración de Radius en el Firewall
  4. Configuración de la conexión SSTP en el Firewall
  5. Configuración de las políticas de Firewall básicas para permitir las conexiones de los clientes VPN

Como siempre, aquí os dejo la topología de referencia:

Objetivo: configurar una conexión VPN SSTP para que nuestros usuarios remotos se conecten a los servidores de ficheros que tenemos en Azure Files (con Private Link: Microsoft Azure Files: Migración, Conexión Privada vía Private Link utilizando DNS Privados para Clientes VPN en Azure) y autenticando con MFA vía NPS

Ahora vayamos paso a paso configurando el servicio en nuestro Firewall de Azure:

1. Configuración de un registro DNS público que tenga como IP la IP Pública del Firewall

Nuestro Firewall en Azure no va a “ver” directamente la IP Pública que tiene, pero si la tarjeta de red que tiene nuestra máquina virtual de nuestro firewall. Accedemos a l máquina virtual y copiamos la IP Pública que tenga asociada:

Ahora crearemos un registro DNS para que los clientes VPN puedan configurar, algo como sstp.dominio.com (por ejemplo). Esto lo haréis en vuestro NS de vuestro dominio, en mi caso es en Azure y simplemente he añadido un registro de tipo CNAME que tiene como host de destino un registro tipo A que apunta la  IP pública de mi firewall:

2. Importación de un certificado digital el cual utilizaremos para la conexión SSTP

Una vez que hayamos solicitado y descargado el certificado SSL de nuestro proveedor (DigiCert, Godaddy, etc..) debemos acceder la configuración del Firewall e importarlo de la siguiente forma desde la sección System – Certificates vamos a Create/Import y pulsamos en Certificate:

Pulsamos en Import Certificate:

Buscamos el certificado, escribimos su clave de importación y escribimos el nombre con el que vamos a identificar el certificado en el Firewall y pulsamos en Create:

Si lo hemos hecho bien tendremos que ver algo parecido a esto:

Y el certificado correctamente importado:

3. Instalación de la extensión NPS para nuestro servidores Radius

Aquí no voy explayarme mucho, porque tengo otros artículos donde hablo de la instalación del NPS en un Windows Server y la extensión de NPS para utilizar la autenticación con MFA (+info https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension). Lo único comentar algunos detalles que me parecen interesantes:

  1. El servidor NPS solo autenticará peticiones para luego enviar la petición a AzureAD para la doble autenticación,  vamos, que si tenéis otros servicios en ese radius podrían quedar inutilizados. Aunque MSFT te permite configurar una clave de registro para evitarlo (If you have users that aren’t enrolled for MFA, you can determine what happens when they try to authenticate. To control this behavior, use the setting REQUIRE_USER_MATCH in the registry path HKLM\Software\Microsoft\AzureMFA. This setting has a single configuration option) yo nunca lo he logrado :-(. Recomendable configurar un servidor con el rol NPS solo para las conexiones que queráis autenticar con MFA.
  2. El nivel de autenticación para recibir el SMS de doble factor de autenticación solo funcionará si utilizáis PAP en vuestra configuración de Radius. MSFT también indica que si utilizamos MSCHAP-V2 podemos utilizar Microsoft Authenticator yo no lo he hecho funcionar.

Estas son las dos cosillas que yo me he encontrado, si alguien es capaz de salvarlas por favor, dejar un comentario en este artículo. Igualmente aquí os dejo una vez instalada la extensión de NPS (aquí el artículo de como se instala y configura Instalación y configuración extensión NPS para AzureMFA la configuración a nivel de servidores NPS y Firewall.

Primero la configuración del servidor Radius, básicamente configurar el cliente Radius con una clave compartida:

Luego una directiva de red sencilla, compruebo si perteneces al grupo Acl Nps AzureMFA Users y poco más (podéis complicarlo todo lo que queráis claramente):

Ahora la parte del Firewall, en la sección User & Authetication vamos a la sección Radius Servers y pulsamos en Create New (yo ya lo tengo creado pero os muestro su configuración):

Escribimos un nombre descriptivo, tipo de autenticación (recordad lo de PAP que he comentado antes), la IP de nuestro/s servidor/es Radius y la clave compartida:

Ahora tenemos que crear un grupo de usuarios para luego utilizarlo en las políticas del firewall, para ello vamos a User & Authenticacion  – User Groups y pulsamos en Create New:

Escribimos un nombre descriptivo, pulsamos en Add en la sección de Remote Groups (paso 1) para luego elegir el servidor Radius que previamente hemos configurado (paso 2) y  es el que muestro en el paso 3 (es que ya lo tenía configurado):

Y listo, ya tenemos nuestro grupo de usuarios cuyos miembros serán los que nos vengan por la conexión de los servidores radius:

4. Configuración de la conexión SSTP en el Firewall

Ahora veamos las configuraciones más globales/importantes que debemos revisa para que los clientes VPN se puedan conectar, para ello nos vamos a la sección de VPN y luego a SSL-VPN Settings:

  • Elegimos nuestra interface para este servicio: como es algo que tiene que ser accesible directamente desde internet elegimos nuestra WAN
  • Puerto de escucha para el servicio: 443 (podéis cambiarlo si queréis)
  • Server Certificate: elegimos el certificado que hemos anteriormente importado
  • IP Ranges: por defecto no ofrece un rango de IPs para los clientes VPN, aquí a vuestra elección el crear un nuevo o no
  • DNS: si queréis que resuelvan registro DNS internos tenéis que poner las IPs de vuestros DCs si tenéis
  • Mapeado de portal: aquí es donde asociamos el grupo creado anteriormente en el portal de acceso del Firewall, yo lo he agregado al portal Tunnel-Access

El portal de acceso es donde podemos configurar si los clientes se conectarán con Split-Tunneling habilitado o no, en mi caso para este artículo así será (para el próximo mostraré una configuración sin Split-Tunneling). Entiendo que todos sabéis que es el Splint-Tunneling, pero sino es así, básicamente es indicarle al cliente VPN que tráfico tiene que enviar mediante el túnel VPN (tráfico hacia la red privada de la empresa) y cual no (el resto del tráfico de red como el acceso a Internet), esto tiene sus ventajas e inconvenientes, pero esto prefiero comentarlo en el siguiente artículo que lo haré sin Split-Tunneling:

5. Configuración de las políticas de Firewall básicas para permitir las conexiones de los clientes VPN

Una vez que ya hemos completado todos los pasos anteriores, solo nos queda crear las políticas de firewall en las que indicaremos que tráfico vamos a permitir  hacia nuestras redes protegidas. Es como una regla cualquiera, simplemente que aquí no habilitamos  la opción de NAT, aquí os dejo alguna de la reglas para los clientes VPN que tengo configuradas:

Y aquí la edición de una de ellas, en donde os cuento la cosas a tener en cuenta:

  • Interface de entrada: una interface virtual que se nos crea para mantener virtualmente a los clientes VPN
  • Interface de salida: si recordáis la configuración que hemos comentado en los dos primeros artículos sobre el firewall Fortinet en Azure, la interface LAN será la encargada de llevarnos a cualquier red interna
  • Origen: aquí importante configurar los rangos de VPN de los clientes VPN (como os comento ya tengo varias configuraciones en el firewall por eso aparecen más rangos), y los grupos de autenticación que hemos creado anteriormente.
  • Destino: a los host a los que queráis que tengan acceso
  • Servicios: los puertos o grupos de servicios a los que le vamos a permitir que se conecten
  • Nat: importante.. DESHABILITADO
  • Perfiles de seguridad: aquí es importante  habilitar el IPS por lo menos.

Por el resto, nada que no hayáis hecho en otras reglas. Ahora bien, nos queda probar la conexión VPN con el cliente Fortinet y aprovecho para dejaros por aquí un enlace de un articulo donde explico como publicar desde Intune el cliente de Fortinet y su configuración para que los usuarios solo tengan que pulsar en conectar y autenticarse: Microsoft Intune: Actualización del Cliente VPN de Fortinet. De esta forma, podéis desplegar la nueva versión del cliente VPN de Fortinet (desinstalando las versiones previas si existen en los equipos) y ya configurar la nueva conexión con los datos que necesitan para conectarse con el Firewall que hemos desplegado en Azure, vamos, que este proceso os sirve también para migrar las conexiones VPN que tengáis en On-Premises y ahora las tenéis en Azure :-).

Pues nada, solo toca probarlo … primero nos pide que iniciemos sesión y nos autenticará el servidor NPS:

Una vez nos hayamos validado correctamente entonces como podemos apreciar nos solicitar el código (recibido vía SMS) para la segunda autenticación, ya la autenticación MFA: 

Y si hemos puesto correctamente el código pues .. conexión VPN establecida:

Por último, nos conectaremos a la consola del Firewall y en la sección Dashboard – Users & Devices buscamos al usuarios y aí lo podemos ver conectado, su nombre de usuario, IP , Grupo, Duración, Tráfico y Método:

Si ahora filtramos por el usuario en cuestión en la sección de FortiView Sessions podemos ver las reglas que se le están aplicando en función del tráfico de red que está generando:

Como podéis observar es muy sencillo configurar todo el proceso desde cero, sencillo y súper útil. Entiendo que no tengo que recordar que los usuarios tienen que tener habilitar el MFA sino .. no vale de nada :-).

En el siguiente artículo vamos a configurar ya solo la parte de los clientes sin Split-Tunneling y como podemos controlar no solo el tráfico hacia los recursos internos, sino su navegación a Internet (AV, Web Filter, Traffic Shapping, etc..), pero ya para el siguiente fin de semana :-).

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

¡Comparte!