RADIUS en Wi-Fi - Centraliza tu seguridad de red

Un servidor RADIUS centraliza la autenticación, la autorización y el registro de actividad para que el acceso a la red no dependa de reglas dispersas en cada punto de acceso, switch o VPN. En una infraestructura de Wi‑Fi y redes corporativas esto reduce errores, simplifica el alta y la baja de usuarios y deja trazabilidad real de quién entró, cuándo y desde dónde. Si trabajas con seguridad, además, es una de esas piezas que marcan la diferencia entre una red administrable y una red que se va llenando de excepciones.

Qué resuelve realmente RADIUS en una red

El valor de RADIUS no está solo en “dejar entrar o no dejar entrar” a un usuario. Su papel es más amplio: concentra las decisiones de acceso para que la red aplique las mismas reglas en todos los puntos donde alguien intenta conectarse. Eso incluye quién se autentica, qué permisos obtiene y cómo queda registrado su paso por la infraestructura.

Yo lo explico así: un punto de acceso o un switch no debería guardar criterios de negocio ni políticas de seguridad complejas en local. Es mejor que actúe como intermediario y pregunte a un sistema central. Así, si cambias una política de acceso, desactivas una cuenta o ajustas una VLAN, no tienes que perseguir equipo por equipo para replicar la modificación.

En la práctica, esto es especialmente útil cuando conviven varios tipos de acceso: Wi‑Fi corporativo, cableado con control por puerto, VPN para teletrabajo y, en algunos entornos, acceso de invitados o partners. Si todo pasa por el mismo modelo de AAA, la auditoría también se vuelve más limpia. Y cuando una red se investiga por un incidente, ese detalle ahorra horas.

Para entender por qué esto encaja tan bien en Wi‑Fi, conviene seguir el recorrido de una conexión real y ver qué hace cada pieza del flujo.

Cómo viaja una autenticación en una red Wi‑Fi

El mecanismo básico está muy bien definido en el RFC 2865 para autenticación y autorización, y en el RFC 2866 para accounting. La idea no cambia mucho de una implementación a otra: el dispositivo que controla el acceso, normalmente un punto de acceso, actúa como cliente RADIUS y reenvía la petición al servidor central.

En un despliegue Wi‑Fi con 802.1X, el cliente no habla “directamente” con la base de datos de usuarios. Primero se asocia al SSID, luego el AP encapsula el intercambio en RADIUS y el servidor decide si la sesión se acepta, se rechaza o necesita un paso adicional. Esa capa intermedia permite usar métodos EAP, que soportan varios esquemas de autenticación sin tener que programar cada uno en el equipo de acceso.

Hay cuatro piezas que conviene tener claras:

• NAS o cliente RADIUS: el equipo de red que recibe la solicitud, como un AP, un switch o una VPN.
• Servidor central: consulta la identidad, aplica políticas y responde con la decisión de acceso.
• Shared secret: la clave compartida entre cliente y servidor para validar el intercambio y evitar peticiones sueltas sin confianza mutua.
• Accounting: el registro de eventos de conexión, útil para auditoría, capacidad y análisis forense.

El tráfico se transporta sobre UDP y los puertos oficiales son 1812 para autenticación y 1813 para accounting. Eso no significa que el diseño sea “simple” sin más: UDP obliga a pensar bien los reintentos, los timeouts y la tolerancia a fallos, porque no tienes la fiabilidad de una sesión TCP mantenida por el propio protocolo.

Microsoft Learn resume este modelo de forma clara cuando describe a los puntos de acceso y switches como clientes RADIUS y al servidor como el punto central de decisión. En una red bien montada, ese patrón se repite una y otra vez sin que el usuario tenga que pensar en él. Y precisamente ahí está su fuerza.

Con este flujo claro, ya se ve mejor en qué escenarios aporta más valor y dónde no conviene forzarlo.

Dónde encaja mejor en redes y Wi‑Fi

No todos los casos de uso necesitan la misma profundidad de control. RADIUS brilla cuando hay identidades, políticas y trazabilidad que centralizar, pero no siempre es la herramienta adecuada para resolver cualquier forma de acceso.

Un matiz importante: RADIUS no cifra el tráfico de usuario ni “protege la Wi‑Fi” por sí solo. Lo que hace es controlar acceso y registrar eventos. Si la red está mal segmentada, si las claves compartidas se reutilizan sin criterio o si la política es demasiado permisiva, el sistema seguirá siendo frágil aunque el servidor esté bien montado.

Por eso, antes de elegir software, merece la pena comparar opciones y decidir cuál encaja mejor con el entorno real.

Qué solución elegir según tu entorno

La mejor plataforma no es la que tiene más nombre, sino la que encaja con tu identidad corporativa, tu equipo y tu nivel de exigencia operativa. Yo suelo separar la decisión en tres caminos: open source flexible, integración nativa con Windows o servicio gestionado.

