Contruye tu propia VPN Point to Site en Azure compatible con ExpressRoute y autenticación Active Directory

Esto puede dar un poco de sensación de dejà-vu, sobre todo cuando en el blog de Enterprise IT de Plain Concepts ya hablé de este tema. Sin embargo, quiero aprovechar para dar la profundidad técnica que merece.

La situación

Imaginad que hemos construido nuestra red en Azure, en la que hemos puesto un bosque de Active Directory con dos controladores de dominio. Evidentemente no queremos que esto esté expuesto a Internet de ninguna manera por razones obvias. Sin embargo, es necesario que nuestros administradores de sistemas entren en la red para realizar tareas de gestión e implementar nuevos servicios en otras máquinas virtuales que agregaremos más tarde.

Estas personas deberán validarse contra el bosque de Active Directory antes de poder acceder a los entornos.

Conclusión lógica: necesitamos una VPN Point to Site.

¿Qué es una VPN Point to Site?

Hay multitud de tecnologías para construir accesos VPNs, pero la mayoría de ellas se reducen a la consecución de dos objetivos que se pueden presentar juntos o por separado:

• Conectar dos redes locales físicamente separadas a través de una red de área amplia (WAN), que suele ser Internet en la mayoría de los casos. Los dispositivos que se encuentren en ambas redes tendrán visibilidad como si estas estuvieran físicamente conectadas sin realizar ninguna operación especial. Esto se conoce como site to site.
• Conectar un dispositivo individual físicamente separado a una red, de forma que obtenga visibilidad de elementos internos de la misma. Esto se conoce como point to site.

Esta publicación la dedicaré al segundo caso.

¿No tiene Azure un servicio de VPN Point to Site?

Sí, desde luego que lo tiene y se explica aquí. Si bien tiene la ventaja de que es totalmente gestionado por Microsoft y no nos debemos preocupar de administrar máquinas virtuales, runtimes o seguridad; tiene algunos problemas importantes:

• Sólo soporta sistemas operativos Windows 7 SP1 y superiores. No hay soporte para OSX, GNU/Linux o dispositivos móviles.
• Su autenticación se basa en certificados, por lo que debemos manejarnos con una PKI para implementarlo productivamente.
• Sólo realiza split-tunneling por lo que no soporta que enrutemos todo nuestro tráfico a través de Azure.
• La comunicación es siempre en sentido saliente del dispositivo conectado al resto de la infraestructura. Un servicio escuchando en el dispositivo conectado no será alcanzable desde la red de destino.
• No es compatible con ExpressRoute. Aunque el Gateway ExpressRoute puede coexistir con otro VPN, este último no podrá desplegar Point to Site si se encuentra en esta situación de convivencia.

Cualquiera de estos puntos, bien sea separados o combinados pueden inclinar bastante la balanza hacia una solución alternativa.

Nuestros objetivos

Queremos establecer una VPN Point to Site que cumpla con los siguientes criterios:

• Debe ser compatible con ExpressRoute.
• Los usuarios se autenticarán mediante sus cuentas de Active Directory.
• Debe ser compatible -al menos- con los protocolos SSTP (Windows 7 SP1 y superior) y L2TP/IPsec (virtualmente cualquier dispositivo con capacidades VPN).

¿Cómo? Máquina virtual GNU/Linux y SoftEther VPN

¡Vamos a crear una máquina virtual con GNU/Linux! ¿Por qué Linux? Al césar lo que es del césar. Hasta la fecha de escribir estas líneas considero Linux considerablemente más potente y confiable en temas de redes que Windows y como tal es mi elección por defecto en estas materias (por supuesto, Windows es superior en otros menesteres que no vienen al caso de este artículo).

Ya he hablado en otras ocasiones de las maravillas de este poderoso software de VPN de código abierto, proyecto académico brillante de la Universidad de Tsukuba, Japón. SoftEther VPN funciona bajo Windows, OSX, GNU/Linux, FreeBSD y Solaris. Aunque como veis el software funciona perfectamente en Windows Server, dado que el rol de RRAS de Windows Server NO está soportado en Azure, no me he decidido a aventurarme con SoftEther VPN y a pesar de todo me mantengo en mi afirmación sobre la superioridad en redes de Linux.

