802.1X, FreeRADIUS y VLANs dinámicas: guía completa

Informatec Digital » Recursos » 802.1X, FreeRADIUS y VLANs dinámicas: guía completa

Si gestionas redes cableadas o Wi‑Fi y quieres separar el tráfico por tipos de usuario sin meterte en una solución NAC carísima, jugar bien con 802.1X, FreeRADIUS y asignación dinámica de VLANs es de lo más potente que puedes hacer, y conviene entender cómo encaja esto con la arquitectura Zero Trust. Bien montado, te permite decidir a qué red se conecta cada dispositivo en función de quién es, de dónde viene o de qué grupo de directorio pertenece, sin ir creando SSIDs por todas partes ni atarte a un único fabricante.

En este artículo vamos a desgranar de forma muy detallada cómo encaja todo el puzzle: papel de 802.1X, configuración típica de FreeRADIUS, atributos RADIUS para VLANs, integración con controladoras Wi‑Fi y switches, casos reales (Omada, ExtremeCloud IQ, switches clásicos), problemas habituales y hasta temas avanzados como Azure AD o atributos mal formados en LDAP. La idea es que al acabar tengas una visión clara y práctica, y que puedas adaptar lo que veas aquí a tu propia infraestructura, sea pequeña o grande.

802.1X y VLANs dinámicas: conceptos básicos y componentes

El estándar 802.1X es, dicho rápido, el portero de tu red: hasta que el dispositivo no se autentica, el puerto o la Wi‑Fi no le dan paso a la red «buena». Para conseguir segmentación real, se combina con asignación dinámica de VLAN usando atributos RADIUS, de modo que el servidor decide en qué VLAN cae cada cliente tras autenticarse.

En cualquier despliegue 802.1X hay tres piezas clave que siempre aparecen, da igual que uses Omada, ExtremeCloud IQ o switches genéricos:

• Supplicant: el cliente que se quiere conectar (portátil, móvil, impresora “lista”, etc.).
• Authenticator: el equipo de red que controla el acceso (switch, AP o controladora Wi‑Fi) y que habla con el servidor RADIUS.
• Servidor de autenticación: normalmente un RADIUS, muchas veces FreeRADIUS, que valida credenciales y decide política (permitir, denegar, meter en una VLAN u otra).

La magia de las VLANs dinámicas viaja en forma de atributos RADIUS dentro del Access-Accept. Para VLANs, casi todos los fabricantes entienden la combinación de atributos tipo túnel:

• Tunnel-Type = VLAN
• Tunnel-Medium-Type = IEEE-802
• Tunnel-Private-Group-Id = «ID de VLAN» (normalmente un número entre 1 y 4095, aunque se envía como texto)

Cuando el switch o el AP recibe un Access-Accept con esos atributos, si tiene soporte de 802.1X y VLAN dinámica, asigna el puerto o la sesión Wi‑Fi a la VLAN indicada por el RADIUS ignorando la VLAN por defecto del puerto o SSID (salvo que el RADIUS no envíe nada, en cuyo caso aplica su configuración local).

Configuración de FreeRADIUS para VLANs dinámicas

FreeRADIUS es el servidor RADIUS open source por excelencia. Se puede instalar en cualquier Linux modesto, incluso en hardware muy pequeño tipo NanoPi NEO o Raspberry Pi, y con una buena configuración es capaz de manejar entornos muy serios. Para VLANs dinámicas hay dos bloques importantes: definición de usuarios/grupos y colocación correcta de los módulos en la cadena de procesamiento.

En despliegues sencillos, se pueden definir usuarios de prueba directamente en el archivo users de FreeRADIUS, asignándoles ya la VLAN que queremos que reciban. El fichero típico en Debian/Ubuntu está en /etc/freeradius/3.0/users, y las entradas con VLAN quedan de esta forma (simplificada y reescrita):

