Problema

Muchas pymes y oficinas remotas utilizan los dispositivos Meraki MX como puerta de enlace VPN. Desde hace poco, Meraki permite túneles IKEv2/IPsec, que son mucho más rápidos que los basados en TLS/DTLS. El inconveniente habitual es que la autenticación se limita a usuario y contraseña contra un servidor RADIUS, sin soporte nativo para MFA ni para certificados de cliente. En entornos donde la identidad está gestionada por Azure AD/Entra ID, los administradores buscan una forma de exigir MFA antes de que el RADIUS acepte la conexión, pero sin adquirir licencias de AnyConnect Premium o desplegar una infraestructura AD completa.

El patrón que se repite es: una VPN basada en IKEv2/IPsec que necesita MFA, pero el appliance solo habla RADIUS. La solución debe ser económica, reutilizar los servicios de identidad ya existentes y no añadir complejidad operativa significativa.

Causa

  1. Limitación del appliance – Los MX de Meraki exponen únicamente un servidor RADIUS para la fase de autenticación de IKEv2. No hay hook para MFA ni para validar certificados de cliente.
  2. Separación de identidad y acceso – Azure AD/Entra ID gestiona usuarios y MFA, pero no expone un endpoint RADIUS nativo. La integración típica es mediante NPS (Network Policy Server) que actúa como traductor RADIUS → Azure AD.
  3. Dependencia de licencias – Las opciones oficiales de MFA para VPN (por ejemplo, AnyConnect Premium) requieren licencias adicionales que resultan costosas para presupuestos ajustados.
  4. Falta de cliente certificado – Meraki no permite validar certificados X.509 en IKEv2, lo que elimina una vía de autenticación fuerte sin MFA.

Solución

Arquitectura recomendada

  1. NPS con Azure MFA Extension – Instala un servidor Windows Server (puede ser una VM ligera en Azure) con el rol NPS y la extensión Azure MFA Server (o Azure MFA NPS Extension). Esta combinación permite que NPS reciba peticiones RADIUS desde el MX y, antes de responder, invoque Azure AD para validar MFA.
  2. Azure AD Application + Service Principal – Registra una aplicación en Azure AD que tenga permiso para leer el estado de autenticación del usuario. La extensión MFA usa este cliente para lanzar el desafío (push, OTP, etc.).
  3. Configuración del MX – Apunta el servidor RADIUS del MX al NPS. En la política de red del MX, especifica el método de autenticación como RADIUS y habilita IKEv2/IPsec.
  4. Política NPS – Crea una política que acepte los grupos de usuarios que deben usar la VPN y habilita la opción “Microsoft: Require authentication”. La extensión interceptará la solicitud y forzará MFA.
  5. Fallback sin MFA – Si algún usuario no está registrado en Azure MFA, la política puede redirigir a una segunda política que permita solo contraseña (útil para cuentas de servicio).

Alternativas de bajo costo

  • FreeRADIUS + Azure AD Conditional Access: Usa FreeRADIUS en Linux y un conector como RADIUS Proxy que delega la autenticación a Azure AD mediante OAuth2. Algunas soluciones de código abierto (p.ej., pyrad + msal) pueden montar este flujo, aunque requiere más scripting.
  • Duo Authentication Proxy: Duo ofrece un proxy RADIUS que puede integrarse con Azure AD mediante SAML. La licencia Duo Free permite MFA para un número limitado de usuarios y es suficiente para equipos pequeños.
  • Azure AD Passwordless + Azure VPN Client: Si la política permite, migrar a Azure VPN Client (IKEv2) que soporta Azure AD MFA directamente, eliminando la capa RADIUS. Sin embargo, esto implica cambiar el cliente en los endpoints.