SoftEther VPN se define como una alternativa óptima a OpenVPN y los servidores VPN de Microsoft, que puede establecer túneles tanto Site to Site como Point to Site, soportando los siguientes protocolos:

• SSTP
• L2TP, L2TP/IPsec y L2TPv3
• OpenVPN
• SSL-VPN sobre HTTPS, un protocolo propio de SoftEther.

Bajo GNU/Linux para arquitectura x64 SoftEther VPN es muy compatible con las máquinas virtuales de Azure, ¡así que vamos a implementarlo!

Creando y configurando una máquina virtual Azure

Lo primero es crear la máquina virtual. Para ello elegimos alguna de las distribuciones de GNU/Linux soportadas en Azure a través de su galería. Voy a describir cómo hacerlo con Ubuntu 16.04 LTS, pero nada impide hacerlo en cualquier otra. La diferencia potencial del procedimiento sería el sistema de arranque, que en nuestro caso va a ser el infame systemd.

Por otro lado, aunque SoftEther VPN soporta clustering para aumentar la disponibilidad del servicio, nos vamos a basar en configuraciones de una única máquina virtual. En cuanto a tamaños de instancias, recomiendo las siguientes:

• Entornos domésticos o no-productivos: instancias tipo Av2, o incluso A0.
• Entornos productivos: Instancias tipo FS con Storage Premium, que nos permite beneficiarnos del SLA del 99,9% de Azure para esta configuración de una única máquina virtual.

En cuanto al resto de configuraciones:

• Use managed disks. Mi recomendación es YES excepto que alguna de las limitaciones que aplican hoy a estos discos nos afecte. Más información en aquí.
• Virtual Network. Seleccionar la red donde vamos a desplegar la máquina. Deberá ser la red a la que queremos acceder o bien deberá estar conectada a esta mediante VNET Peering.
• Subnet. Nuestro servidor de acceso remoto es una máquina de perímetro, por lo que es muy recomendable ubicarlo en una subred DMZ donde podamos aplicar los NSG pertinentes.
• Public IP address. Desde luego que necesitaremos una y además si puede ser estática mejor que mejor.
• Network Security Group. Necesitaremos permitir los siguientes puertos de entrada en función de los protocolos que vayamos a usar en nuestro servidor. Recuerda que es buena práctica deshabilitar todos los que no vayamos a usar:
• SSH (TCP/22). Obligatorio para administrar la máquina. Más tarde lo protegeremos contra ataques de fuerza bruta o DoS.
• SSTP: HTTPS (TCP/443). Utilizado para la administración de SoftEther VPN y también el puerto de escucha para conexiones SSTP.
• L2TP/IPsec: IKE (UDP/500) y NAT-T (UDP/4500).
• OpenVPN: TCP/443, TCP/992, TCP/5555 y UDP/1194.

Con esto ya estamos listos para crear la máquina virtual.

Configurando el adaptador de red

Una vez nuestra máquina virtual está creada, tenemos que hacer algunas configuraciones en el recurso de interfaz de red Azure. Buscamos cuál tiene asociado la máquina virtual y desde ahí accedemos a IP configurations.

Lo primero que tendremos que hacer aquí es habilitar el IP forwarding, ya que la máquina va a hacer de router, dirigiendo paquetes entre redes.

Ahora hacemos clic en ipconfig1 y IP privada a estática.

Podemos aprovechar para revisar la configuración del Network Security Group y de los servidores DNS, pero a priori esta es toda la configuración que necesitamos desde Azure. ¡Hora de entrar en la máquina virtual!

Configurando el sistema GNU/Linux

Instalando SoftEther VPN

Iniciamos la sesión en nuestra máquina virtual mediante SSH y en primer lugar instalamos los requisitos previos:

$ sudo apt update; sudo apt upgrade
$ sudo apt install build-essential wget

Ahora necesitamos buscar y descargar la última versión de SoftEther VPN Server (no confundir con otras ediciones como Bridge) para Linux/x64. Las versiones BETA han demostrado ser muy estables e incorporan características de seguridad que no considero una opción en una máquina de perímetro.