empleado10 Cleartext-Password := "clave10"
    Service-Type := Framed-User,
    Tunnel-Type := VLAN,
    Tunnel-Medium-Type := IEEE-802,
    Tunnel-Private-Group-Id := "10"

empleado20 Cleartext-Password := "clave20"
    Service-Type := Framed-User,
    Tunnel-Type := VLAN,
    Tunnel-Medium-Type := IEEE-802,
    Tunnel-Private-Group-Id := "20"

Con esa estructura FreeRADIUS devolverá, tras un Access-Accept, los tres atributos túnel para que el NAS (switch o AP) coloque al cliente en la VLAN 10 o 20 según el usuario. El secreto está en que el equipo de red soporte la RFC correspondiente y respete esos atributos por delante de la VLAN de acceso configurada.

En algunos escenarios, como integración con ExtremeCloud IQ, es fundamental que esos atributos se envíen exactamente en el Access-Accept, y no sólo como atributos “tunneled” en otras fases del EAP. En configuraciones por defecto, FreeRADIUS puede procesar primero el módulo eap y después el módulo files (que es el que lee el archivo users). Esto provoca que la controladora no vea los atributos en el momento adecuado.

La solución práctica que se ha demostrado útil es ajustar el archivo /etc/freeradius/3.0/sites-enabled/default, moviendo el módulo files por delante de eap dentro del bloque authorize. De esta manera, FreeRADIUS carga primero los atributos estáticos de usuario (incluyendo VLAN) y luego gestiona el EAP, de forma que al construir el Access-Accept final se incluyen los atributos de túnel donde la controladora los espera.

Otro ajuste recomendable es desactivar métodos de EAP débiles como EAP-MD5, que nunca se pensaron para entornos productivos. Editando el fichero /etc/freeradius/3.0/mods-enabled/eap y comentando o eliminando la sección MD5, FreeRADIUS dejará de ofrecerlo. Es buena idea centrar la configuración en métodos robustos como EAP-TLS (certificados) o PEAP con MSCHAPv2.

Asignación de VLAN con Omada: RADIUS interno y FreeRADIUS externo

El ecosistema Omada de TP‑Link (controladora + switches + AP) integra muy bien 802.1X con VLAN dinámica, tanto usando su RADIUS interno como delegando en un FreeRADIUS externo. Es un caso muy ilustrativo porque se ve claramente el flujo completo.

Para usar el RADIUS incorporado en la controladora Omada, se suele seguir un proceso en tres grandes pasos. Primero, en el menú global de la controladora se habilita el RADIUS integrado, indicando la IP (la de la propia controladora) y activando la opción de Tunneled Reply para que envíe correctamente los atributos de túnel al equipo de acceso.

Después, ya en el sitio concreto, se entra en Settings > Profile > RADIUS Profile, se edita el perfil y se crean usuarios RADIUS internos. Para cada usuario, Omada permite fijar un nombre, contraseña y VLAN ID, de forma que cuando ese usuario se autentique, será la controladora quien devuelva los atributos VLAN al switch o al AP sin pasar por un servidor externo.

Por último, en Settings > Authentication > 802.1X se activa el 802.1X, se selecciona el perfil RADIUS interno y se habilita explícitamente la opción de VLAN Assignment. En el mismo apartado se marcan los puertos del switch que requerirán autenticación 802.1X. Tras guardar, cualquier dispositivo que conecte a esos puertos deberá autenticarse y, si la cuenta tiene un VLAN ID asignado, se colocará en dicha VLAN de forma automática.

Si preferimos centralizar todo en un FreeRADIUS externo, Omada soporta perfectamente ese escenario. El primer paso es editar el archivo clients.conf en el servidor FreeRADIUS para autorizar a la controladora (o al rango donde estén los switches/AP) como cliente RADIUS, indicando IP o subred y el shared secret que más tarde configuraremos en Omada.