Si ya trabajas con Active Directory, NPS suele ser una ruta razonable. Si tu red mezcla fabricantes, varias sedes o reglas más sofisticadas, FreeRADIUS suele dar más juego. Y si no tienes equipo para operar la capa de AAA con calma, un servicio gestionado puede tener sentido, aunque yo solo lo elegiría cuando la reducción de carga compense de verdad la pérdida de control.

Elegir la plataforma ayuda, pero la puesta en marcha es lo que decide si el sistema aguanta en producción o empieza a dar problemas desde la primera semana.

Cómo implantarlo paso a paso sin improvisar

La mayoría de los fallos en RADIUS no aparecen porque el protocolo sea malo, sino porque se monta deprisa y sin una lógica clara de operación. Si quieres que funcione en serio, yo seguiría este orden.

1. Define la fuente de identidad. Decide si vas a autenticar contra Active Directory, LDAP, una base local o un IdP externo. Si no está claro desde el principio, luego aparecen reglas duplicadas y excepciones difíciles de mantener.
2. Inventaría todos los clientes RADIUS. APs, switches, controladoras, VPN y cualquier otro NAS deben estar identificados por IP, ubicación y función.
3. Asigna secretos compartidos distintos. No reutilices la misma clave en toda la infraestructura si puedes evitarlo. Separar por sede o por tipo de equipo reduce el impacto de una filtración.
4. Elige bien el método de EAP. EAP-TLS usa certificados y suele ofrecer mejor nivel de seguridad; PEAP es más común en despliegues donde todavía hay dependencias de usuario y contraseña. La diferencia importa mucho en Wi‑Fi empresarial.
5. Define políticas por contexto. No basta con “permitir” o “bloquear”. Conviene decidir qué grupo entra, a qué VLAN va, con qué horario, desde qué tipo de equipo y con qué nivel de acceso.
6. Activa accounting desde el principio. Registrar inicios, cierres y errores facilita auditoría, capacidad y detección de anomalías.
7. Prueba con un segmento pequeño. Yo prefiero validar primero un SSID, un grupo de usuarios o un conjunto limitado de puertos antes de abrirlo a toda la empresa.
8. Documenta el plan de respaldo. Si el servidor primario cae, alguien debe saber qué servidor toma el relevo y qué pasa con las sesiones activas.

Un detalle que mucha gente subestima es la sincronización horaria. Cuando hay certificados, trazabilidad y validaciones temporales, un desfase de reloj puede romper la autenticación aunque todo lo demás parezca correcto. Y eso nos lleva a los errores que más se repiten cuando el sistema ya está funcionando.

Los fallos que más cuestan en producción

Los problemas más caros no suelen ser espectaculares. Casi siempre son pequeños errores de diseño, de operación o de mantenimiento que se repiten hasta que un día dejan a media red sin acceso.

• Reutilizar el mismo secreto compartido en todos los equipos: si uno se filtra, comprometes demasiado.
• Olvidar la caducidad de certificados: en EAP-TLS, un certificado vencido puede dejar fuera a usuarios o dispositivos legítimos de forma repentina.
• Ignorar la hora del sistema: la validación de certificados y los registros de auditoría dependen de relojes alineados.
• Crear políticas demasiado permisivas: una regla de “permitir por si acaso” suele convertirse en una puerta abierta que nadie recuerda revisar.
• Usar MAC auth como si fuera seguridad fuerte: la autenticación por MAC puede ser útil para inventario o automatización, pero no es un control robusto por sí sola.
• No probar la caída del servidor secundario: tener redundancia escrita en un documento no significa que vaya a funcionar cuando haga falta.
• Dejar el accounting desactivado: sin registros, investigar incidentes o demostrar cumplimiento se vuelve mucho más difícil.
• No limitar el acceso de red entre clientes y servidor: los puertos RADIUS no deberían quedar expuestos más de la cuenta ni mezclarse con redes no confiables.

En seguridad, estas pequeñas omisiones cuestan más que un error visible porque dan una falsa sensación de control. Una red puede funcionar “bien” durante meses y, sin embargo, estar mal preparada para un incidente, una auditoría o un cambio de personal. Por eso yo cerraría la instalación con algo más que una prueba rápida.

Lo que yo dejaría cerrado antes de ponerlo en producción

Si tuviera que entregar una infraestructura RADIUS lista para uso real, no me quedaría solo con que el login responda. Revisaría la alta disponibilidad, la renovación de certificados, la caducidad de cuentas, el esquema de logs y la forma en que se documentan los cambios. También comprobaría que la política de acceso sea coherente con el principio de mínimo privilegio, porque una autenticación centralizada no compensa una autorización mal pensada.

Mi criterio es simple: en una red bien diseñada, RADIUS no se nota cuando todo va bien, pero sí se echa en falta en cuanto intentas escalar, auditar o endurecer el acceso. Si el objetivo es una Wi‑Fi corporativa más segura, el valor real no está en “tener un servidor”, sino en construir un sistema de identidades que puedas sostener sin improvisar. Cuando eso está bien resuelto, la red deja de depender de excepciones y empieza a comportarse como una infraestructura seria.