A fecha de escribir estas líneas la última versión es la 4.22-9634-beta-2016.11.27. Procedemos a descargarla y desempaquetarla:

$ wget http://www.softether-download.com/files/softether/v4.22-9634-beta-2016.11.27-tree/Linux/SoftEther_VPN_Server/64bit_-_Intel_x64_or_AMD64/softether-vpnserver-v4.22-9634-beta-2016.11.27-linux-x64-64bit.tar.gz
$ tar xfvz softether-vpnserver-v4.22-9634-beta-2016.11.27-linux-x64-64bit.tar.gz

SoftEther VPN requiere compilar y aceptar un acuerdo de licencia (GPL v2). Procedemos como se hace en todo UNIX:

$ cd vpnserver
$ sudo make

Ahora movemos la carpeta a su destino final y aplicamos los permisos pertinentes para asegurar que otros usuarios del sistema no pueden acceder a ella.

$ cd ..
$ sudo mv vpnserver /usr/local/
$ cd /usr/local/vpnserver/
$ sudo chmod 600 *
$ sudo chmod 700 vpnserver
$ sudo chmod 700 vpncmd

Ahora debemos asegurarnos de que el servidor se puede ejecutar sin problemas en nuestra máquina GNU/Linux:

$ cd /usr/local/vpnserver/
$ sudo ./vpncmd

Al ejecutar la utilidad, marcamos la opción 3 y posteriormente damos la orden check. Si obtenemos un All checks passed estamos en el buen camino.

Creando un servicio en systemd

Queremos que nuestro servicio se inicie automáticamente cuando arranque la máquina, ¿verdad? ¡Vamos a ello!

Creamos un nuevo archivo de servicio de systemd:

$ sudo nano /lib/systemd/system/vpnserver.service

E introducimos el siguiente contenido en él:

[Unit]
Description=SoftEther VPN Server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/vpnserver/vpnserver start
ExecStop=/usr/local/vpnserver/vpnserver stop

[Install]
WantedBy=multi-user.target

Y para activarlo debemos especificar:

$ sudo systemctl enable vpnserver
$ sudo systemctl start vpnserver
$ sudo systemctl status vpnserver

Si el resultado del status es parecido a la siguiente imagen, tenemos el servicio perfectamente funcionando.

Lo fundamental ahora es entrar configurar una contraseña o potencialmente tendremos muchos problemas:

$ /usr/local/vpnserver/vpncmd

Ahora realizamos los siguientes pasos:

1. Especificamos la opción 1.
2. El servidor a conectarnos es localhost, por lo que no necesitamos establecer nada adicional.
3. Ejecutamos ServerPasswordSet y ponemos una contraseña de administración del servidor.
4. Ejecutamos HubCreate AZURE para crear un HUB (no necesitaremos más). Podemos sustituir AZURE por el nombre que prefiramos.

Por último, debemos activar el ipv4 forwarding en nuestra máquina Linux para permitirle hacer las funciones de router. Para ello:

$ sudo nano /etc/sysctl.conf

Buscamos la línea #net.ipv4.ip_forward=1 y la sustituimos por net.ipv4.ip_forward=1. Para activar la configuración basta con escribir:

$ sudo sysctl -p /etc/sysctl.conf

A partir de este punto podemos conectarnos remotamente al servidor con el programa gráfico de administración y realizar las configuraciones adicionales.

Configuración de SoftEther VPN

Vamos a seguir configurando SoftEther VPN, pero ahora desde la administración gráfica. Para ello descargamos las Admin Tools desde el sitio de descargas. La última versión para Windows disponible a fecha de hoy es esta. Una vez desempaquetemos el archivo ejecutamos el vpnsmgr.exe.

Nos aparecerá una ventana para gestionar conexiones a nuestros servidores y hacemos clic en New Setting. Rellenamos los parámetros de conexión y contraseña.

Conectamos con servidor que acabamos de configurar y si todo ha ido bien deberíamos tener una ventana similar a esta:

Debemos empezar a hacer algunas operaciones aquí:

• Management of Listeners. Detener todos aquellos que no necesitemos haciendo clic en Stop. Normalmente será suficiente con dejar el 443 si no queremos OpenVPN.
• Encryption and Network.
  • Encryption Algorithm Settings. Por defecto es RC4-MD5, así que es buena idea cambiarlo a un cifrado más fuerte como los basados en AES256. No os alarméis de la mención a SSLv3, nos ocuparemos de ello más tarde.
  • Server Certificate Settings. Windows por defecto se niega a establecer una conexión SSTP si el certificado que la sirve no es de confianza. Aquí tenemos la opción de importar el que consideremos oportuno o bien crear uno autofirmado. ¿Eres fan de Let's Encrypt? En este artículo explico cómo auto-renovar certificados.
  • User Keep Alive Internet Connection. Deshabilitar. Probablemente no necesitamos que el software esté haciendo conexiones a keepalive.softether.org.
• IPsec/L2TP Setting. Habilitar los que vayamos a utilizar. Normalmente el protocolo más compatible es el clásico L2TP over IPsec. No recomiendo en absoluto habilitar el L2TP plano, ya que no proporciona cifrado y nuestra información viajará limpia por la red.
  • IPsec Pre-Shared Key: PSK que todos los usuarios necesitarán conocer para conectarse por este protocolo.
• OpenVPN / MS-SSTP Setting. Solo hay dos checkboxes para habilitar funciones de OpenVPN y SSTP. Particularmente con SSTP voy más que servido.

¿Lo tenemos? ¡Vayamos ahora a Manage Virtual Hub!

Configurando el Virtual Hub y preparando la autenticación RADIUS

Hemos hecho tantas cosas que lo mismo no recordamos el propósito de nuestra aventura: autenticar con Active Directory mediante RADIUS. Así que tenemos que prepararlo debidamente.

• Manage Users. Otro de los temas en los que brilla SoftEther VPN es que soporta varios métodos de autenticación para sus usuarios... ¡y podemos mezclarlos! Nuestro objetivo es autenticar usuarios de Active Directory mediante RADIUS. Sin embargo es buena idea tener algún usuario en la base de datos local de SoftEther VPN. Que no os despiste el método de autenticación NT Domain Authentication, ya que sólo funciona si corremos SoftEther VPN bajo Windows.
  • Usuario nativo de SoftEther VPN. Hacemos clic en New e introducimos User Name, Full Name, seleccionamos Password Authentication y Password.
  • Resto de usuarios RADIUS. Otra vez clic en new, pero en este caso el User Name es * (sí, el carácter comodín) y el tipo de autenticación RADIUS Authentication. No hay que configurar nada más. Esta configuración busca en el servidor RADIUS cualquier usuario que intente autenticar.
    
• Authentication Server Settings. Muy sencillo:
  • Activar el Use RADIUS Authentication
  • RADIUS Server HostName or IP. Aún no lo hemos creado, pero puedes dejarlo apuntando al controlador de dominio de Active Directory. Puedes usar , o ; como separador para introducir varios nombres de servidores. Muy útil para garantizar alta disponibilidad.
  • Configurar puerto y el Shared Secret, que debe coincidir con el definido en el servidor RADIUS.

¡Vamos ahora a una parte crucial de la configuración! ¡Virtual NAT and Virtual DHCP Server (SecureNAT)!

Configurando SecureNAT

Al igual que otros servidores Point to Site, SoftEther VPN crea una red virtual ficticia donde ubicará a todos los clientes que se conecten. En esta red coloca un servidor DHCP para asignar IP, un proxy DNS y un NAT para poder alcanzar nuestra red de destino.

Como nota decir que no es necesario configurar ninguna red virtual o subred en Azure para alojar el SecureNAT, si bien es de vital importancia que los rangos que asignemos en esta configuración no se solapen otros que ya tengamos definidos en Azure.

Antes de activar el servicio debemos configurarlo, así que vamos a SecureNAT Configuration. Nos aparece la siguiente ventana:

• MAC Address. Podemos dejar la que nos aparezca por defecto.
• IP Address. La dirección IP del servidor DHCP y el router. Debe estar en la misma subred que los clientes.
• Subnet Mask. En función de la subred que definamos.
• Virtual DHCP Server Settings
  • Use Virtual DHCP Server Functions. Activar y establecer el rango de direcciones IP que este tendrá disponible para los clientes que se quieran conectar.