Luego, de nuevo en Omada, se crea un RADIUS Profile externo desde Settings > Profiles > RADIUS Profile, donde se introduce la IP del FreeRADIUS, el puerto de autenticación (1812 normalmente) y la contraseña compartida. En la configuración de 802.1X de la controladora se selecciona este perfil externo y se vuelve a activar VLAN Assignment, marcando los puertos o SSIDs que queramos proteger.

La comprobación posterior se puede hacer desde la propia controladora: en Tools > Terminal se abre una consola contra el switch que tiene 802.1X activado y se ejecuta el comando show dot1x auth-state. Si todo está bien, se verá el puerto autenticado y la VLAN asignada por RADIUS (por ejemplo, un puerto 1/0/1 autenticado y asociado a VLAN 2).

VLAN dinámica en Wi‑Fi con FreeRADIUS y ExtremeCloud IQ

Otro caso muy completo es el de redes Wi‑Fi gestionadas por ExtremeCloud IQ (XIQ) usando FreeRADIUS como servidor de autenticación. Aquí la VLAN dinámica se asigna sobre todo a clientes Wi‑Fi según atributos de túnel que devuelve FreeRADIUS.

Primero se prepara FreeRADIUS para enviar esos tres atributos en el Access-Accept, igual que antes: entradas en /etc/freeradius/3.0/users con usuarios y sus VLANs, y el ajuste en sites-enabled/default para que el módulo files se procese antes que eap, ya que XIQ espera los atributos exactamente en el Accept.

Es muy recomendable dejar desactivado EAP-MD5 y usar métodos como PEAP/EAP-TLS. Tras modificar el fichero de configuración EAP, se reinicia el servicio con un systemctl restart freeradius para aplicar los cambios. A partir de ahí, el servidor estará listo para responder a las peticiones que le envíen los AP gestionados por XIQ.

Por la parte de la nube de Extreme, hay dos tipos de cuenta relevantes: la gratuita Connect, que permite gestión básica de hasta diez dispositivos pero no soporta reglas de clasificación avanzadas para VLANs dinámicas, y la versión Pilot, que ofrece prueba de 90 días y sí habilita todo el juego de perfiles y reglas basadas en atributos RADIUS.

Con la cuenta Pilot, se crea una Network Policy nueva desde el menú «Configure > Network Policies», se le da nombre y se elige que sólo sea para Wi‑Fi para simplificar. En el segundo paso se define el SSID, normalmente como red Enterprise con WPA2 o WPA3, y se asocia un RADIUS Group. Al crear ese grupo se añade el FreeRADIUS como servidor externo, indicando IP, secret y puertos 1812/1813.

Después se configuran los User Profiles, que son, en la práctica, perfiles de acceso vinculados a distintas VLAN (por ejemplo, VLAN10 y VLAN20). Existe un perfil por defecto al que irán a parar los clientes cuyo RADIUS no devuelva atributos de túnel, pero para VLAN dinámica se marcan reglas de asignación basadas en el valor de Tunnel-Private-Group-ID y otros atributos RADIUS.

Las reglas simplemente dicen: «si el Tunnel-Private-Group-ID que viene en el Accept es 10, asigna el User Profile VLAN10»; si es 20, asigna el User Profile VLAN20, y así sucesivamente. ExtremeCloud IQ traduce esas reglas en la práctica a colocar al cliente en la VLAN que coincide con el atributo enviado desde FreeRADIUS.

Por último, hay que dar acceso a esas VLAN en el lado cableado del AP, ajustando el perfil de AP en XIQ para que el puerto de uplink permita todas las VLAN configuradas y mantenga la nativa (normalmente VLAN 1). Una vez guardado todo y aplicada la Network Policy a los AP, se puede usar la herramienta de RADIUS Test integrada en XIQ para comprobar que FreeRADIUS está accesible y que el servidor devuelve el atributo de VLAN esperado para cada usuario.