Pasos concretos con NPS + Azure MFA Extension

  1. Provisionar la VM – Windows Server 2022, 2 vCPU, 4 GB RAM, conectada a la misma red virtual que el Azure AD DS (si existe) o con conectividad VPN a la sede.
  2. Instalar NPS – Add-WindowsFeature NPAS.
  3. Descargar e instalar Azure MFA NPS Extension – Disponible en el portal de Microsoft. Durante la instalación, se solicita el Tenant ID, Client ID y Client Secret de la aplicación registrada.
  4. Configurar el cliente RADIUS en Meraki – En el Dashboard, sección Security & SD-WAN > Configure > Client VPN → RADIUS server → IP de la VM, puerto 1812, secreto compartido.
  5. Crear política NPS – En Network Policy Server > Policies > Network Policies, nueva política:
    • Condiciones: grupo de AD (o Azure AD DS) que contiene usuarios VPN.
    • Constraints → Authentication Methods → Microsoft: Protected EAP (PEAP) y marca Enable multi‑factor authentication.
  6. Probar – Desde un cliente Windows 11, iniciar conexión IKEv2 con credenciales. Debería aparecer el prompt de MFA (push o código) antes de que el túnel se establezca.

Cuándo aplicar esta solución

  • Entorno híbrido: Cuando ya se usa Azure AD/Entra para gestión de usuarios y MFA, y se quiere mantener esa fuente de verdad.
  • Presupuesto limitado: La VM de NPS y la extensión son gratuitas; solo se paga por la licencia de Azure AD (incluye MFA) y por la VM mínima.
  • Necesidad de IKEv2: Cuando la velocidad del túnel es crítica y TLS/DTLS no es aceptable.
  • Escenarios donde no se pueden usar certificados: Si la política de la empresa prohíbe la distribución de certificados de cliente.

No aplicar si:

  • La organización ya tiene una infraestructura de PKI y prefiere certificados de cliente.
  • Se requiere MFA basada en hardware token que no está soportado por Azure MFA.
  • La VPN es exclusivamente para usuarios externos sin cuentas en Azure AD.

Código

# Instalar NPS en Windows Server
Install-WindowsFeature -Name NPAS -IncludeManagementTools

# Descargar e instalar la extensión (ejemplo con PowerShell)
$url = "https://download.microsoft.com/download/7/5/2/752A5C0F-6F5A-4D6F-9E9C-9C1A2D5F6E7B/AzureMFAExtension.msi"
Invoke-WebRequest -Uri $url -OutFile "$env:TEMP\AzureMFAExtension.msi"
Start-Process msiexec.exe -ArgumentList "/i `"$env:TEMP\AzureMFAExtension.msi`" /quiet" -Wait

# Registrar la aplicación en Azure AD y obtener los valores
# (Este paso se hace en el portal, luego se rellenan los parámetros en la extensión)

Verificación

  1. Log de NPS – En el visor de eventos, busca NetworkPolicyServer → Authentication y verifica que la solicitud RADIUS llegue y que la extensión invoque MFA.
  2. Prompt de MFA – Desde el cliente, confirma que aparece el desafío (push, código, llamada).
  3. Estado del túnel – En el Dashboard de Meraki, la sesión VPN debe mostrarse como Active después de la autenticación exitosa.
  4. Fallos controlados – Intenta conectar con credenciales incorrectas o sin MFA habilitado; NPS debe rechazar la petición y el cliente debe recibir access‑reject.

Notas adicionales

  • Sincronización de tiempo: IKEv2 es sensible a desfases de reloj. Asegúrate de que la VM NPS y los MX tengan NTP configurado.
  • Secretos compartidos: Usa una cadena larga y aleatoria; cambia el secreto cada 90 días para cumplir buenas prácticas.
  • Escalabilidad: Si la cantidad de usuarios crece, considera un NPS farm detrás de un balanceador de carga interno.
  • Logs de auditoría: Azure AD registra cada desafío MFA; revisa los logs de Sign‑ins para detectar intentos sospechosos.
  • Compatibilidad de cliente: Windows 11 y macOS soportan IKEv2 con autenticación basada en credenciales; en Linux se necesita strongSwan configurado para RADIUS.

Con esta arquitectura, se consigue un túnel IPsec rápido, MFA integrado y un coste prácticamente nulo, aprovechando los servicios ya presentes en la nube de Microsoft.