PacketFence es una plataforma NAC para controlar el acceso de usuarios y dispositivos a redes cableadas y Wi-Fi. Reúne autenticación, políticas de acceso, invitados e integración con la infraestructura. Add Solution apoya la evaluación, la arquitectura, el piloto y la implementación segura.
Add Solution parte del entorno real: identidades, endpoints, modelos y firmware, VLAN, RADIUS, portal de invitados, contingencia y operación.
Asociar el acceso a la identidad del equipo o del usuario. En un parque gestionado, la evaluación debe considerar la autenticación mediante certificados, la distribución centralizada del perfil de red y la retirada del acceso ante la baja del usuario o la pérdida del dispositivo.
Ofrecer una vía de entrada con plazo, responsable y permisos definidos. Para un contratista que necesita un sistema interno, la pregunta es qué destinos se habilitarán, durante cuánto tiempo y quién aprueba esa excepción.
Organizar el uso de dispositivos personales sin mezclar ese acceso con el de los equipos corporativos. El diseño debe considerar los sistemas operativos, la privacidad, el soporte al usuario y lo que ocurre cuando el dispositivo deja de utilizarse.
Reducir las autorizaciones permanentes e indiscriminadas. Los equipos sin autenticación robusta necesitan registro, responsable, acceso restringido a los servicios necesarios y criterios de revisión. En entornos sensibles, el riesgo de interrupción exige una evaluación conjunta con operaciones.
Definir una política común, preservando las diferencias de aplicación en cada equipo. La implementación puede comenzar por una red, SSID o grupo de puertos, con una ampliación condicionada a los resultados del piloto.
El proyecto debe convertir las reglas de seguridad en accesos administrables: permisos coherentes, altas y bajas organizadas, diagnóstico objetivo, implementación gradual y continuidad documentada. El inventario, los riesgos y la capacidad operativa definen el alcance y los criterios de aceptación.
En 802.1X, el endpoint presenta su identidad, el equipo de red transporta la autenticación mediante RADIUS y aplica la autorización recibida. El resultado debe confirmarse en el equipo, en el direccionamiento y en el tráfico permitido.
El endpoint presenta la identidad prevista del usuario, dispositivo o certificado.
En el flujo 802.1X, el autenticador transporta la conversación EAP mediante RADIUS y recibe la decisión de autenticación y autorización.
El contexto, el grupo, el dispositivo y la ubicación determinan el resultado esperado para esa conexión.
El NAS aplica una VLAN, un rol, una ACL u otro mecanismo nativo documentado y admitido.
El estado del equipo, el direccionamiento y el tráfico permitido confirman el acceso efectivo.
Es una opción prioritaria para evaluar en dispositivos gestionados. La autenticación utiliza certificados y reduce la dependencia de contraseñas introducidas para acceder a la red. Exige una PKI bien operada y perfiles distribuidos correctamente. La negociación de TLS también debe ser compatible entre los clientes y el servidor. EAP-TLS con TLS 1.3.
Pueden satisfacer requisitos de compatibilidad, pero deben elegirse teniendo en cuenta el directorio y los sistemas operativos utilizados. En Windows, Credential Guard puede afectar al uso de las credenciales de sesión en métodos basados en MS-CHAPv2. La revisión debe buscar un método adecuado al parque, preservando las protecciones del endpoint. EAP en Windows.
Puede permitir el acceso de equipos sin supplicant. La dirección MAC funciona como identificador y puede suplantarse; no ofrece la misma garantía de identidad que un certificado. Por ello, recomendamos excepciones delimitadas, inventario y segmentación restrictiva. El comportamiento de prioridad y fallback entre 802.1X y MAC debe validarse en el modelo utilizado. Limitaciones y diseño de MAB.
PacketFence ofrece opciones como autorregistro, aprobación por patrocinador y confirmación por correo electrónico o SMS. La elección depende de la experiencia deseada y los servicios disponibles. Invitados y BYOD. El acceso mediante el portal debe evaluarse junto con el aislamiento de la red, la duración del acceso y la autenticación utilizada en el enlace Wi-Fi. El formulario, por sí solo, no define estos controles.
EAP-TLS exige gestionar el ciclo de vida de los certificados: emisión, distribución, vigencia, renovación y revocación. La homologación debe confirmar la identidad, la cadena de confianza, la finalidad del certificado y el comportamiento ante la caducidad o la indisponibilidad de la PKI.
En el control fuera de banda, el endpoint se comunica con los servicios permitidos a través del equipo de red, o NAS, y de la infraestructura de producción. En una rama separada, el NAS intercambia mensajes RADIUS de autenticación y autorización con PacketFence. PacketFence utiliza identidad y confianza, como directorio y certificados, según el método. El NAS aplica la autorización. El tráfico de producción no atraviesa PacketFence. Esquema conceptual sin datos de una instalación real.
En el modelo fuera de banda, PacketFence decide la autorización y el equipo de red la aplica. El tráfico de producción permanece en la infraestructura. El diseño debe validar RADIUS, VLAN, ACL, accounting, cambios de autorización y contingencia en cada equipo.
En modo inline, PacketFence se sitúa en la ruta del tráfico de la red controlada. Puede atender a equipos sin mecanismos adecuados de aplicación de políticas, pero añade requisitos de capacidad y continuidad. Arquitectura inline. La evaluación debe incluir el throughput real, los picos de tráfico, las interfaces, la latencia y el impacto del mantenimiento. La elección debe ser consciente, especialmente cuando el mismo entorno depende de esa ruta para acceder a sistemas esenciales.
Es posible trabajar con RADIUS only, sin los flujos de registro, aislamiento y portal de ese modo de implementación, o combinar mecanismos según el segmento atendido. Modos admitidos. En proyectos distribuidos, conviene decidir dónde se ubican la autenticación, el portal y las dependencias de identidad. La conectividad entre sedes, el comportamiento ante fallos y el acceso de contingencia deben definirse antes de la ampliación.
Usuario, dispositivo, certificado o combinación según la política.
Autenticación y autorización transportadas hasta el equipo de red.
El switch, punto de acceso o controlador aplica una VLAN, un rol o una ACL admitidos.
DHCP, DNS, enrutamiento y segmentación completan el acceso efectivo.
Accounting, el estado de la sesión y la prueba de tráfico demuestran el resultado.
La compatibilidad debe validarse por modelo, firmware y mecanismo. El relevamiento registra autenticación, atributos de autorización, VLAN o ACL, accounting, CoA y comportamiento en la reautenticación y ante fallos.
La compatibilidad con Huawei varía según el modelo, el firmware y el mecanismo. El relevamiento confirma 802.1X, MAB, RADIUS, VLAN o ACL dinámica, accounting y CoA necesarios para el caso. La homologación debe utilizar el equipo y la versión reales del entorno.
En entornos multifabricante, la política puede ser común, pero su aplicación cambia según el fabricante. El proyecto documenta los atributos, los límites y el comportamiento de cada integración, preservando las funciones nativas y una operación sostenible.
El recorrido de los invitados debe definir registro, responsable, aprobación, plazo y recursos permitidos. El portal debe funcionar en los dispositivos previstos, preservar la accesibilidad y orientar al usuario incluso antes de disponer de acceso pleno a internet.
La autorización debe comprobarse en el equipo y en el tráfico. Accounting identifica la sesión; CoA, Disconnect o un mecanismo equivalente debe modificar o finalizar el acceso correcto. El piloto valida la caducidad, la renovación, el roaming y los fallos de comunicación.
El invitado accede mediante la red y la experiencia del portal previstas para el dispositivo real.
El autorregistro, la recepción o el patrocinador siguen los requisitos definidos de datos mínimos, plazo y responsabilidad.
La política concede acceso solo a internet o a los recursos específicos aprobados.
Accounting y los identificadores disponibles correlacionan al usuario, el equipo y el NAS.
CoA, Disconnect o el mecanismo nativo acordado modifica o finaliza la sesión correcta.
PacketFence puede combinar el perfil del dispositivo con señales de herramientas de seguridad. Cada señal debe tener un origen, una vigencia y un nivel de confianza conocidos; las acciones automáticas necesitan alcance, remediación y reversión para evitar bloqueos indebidos.
La alta disponibilidad debe validarse por servicio. El proyecto mide nuevas autenticaciones, el portal, las sesiones existentes, la base de datos y las dependencias en condiciones de fallo. La capacidad y la retención se dimensionan con datos observados, margen y pruebas representativas.
Las actualizaciones deben seguir versiones con soporte, notas oficiales, copias de seguridad, pruebas y una reversión planificada. Las integraciones deben utilizar mecanismos documentados para evitar depender de modificaciones locales que dificulten el soporte y la evolución.
La arquitectura documentada parte de al menos tres nodos y un número impar de servidores.
Galera, HAProxy y Keepalived distribuyen las funciones según el diseño y la conectividad entre ubicaciones.
Cuando el clúster pierde el quórum, la base de datos entra en modo de solo lectura; el portal y las autenticaciones RADIUS pueden verse afectados de forma diferente según los datos y las fuentes que sigan accesibles.
El portal, las nuevas autenticaciones y las sesiones existentes se verifican por separado.
Las copias de seguridad, la restauración, las actualizaciones y las pruebas de regresión entre fabricantes tienen procedimientos y evidencias propios.
El costo total incluye infraestructura, implementación, operación, soporte, actualizaciones y crecimiento. La edición autohospedada se distribuye bajo GPL v2 o posterior; el soporte del fabricante y los servicios de Add Solution tienen alcances propios, que deben quedar explícitos en la propuesta.
La comparación debe partir de los requisitos del entorno. PacketFence favorece el control de la infraestructura y la flexibilidad abierta; Cisco ISE, ClearPass y FortiNAC pueden ser adecuados cuando sus integraciones de ecosistema son decisivas; NPS atiende escenarios RADIUS más limitados. Las licencias, la compatibilidad, la operación y la migración deben compararse con el mismo alcance.
El alcance debe registrar la compatibilidad por modelo y firmware, las integraciones nativas, los criterios de aceptación, las responsabilidades y los objetivos de continuidad. Las limitaciones detectadas en el piloto deben tratarse antes de la ampliación.
El alcance puede incluir las siguientes líneas de trabajo, según las necesidades del entorno:
Inventario de puntos de control, fuentes de identidad, tipos de endpoint y dependencias. Definición de políticas, excepciones, método de implementación y criterios de continuidad.
Validación en un conjunto representativo de equipos y clientes. Pruebas de admisión, rechazo, segmentación, caducidad, revocación y fallo. Registro de resultados y limitaciones antes de la ampliación.
Secuenciación por sede, SSID o grupo de puertos, con comunicación al soporte y un procedimiento de reversión. Cada etapa debe tener criterios de avance y responsables definidos.
La entrega registra políticas, integraciones, certificados, pruebas, excepciones y procedimientos de soporte y recuperación. Las responsabilidades y el modelo de atención se definen en la propuesta.
La respuesta depende de los modelos, el firmware y los controles previstos. El relevamiento debe distinguir los equipos que cumplen el diseño, los que requieren restricciones y los que deben sustituirse. La compatibilidad debe comprobarse por función en la matriz oficial.
Sí, ese puede ser el alcance inicial del proyecto. Incluso en esta etapa, es importante validar el aislamiento, el portal, la duración, la trazabilidad y la finalización del acceso. La ampliación a 802.1X corporativo es una decisión posterior de arquitectura.
Debe tratarse como identificación con limitaciones. El diseño recomendado combina registro controlado, permisos mínimos y seguimiento de excepciones. Debe evaluarse el uso de autenticación más robusta en los equipos que la admitan.
No. El proyecto coordina estos controles. La política de admisión y segmentación debe convivir con la inspección del tráfico, la protección de endpoints y la respuesta a incidentes. Cada capa debe tener una función, un responsable y evidencias propios.
La aceptación debe incluir pruebas entre invitados, redes internas y servicios de infraestructura. El resultado depende de las reglas y las rutas de comunicación realmente configuradas, incluido IPv6 cuando esté presente.
El proyecto debe separar la validación del certificado del permiso de acceso. La identidad, la vinculación con el dispositivo o usuario, la vigencia de la autorización y las posibles restricciones deben formar parte de la decisión.
Los mecanismos de autenticación de red pueden utilizar el supplicant del sistema o la identificación por MAC. Las comprobaciones de postura y el aprovisionamiento tienen dependencias propias, que deben confirmarse para cada integración y sistema operativo.
Esto debe demostrarse para la arquitectura elegida. Las sesiones existentes, las nuevas autenticaciones y el portal pueden comportarse de forma diferente. El piloto debe incluir fallos de nodos y dependencias, con una política de contingencia explícita.
Sí, el portal dispone de mecanismos de personalización documentados. El proyecto debe preservar la accesibilidad, la claridad de los estados, la compatibilidad móvil y la ruta de actualización de la plataforma.
El proyecto puede aportar controles de acceso y registros. La organización debe validar la finalidad, los datos recopilados, la retención y las responsabilidades con su área de privacidad. Un portal o una herramienta por sí solos no demuestran el cumplimiento. Orientaciones de la ANPD sobre seguridad de la información.
Depende de la compatibilidad del parque, la madurez de la identidad y la PKI, la cantidad de flujos, la necesidad de redundancia y el alcance operativo. La evaluación inicial debe transformar estas variables en etapas, criterios de aceptación y una propuesta.
Comparta las clases de dispositivos, redes, equipos, métodos de autenticación, necesidades de invitados y requisitos de continuidad. No envíe credenciales, secretos RADIUS ni datos operativos sensibles.