Omada SDN con FreeRADIUS: VLANs para cable e inalámbrico

La solución SDN de Omada también permite asignar VLANs dinámicas a la vez en redes inalámbricas y cableadas usando un RADIUS externo como FreeRADIUS. Esto evita tener que crear muchos SSID diferentes o jugar con PVIDs fijos en los puertos del switch.

La topología típica incluye controladora Omada, puntos de acceso EAP, switches JetStream y el servidor FreeRADIUS sobre Linux. Para que los equipos de red puedan enviar peticiones de autenticación al servidor, se edita el fichero clients.conf fijando como cliente el rango de red de los Omada (por ejemplo, 192.168.0.0/24) y un password compartido.

Después se preparan las cuentas en el fichero users, definiendo por ejemplo dos usuarios: uno para VLAN10 y otro para VLAN20, con sus respectivos atributos Tunnel-Type, Tunnel-Medium-Type y Tunnel-Private-Group-Id. En WPA-Enterprise es frecuente tocar también el archivo de configuración EAP para adaptar el método al tipo de clientes (por ejemplo, EAP-PEAP para portátiles Windows).

Desde la controladora Omada, en el apartado de autenticación se crea un RADIUS Profile apuntando al FreeRADIUS, y se marca la opción Enable VLAN Assignment for Wireless Network. Eso hace que, cuando un cliente se autentique vía WPA-Enterprise, Omada consulte el RADIUS y coloque al dispositivo en la VLAN devuelta por el servidor en lugar de en la VLAN fija del SSID.

Es necesario, además, definir las propias interfaces VLAN de la red en Settings > Wired Networks > LAN, creando por ejemplo dos interfaces lógicas para VLAN10 y VLAN20 con sus puertas de enlace IP. Así, cuando un cliente caiga en VLAN10, obtendrá un IP dentro del rango de esa VLAN, y lo mismo para VLAN20.

En el plano inalámbrico, se crea un SSID con WPA-Enterprise apuntando al perfil RADIUS. Al conectarse un cliente y autenticarse como, por ejemplo, test10, el usuario recibirá una IP de VLAN10; si utiliza test20, caerá en VLAN20, sin que tengamos que crear un SSID específico para cada caso.

En el lado cableado, la lógica es similar pero utilizando 802.1X Port-Based. Se habilita el 802.1X en la sección correspondiente de la controladora, se selecciona el tipo «Port Based», se activa «VLAN Assignment» y se marcan los puertos que requerirán autenticación. Sobre esos mismos puertos se aplica un port profile que añade las VLAN10 y VLAN20 como redes untagged, asegurando que el modo de control 802.1X esté en «Auto» para que el switch haga la negociación cuando detecta un cliente.

Así, con una sola configuración de RADIUS y un par de perfiles, Omada SDN consigue que tanto el usuario cableado como el Wi‑Fi acaben en su VLAN correspondiente según las credenciales, sin tener que multiplicar redes o tocar manualmente la configuración de cada puerto.

Casos prácticos, errores frecuentes y trucos de configuración

Trabajando con FreeRADIUS y VLAN dinámica no todo son rosas: hay varios problemas recurrentes que aparecen en cuanto se pasa de pruebas de laboratorio a entornos reales, sobre todo cuando entran en juego directorios LDAP/AD, formatos de nombre de usuario y políticas complejas, por lo que una buena gestión de riesgos de ciberseguridad ayuda a reducir incidencias.

Un fallo muy típico ocurre cuando el servidor arma una consulta LDAP usando el atributo %{User-Name} tal como llega en el RADIUS. En muchos escenarios Windows, el formato llega como DOMINIO\usuario, con la barra invertida codificada como \5c. Si la plantilla LDAP se construye con uid=%{User-Name}, la query resultante será algo como uid=DOMINIO\5cusuario, que rara vez coincide con el uid real en el árbol LDAP, devolviendo cero resultados.