• Use Virtual NAT Function. Activar y dejar valores por defecto excepto que sepamos muy bien lo que estamos haciendo.
• Options Applied to Clients (optional)
  • Default Gateway Address. Una configuración crucial, tenemos dos opciones: dejarlo en blanco si vamos a hacer split tunneling y por tanto necesitamos ir a Edit the static routing table to push o bien poner la misma dirección que IP Address si queremos enrutar todo el tráfico por el tunel.
  • DNS Server Address. Podemos especificar aquí los servidores DNS a asignar a los clientes. Si ponemos la misma IP Address que comentamos anteriormente, SoftEther VPN utilizará los que tenga asignados la máquina, que os recuerdo que a su vez vienen de la configuración de red virtual de Azure.
  • Domain Name. Por si queremos agregar un dominio de búsqueda por defecto. Totalmente opcional.
• Edit the static routing table to push. Esto es obligatorio si decidimos dejar el Default Gateway Address en blanco para hacer split tunneling. Aquí podemos especificar a los clientes que se conecten al Point to Site la tabla de rutas que definamos. La interfaz es muy auto-explicativa con el formato, que es tipo RED/MÁSCARA/GATEWAY.

Con todo configurado ya estamos en disposición de hacer clic en OK y posteriormente en Enable SecureNAT. Después Exit dos veces y hemos configurado nuestro VirtualHUB.

Ahora nos faltan unos servidores RADIUS enlazados con nuestro Active Directory. ¡Vamos a por ellos!

Servidor RADIUS para Active Directory con Windows Server

Una de las novedades que incluyó Windows Server 2008 era un nuevo rol llamado Network Policy Server que entre sus funciones contaba con la de hacer de servidor RADIUS contra la base de usuarios de Active Directory. A día de hoy el rol y esta función se mantienen en Windows Server 2016... ¡justo lo que necesitamos!

Vamos a proceder a instalar el rol de NPS en una de las máquinas que hacen de controlador de dominio. ¿No decimos siempre que un controlador de dominio no debe instalarse nada y muy preferiblemente evitar roles adicionales? Correcto, pero el NPS en contexto de autenticación RADIUS es una excepción por dos motivos:

• No interfiere para nada con la operativa del controlador de dominio.
• Cuando un usuario autentica mediante RADIUS la conexión que realiza a Active Directory es en la misma máquina, de forma local, lo que acelera considerablemente el proceso.

Así pues, agregamos el rol de Network Policy Server. Si estás en una versión anterior a Windows Server 2016 te dará opción a desplegar los subroles de Network Access Protection (NAP) y HCA, que no necesitamos (y han desaparecido en Windows Server 2016).

Configurar el servidor RADIUS es muy fácil. Lo primer que tenemos que hacer es abrir la consola de administración del Network Policy Server y hacer clic con el botón derecho en NPS (Local) y seleccionar la opción Register server in Active Directory.

Una vez completado tenemos un asistente en Getting Started que nos hará la vida muy fácil. Seleccionamos del desplegable RADIUS server for Dial-Up or VPN Connections y hacemos clic en Configure VPN or Dial-Up.

Marcamos lo obvio, Virtual Private Network (VPN) Connections.

A continuación nos pedirá agregar clientes RADIUS (esto es nuestro SoftEther VPN). Especificamos friendly name, IP y el Shared Secret que debe coincidir con el que pusimos en la configuración del SoftEther VPN.

Una vez hecha la configuración seleccionamos el servidor y hacemos clic en NEXT para seguir al siguiente paso para configurar métodos de autenticación. Este paso es vital para garantizar la seguridad de nuestro entorno. Lo dejamos configurado tal como muestra la captura de pantalla: deshabilitar MS-CHAPv2 y activar Extensible Authentication Protocol (EAP para los amigos) y en el desplegable seleccionamos EAP-MSCHAP v2.

Hacemos clic en NEXT para configurar los grupos de usuarios a los que les permitiremos acceso. Seguramente no queremos que cualquier usuario de Active Directory pueda autenticar contra nuestra VPN y tenemos uno o varios grupos de seguridad establecidos a tal efecto. Aquí es el momento de especificarlos.

NEXT y nos vamos a IP Filters. Probablemente no necesitemos tocar nada aquí, así que lo dejamos tal cual.

NEXT y vamos a Encryption Settings. Esta configuración sólo aplica si el servidor VPN que utilizamos es el rol RRAS de Windows Server. Como no aplica no importa lo que pongamos, pero por si acaso tirásemos de él a futuro me gustar dejar activa únicamente el MPPE 128-bit.

NEXT y a Realm Name. La dejamos tal cual, no es necesario tocar nada.

NEXT y ya hemos acabado con el asistente. Hacemos clic en Finish y esto nos crea la entrada para el RADIUS Client, una política de solicitud de conexión y una política de red.

¡Casi hemos terminado con la parte NPS! ¿Qué nos queda?

Tal como tenemos configurado el NPS ahora está preparado para asumir autenticaciones RADIUS de clientes Windows, pero con frecuencia no reconocerá los de otras plataformas. Vamos a modificar una configuración que nos permitirá captar estas peticiones.

Desplegamos Policies y después Connection Request Policy y hacemos doble clic en Virtual Private Network (VPN) Connections.

Se nos abrirá una nueva ventana y en Type of network access server lo cambiamos a Unspecified. Hacemos exactamente lo mismo en Policies, Network Policies y Virtual Private Network (VPN) Connections.

Si tuviéramos que configurar más servidores NPS para alta disponibilidad, es trivial exportar e importar la configuración que acabamos de hacer entre ellos (botón derecho en NPS (Local)) e incluso si nos ponemos creativos podríamos hacer por PowerShell un sistema de sincronización de configuraciones.

¡Ya tenemos nuestro servidor RADIUS listo! ¿Podemos empezar ya a conectarnos? Nos queda una última parte, pero no por ello menos importante.

Hardening

Hardening es un término usado en la industria de la infraestructura de sistemas informáticos que define el set de configuraciones y políticas a aplicar en un sistema con el objetivo de que sea lo más seguro posible. Como vamos a colocar una máquina en DMZ expuesta al exterior de manera continuada y que otorga acceso a toda la red, este paso no es una opción y llevándolo acabo minimizaremos las posibilidades de encontrarnos con una desagradable sorpresa.

Una acción por defecto a llevar a cabo independientemente de los puntos que voy a comentar a continuación es mantener nuestro sistema actualizado. Por defecto, las imágenes de Ubuntu Server desplegadas en Azure llevan habilitado el unattended-upgrades para todas aquellas actualizaciones marcadas como de seguridad. En principio esto es suficiente.

Entremos en materia del resto de elementos.

Protegiendo SSH de ataques de fuerza bruta y DoS

El primer punto vulnerable del sistema es el SSH, y dado que lo tenemos publicado en su puerto estándar, el TCP/22, podéis estar más que seguros que en pocas horas comenzará a ser víctima de ataques de fuerza bruta para conseguir acceso a la máquina.

Las acciones necesarias para proteger este punto son:

• Mantener el servidor SSH y el kernel de Linux al día.
• Utilizar nombres de usuario que no sean obvios. Deshabilitar el login directo de root por SSH es una gran idea. Ubuntu ya viene configurado de esta forma.
• Utilizar contraseñas con cierto nivel de complejidad.
• Desplegar fail2ban.

Llevar a cabo este último es muy muy trivial:

$ sudo apt install fail2ban

Se nos instala con la configuración por defecto y nuestro sistema queda protegido, pero no está de más darle un punto más:

$ sudo nano /etc/fail2ban/jail.conf

Buscamos dentro de DEFAULT la directiva bantime, que por defecto es 600 segundos. Servidor suele incrementarla a un valor más razonable como 84600 segundos. Así que cualquier intento de inicio de sesión que falle la contraseña más de 5 veces en un periodo de 600 segundos obtiene una regla REJECT en iptables que durará 84600 segundos.

¿Muy agresivo? Utiliza la directiva ignoreip para establecer un rango de direcciones en tu LAN que quieren que estén exentas de esta inspección.

Por último reiniciamos el servicio para aplicar la configuración modificada:

$ sudo systemctl restart fail2ban

SoftEther VPN, configuración de bajo nivel

Algunas configuraciones de hardening de SoftEther VPN no están disponibles desde la interfaz de administración y tenemos que ir directamente al archivo de configuración. El archivo de configuración no se puede modificar con el servidor arrancado, ya que el tal caso sobre-escribe cualquier cambio que hagamos.

Así pues lo primero es detener el servicio:

$ sudo systemctl stop vpnserver
$ sudo nano /usr/local/vpnserver/vpn_server.config

Buscamos las siguientes configuraciones y las modificamos.

Desactivar el Dynamic DNS

Si montamos SoftEther VPN en casa o una oficina pequeña, esto hace nuestras delicias pues lleva un sistema de DDNS gratuito que nos da un nombre miequipo.softether.net que apunta siempre a nuestra IP aunque sea dinámica.

Sin embargo, no queremos esto en una implementación enterprise. Lo desactivamos realizando la siguiente configuración:

 declare DDnsClient
 {
       bool Disabled true

Esta acción también nos deshabilita automáticamente el VPN Azure, no confundir con Microsoft Azure.

Deshabilitar SSL 3.0, TLS 1.0 y TLS 1.1

Como ya sabréis, el SSL 3.0, TLS 1.0 y TLS 1.1 ya no son considerados protocolos de cifrado seguros, por lo que es una estupenda idea instruir a SoftEther VPN que se ciña únicamente al protocolo TLS 1.2. Para ello dejar las siguientes directivas tal cual especifico en la sección ServerConfiguration:

 declare ServerConfiguration
 {
       bool AcceptOnlyTls true
       bool Tls_Disable1_0 true
       bool Tls_Disable1_1 true
       bool Tls_Disable1_2 false

Activar EAP-MSCHAP V2 para autenticación RADIUS

SoftEther VPN usa por defecto PAP (Password Authentication Protocol) para realizar la autenticación RADIUS, cosa que es muy mala idea, puesto que PAP trasmite las contraseñas en claro. Afortunadamente, en el momento de negociar el protocolo con el servidor, configuramos NPS para no aceptar PAP, pero necesitamos especificar a SoftEther VPN que utilice EAP.

Para ello buscamos y aplicamos la configuración de nuestro VirtualHUB:

 declare VirtualHUB
 {
       declare AZURE
       {
             bool RadiusConvertAllMsChapv2AuthRequestToEap true
             bool RadiusUsePeapInsteadOfEap false

Hay un tema extremadamente importante a tener en cuenta en esta configuración. Fijáos que dice "ConvertAllMsChapv2AuthRequestToEap". Esto quiere decir que si cliente VPN con el que estamos conectando especifica que quiere usar MsChapv2, SoftEther VPN automáticamente convierte la solicitud en EAP-MSCHAP V2. Esto funciona bien con la mayoría de clientes.

Sin embargo, algunos clientes VPN como el de iOS siguen ofertando PAP entre la lista de protocolos admitidos durante la negociación de la conexión. Esto hace que SoftEther VPN negocie PAP como protocolo de autenticación y se lo transfiera al NPS donde es rechazado. La idea es que SoftEther VPN puede soportar solicitudes PAP y EAP-MSCHAP V2.

De momento este problema de autenticación no tiene solución, ya que activar PAP no es una opción. Como workaround, los usuarios que tengan necesidad de conectar desde clientes que presentan este problema con RADIUS se les puede crear una cuenta de usuario local en SoftEther VPN.

Finalizando en hardening

Ya guardamos el archivo /usr/local/vpnserver/vpn_server.config y ya podemos volver a arrancar el servidor:

$ sudo systemctl start vpnserver

No olvidéis que es buena idea deshabilitar todos los protocolos y puertos de escucha que no necesitéis en la administración gráfica de SoftEther VPN.

Listos para conectar

Si todo ha ido bien, podemos configurar nuestro Windows con el cliente nativo de SSTP y conectar a nuestra flamante VPN en Azure con autenticación basada en Active Directory. Además, dispositivos antes no soportados -como teléfonos móviles- ya pueden conectarse utilizando L2TP/IPsec.

Happy tunneling!