Eso implica que no se encuentran los atributos del usuario en el directorio, incluido el posible valor de VLAN o grupo que se quiera mapear, por lo que el servidor no añade Tunnel-Private-Group-Id y el cliente se queda en la VLAN por defecto del switch o AP. En los logs de FreeRADIUS se ve claramente este patrón: consulta LDAP con uid «dominio\5cusuario» y salida de búsqueda vacía.

La solución práctica que se ha utilizado con éxito es cambiar en la configuración de FreeRADIUS el uso de %{User-Name} por %{Stripped-User-Name} en la plantilla de consulta LDAP, p. ej.:

if ("%{ldap:ldap:///dc=ejemplo,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }

De este modo, FreeRADIUS emplea el nombre de usuario «limpio», sin dominio ni barra, y las búsquedas vuelven a dar resultado. En cuanto LDAP devuelve la entrada correcta, el servidor puede aplicar la lógica para asignar VLANs basadas en grupo, OU o atributos específicos, generando de nuevo Tunnel-Type, Tunnel-Medium-Type y Tunnel-Private-Group-Id en el Access-Accept.

Otro caso curioso se da con algunos switches cuando se mezcla configuración estática de VLAN en el puerto con 802.1X dinámico. Por ejemplo, tener el puerto 17 en la VLAN 4 estática y, al mismo tiempo, pretender que RADIUS fuerce a un usuario concreto a la VLAN 2. Si el equipo no respeta los atributos de túnel o la función de VLAN dinámica está deshabilitada, pase lo que pase en RADIUS, el puerto seguirá viendo tráfico como VLAN 4.

En ese tipo de situaciones es crucial revisar la documentación del switch para activarle explícitamente el soporte de VLAN assignment via RADIUS, y depurar con comandos como show dot1x o equivalentes, verificando si el equipo comenta algo tipo «ignoring tunnel attributes» o «dynamic vlan assignment disabled». Sólo cuando el fabricante lo soporta y está habilitado se logrará que un usuario conectado a un puerto físico en VLAN 4 por defecto acabe realmente en VLAN 2 tras autenticarse como «carlos» o quien sea.

También hay debates clásicos sobre la idoneidad de usar VLAN dinámica en escenarios con Remote Desktop (RDP). Cuando se hace autenticación de equipo al arrancar Windows y luego autenticación de usuario al iniciar sesión, el cambio de VLAN que provoca el login del usuario puede cortar sesiones RDP en curso o provocar problemas de DNS mientras el puerto salta de la VLAN «de máquina» a la VLAN «de usuario». Más de un administrador ha optado por mantener una única VLAN para todos los estados en estos casos, o por asignar la misma VLAN a nivel de equipo y usuario, reduciendo al mínimo los cambios de segmento.

Por último, a nivel de integración avanzada, hay interés creciente en ligar FreeRADIUS con Azure AD para determinar la VLAN según pertenencia a grupos en la nube. A día de hoy no existe un módulo oficial nativo que haga «group lookup» directo en Azure AD para VLANs, y las aproximaciones pasan por scripts externos, llamadas a Microsoft Graph API y algo de trabajo de pegamento. Es un campo en movimiento, y si se necesita algo estable y soportado muchas veces se termina delegando esa lógica en un NAC comercial o en otra pieza intermedia.

Combinando bien 802.1X, FreeRADIUS y la asignación dinámica de VLANs se puede conseguir una segmentación fina de la red sin necesidad de soluciones NAC pesadas, lo que encaja dentro de una estrategia de seguridad tecnológica en empresas: desde controladoras como Omada u ExtremeCloud IQ hasta switches de gama media, todo puede colaborar si se respetan los atributos de túnel, se cuidan las consultas a LDAP/AD y se tiene claro cuándo conviene o no mover dinámicamente a los usuarios de una VLAN a otra según su identidad, su rol o el tipo de dispositivo que conectan.