Configurar y probar Wi-Fi directamente en Sophos Firewall

Una red Wi-Fi administrada directamente en Sophos Firewall se crea en Wireless > Wireless networks. Sin embargo, el SSID por sí solo no es suficiente: el modo de tráfico elegido determina si los clientes reciben una red propia, se integran en la LAN del AP o se conectan mediante bridge a una VLAN. Después, DHCP, las reglas de firewall, NAT y la asignación a un punto de acceso deben estar coordinados.

⚠️ Importante: Esta guía solo se aplica al hardware Wi-Fi administrado directamente por Sophos Firewall. Los puntos de acceso AP6 no se pueden administrar mediante SFOS. Para varios AP6, Sophos Fusion (antes Sophos Central) es la opción de administración prevista y recomendada; como alternativa, un único AP6 se puede configurar mediante su interfaz local. Por tanto, Firewall-managed Wireless resulta actualmente relevante sobre todo para instalaciones APX existentes, el LocalWiFi integrado de los modelos de sobremesa W y los módulos Wi-Fi compatibles de Sophos Firewall o SD-RED. El firmware de los APX administrados por SFOS se proporciona mediante las actualizaciones de patrones del firewall y se instala de forma consciente.

Esta guía utiliza una red Wi-Fi para invitados con Separate zone. Es un ejemplo fácil de entender porque permite separar claramente de la LAN interna la red de clientes, las reglas y los destinos permitidos.

Si una red Wi-Fi 802.1X usa RADIUS y el firewall debe reconocer a los usuarios sin un portal cautivo adicional, RADIUS SSO con accounting explica la ruta de accounting separada, la Framed-IP-Address necesaria y la prueba en Live users.

Procedimiento resumido:

Preparar Wireless Protection y la zona del AP en Wireless > Wireless settings.
Aceptar el punto de acceso en Wireless > Access points.
Crear el SSID, la seguridad y la red de clientes en Wireless > Wireless networks.
Añadir DHCP, la regla de firewall y NAT en Network > DHCP y Rules and policies.
Asignar el Wireless Network al AP y comprobar con un cliente de prueba la dirección IP, DNS, Rule ID y los accesos internos no deseados.

¿Esta guía es adecuada para el punto de acceso?

SFOS 22 puede administrar puntos de acceso de interior de la serie APX, el Wi-Fi integrado de un XGS Appliance compatible y módulos de expansión Wi-Fi compatibles de Sophos Firewall o SD-RED. En el caso de los APX externos, esto incluye APX 120, APX 320, APX 530 y APX 740. El modelo de exterior APX 320X y la antigua serie AP no se administran directamente desde un Sophos Firewall actual.

AP6 no forma parte de este procedimiento. AP6 se configura mediante Sophos Fusion o, si se trata de un solo dispositivo, desde su interfaz local. Para la variante de Fusion, consulte los requisitos de Sophos Central Wireless.

La función Wireless local forma parte de la Sophos Firewall Base License. Se necesita por separado un punto de acceso compatible. Sin embargo, APX ya está en End-of-Sale y alcanza su End-of-Life el 31 de diciembre de 2027. Por tanto, esta guía sirve principalmente para operar de forma segura instalaciones APX existentes. Para una nueva plataforma Wi-Fi, conviene considerar el End-of-Life de APX y AP6 como sucesor u otros sistemas Wi-Fi actuales.

Límite de versión: La ayuda de Wireless contiene los procedimientos correspondientes tanto para SFOS 22 como para SFOS 23. Sin embargo, la existencia de una página de ayuda de SFOS 23 no demuestra que un modelo APX concreto sea compatible con SFOS 23. La compatibilidad del hardware debe confirmarse de forma independiente mediante el Retirement Calendar y la matriz de compatibilidad. Por tanto, antes de una actualización, compruebe el modelo, la revisión de hardware y la compilación de destino en la matriz de compatibilidad; no migre los APX existentes a SFOS 23 basándose únicamente en estas instrucciones. El WLAN integrado y los módulos SD-RED también deben corresponder al modelo y a la compilación concretos. Para los nuevos puntos de acceso externos se aplica el procedimiento de administración de AP6 enlazado arriba, no este procedimiento de SFOS-APX.

Para conectar un APX existente sin Ethernet mediante otro APX cableado, configurar y probar Wireless Mesh en Sophos Firewall explica AP raíz, canal, backhaul oculto y validación controlada.

SD-RED con módulo Wi-Fi: La ayuda de Wireless documenta DHCP option 234 para la comunicación de un módulo SD-RED utilizado como punto de acceso con Sophos Firewall. No se trata del DHCP de los clientes de la Wi-Fi de invitados ni de un requisito general para APX o AP6. La ayuda también menciona Sophos UTM en este contexto; esto no constituye aquí unas nuevas instrucciones de instalación de UTM. Antes de realizar cambios, aclare la compatibilidad del módulo, el DHCP de gestión y el controlador realmente utilizado; no adopte un valor de opción de otro tipo de dispositivo. La configuración de SD-RED es el procedimiento separado para conectar la sede.

Elegir el modo Client traffic correcto

La decisión en Client traffic es más importante que el nombre del SSID. Determina si los clientes están en el mismo segmento de red local de capa 2, quién asigna las direcciones IP y qué tráfico pasa realmente por el firewall.

Separate zone

Separate zone crea una interfaz Wireless propia con su propia dirección IP y un túnel VXLAN entre el punto de acceso y el firewall. Los clientes reciben una subred propia. Esto permite controlar los accesos de cada red Wi-Fi mediante reglas específicas de WiFi a WAN o de WiFi a LAN. Zonas e interfaces de Sophos Firewall explica cómo interactúan la zona, la interfaz y el objeto de red.

Este modo es adecuado para invitados, IoT u otras redes que deben estar separadas de la LAN interna. Un hotspot con Captive Portal, contraseña diaria o voucher también requiere Separate zone. El procedimiento completo con la definición de voucher, el portal y la regla automática se describe en Configurar un hotspot de Sophos Firewall.

VXLAN reduce la MTU utilizable. Los paquetes grandes pueden provocar fragmentación o pérdidas de rendimiento. Por tanto, no se debe cambiar preventivamente la MTU a un valor genérico. Primero hay que comprobar si solo fallan las transferencias grandes o si los paquetes TCP se retransmiten repetidamente, lo que se conoce como Retransmits; Comprobar MTU y MSS en Sophos Firewall explica el procedimiento controlado.

Bridge to AP LAN

Bridge to AP LAN sitúa los clientes Wi-Fi en la misma red que el punto de acceso. Un servidor DHCP existente en esa LAN asigna las direcciones de los clientes. Es cómodo, pero no proporciona un límite de red independiente para invitados o dispositivos no seguros.

La ruta de los datos es decisiva: la comunicación dentro de la misma subred puede pasar directamente entre el cliente, el AP y el switch, evitando por completo Sophos Firewall. Una regla de firewall en SFOS solo puede controlar el tráfico que realmente se enruta a través del firewall.

Para permitir únicamente una lista conocida de dispositivos en la red inalámbrica integrada, se crea una lista MAC en Hosts and services > MAC host. Después, en la red Wireless, se selecciona Allow list en Advanced settings > MAC filtering y se asigna esta lista. La contraseña debe tener entre 8 y 63 caracteres. Durante la validación se conecta un dispositivo incluido y otro no incluido en la lista.

Una dirección MAC puede suplantarse. Por tanto, la Allow list es solo un filtro de acceso adicional y no sustituye a WPA2 Personal con AES, a un método WPA3 compatible, a una contraseña segura ni a una correcta segmentación de red.

Cuando se utiliza Bridge to AP LAN con LocalWiFi integrado, la red Wi-Fi también debe conectarse a la LAN cableada. El método correcto depende del modelo de XGS Appliance:

Gen.1 – XGS 87w, 107w, 116w, 126w y 136w: En Network > Interfaces > Add interface > Add bridge se crea un bridge. Name es el nombre visible, que admite hasta 58 caracteres y puede modificarse posteriormente; Hardware name admite hasta 10 caracteres de A-Za-z0-9_ y no puede cambiarse después de guardar. En Member interfaces, la interfaz Wireless recibe la zona WiFi y el puerto Ethernet deseado, la zona LAN. Si es necesario, se pueden añadir más puertos Ethernet a este bridge.
Después, seleccionar IPv4 configuration, introducir la IPv4 address prevista para el bridge en la LAN existente y elegir la máscara de subred correspondiente. La dirección y la máscara deben proceder del plan de direccionamiento de la propia LAN, no de la red de invitados Separate zone que se utiliza más adelante. Antes de Save, comprobar que la dirección no esté asignada a otro dispositivo ni simultáneamente a una interfaz miembro, y que no esté dentro del rango DHCP dinámico sin una reserva. No cambiar de paso el gateway existente de los clientes ni el plan de direccionamiento DHCP. Antes de la modificación, comprobar el backup, las dependencias de los puertos y una vía de administración independiente; el procedimiento para interfaces bridge explica estas comprobaciones comunes y los nombres de hardware reservados. Su ejemplo transparente en línea sin dirección IP tiene otra finalidad: este procedimiento documentado de LocalWiFi Gen.1 utiliza una dirección IPv4 en el bridge, pero no todos los bridges necesitan una dirección IP. Guardar con Save solo después de estas comprobaciones.
Gen.2 – XGS 88w, 108w, 118w y 128w: La interfaz Wireless no puede formar parte de un bridge físico. En su lugar, en Wireless > Access points > LocalWiFi > Advanced settings se activa Bridge to Ethernet, se selecciona exactamente un puerto Ethernet y se establece la zona en LAN.
Para Bridge to Ethernet, el puerto físico seleccionado debe tener una dirección IP y no debe ser un puerto WAN ni miembro de otro puente. Este método no permite conectar mediante un puente una interfaz VLAN a LocalWiFi; la zona del puente tampoco debe ser WAN. La función solo se aplica a IPv4 y a SSID del tipo Bridge to AP LAN. SFOS utiliza el servidor DHCP existente del puerto del puente; si no existe, la ayuda documenta la creación automática de uno nuevo. Por tanto, antes de guardar, compruebe si ya existe un servidor DHCP en la LAN y, después, compruebe el servidor, el pool y la concesión para evitar respuestas DHCP en competencia. Al desactivar la función, se elimina el puente y la configuración vuelve a la interfaz física. Por ello, guarde previamente el estado inicial y compruebe la reversión, incluidos el acceso de administrador, el DHCP de la LAN y la conexión de los clientes, durante una ventana de mantenimiento.

Un APX externo no necesita este bridge LocalWiFi adicional. Además, durante un cambio de hardware no se puede transferir sin cambios un bridge Wireless físico de Gen.1 a Gen.2. Backup y restore de Sophos Firewall explica la preparación necesaria.

Bridge to AP LAN solo debe seleccionarse si la red Wi-Fi y la LAN cableada forman deliberadamente la misma zona de seguridad.

Para este procedimiento de LAN, guardar el Wireless Network con Save después de seleccionar Bridge to AP LAN, los ajustes de seguridad y la lista MAC. En Wireless > Access points > LocalWiFi, comprobar el Country correcto, asignar precisamente esta red en Wireless networks > Add new item y guardar; el Guest WiFi que aparece más adelante es un ejemplo independiente. Tras configurar el bridge, el dispositivo de prueba incluido en la lista debe poder conectarse y el no incluido debe ser rechazado. En el cliente autorizado, comprobar una concesión del rango LAN previsto, la máscara correspondiente, el gateway existente y los servidores DNS previstos; verificar la concesión en el servidor DHCP que realmente atiende esa LAN. Probar la resolución de nombres y un servicio previsto en un dispositivo de la LAN cableada. Si no se obtiene una concesión, comprobar primero la autorización MAC, la asignación de red, los miembros del bridge y el DHCP de la LAN. La comunicación local en la LAN es intencionada en este caso y no demuestra aislamiento de invitados ni una ruta de datos controlada por SFOS.

Bridge to VLAN

Bridge to VLAN separa la red de administración del punto de acceso de la VLAN de clientes. El puerto del switch conectado al AP debe transportar ambas redes como trunk. En el perfil Wi-Fi, Bridge to VLAN ID designa la VLAN de clientes; con autenticación Enterprise, esta ID de VLAN de clientes puede definirse de forma estática o mediante RADIUS con un valor estático de respaldo.

El AP debe conectarse primero durante al menos un minuto al firewall a través de la LAN estándar sin etiquetar para que reciba su configuración. Después se activa VLAN tagging en Wireless > Access points > AP > Advanced settings y se introduce la AP VLAN ID para la red de administración. Solo entonces se cambia el puerto del switch a trunk. La VLAN de administración del AP y la VLAN de clientes pueden utilizar ID diferentes. Sophos recomienda no mezclar Separate zone y redes Wi-Fi VLAN en el mismo AP. El etiquetado VLAN en el propio AP no está disponible para el LocalWiFi0 integrado.

Tras activarlo, el AP intenta durante 60 segundos obtener una dirección por DHCP en la VLAN de administración configurada. Si no recibe respuesta, vuelve a probar DHCP en la LAN sin etiquetar. Es una vía de recuperación útil, pero no un criterio de éxito: hay que corregir la VLAN, el trunk y DHCP hasta que el AP esté realmente en línea a través de la VLAN de administración prevista. Con Bridge to VLAN, SFOS crea automáticamente la interfaz VLAN y las reglas de firewall correspondientes. Conviene revisar estos objetos, porque cada AP crea una interfaz backend independiente por zona y un diseño con muchos AP y zonas puede crecer considerablemente.

La zona de la interfaz del firewall para la VLAN de gestión del AP debe estar permitida en Wireless > Wireless settings > Allowed zone. El modo de tráfico de los clientes y VLAN tagging en el AP deben ser coherentes: Bridge to VLAN requiere etiquetado en el AP; para Separate zone, puede estar activado o desactivado. La ayuda antigua de VLAN denomina otro caso bridge to an access point VLAN y exige que el etiquetado en el AP esté desactivado. De esta formulación no debe deducirse una opción adicional de la interfaz de usuario actual. Para el procedimiento Bridge to AP LAN sin etiquetar descrito aquí, deje desactivado el etiquetado en el AP; si el diseño es distinto, confirme la compatibilidad con el modelo y la compilación reales antes del cambio.

Bridge to VLAN evita la ruta VXLAN y suele ser más apropiado para entornos Wi-Fi grandes que ya estén correctamente segmentados. También en este caso se aplica lo siguiente: SFOS no inspecciona automáticamente el tráfico dentro de la VLAN de clientes.

Preparar la red de ejemplo

El ejemplo utiliza estos valores:

Nombre en SFOS: Guest WiFi
Hardware name inmutable: GuestWiFi
SSID visible: Company Guest
Security mode: WPA2 Personal
Client traffic: Separate zone
Zone: WiFi
Red de clientes: 10.30.40.0/24
Interfaz y gateway: 10.30.40.1
Rango DHCP: 10.30.40.100 a 10.30.40.220
Regla de firewall: WiFi_Guest_to_WAN

10.30.40.0/24 es un ejemplo del espacio de direcciones privadas. Antes de utilizarlo, hay que elegir una subred libre que no se solape con una LAN, VPN, RED, VLAN ni con una ubicación remota. En el ejemplo, la primera dirección utilizable, 10.30.40.1, pertenece a la interfaz Wireless del firewall y se distribuye como gateway.

Para los dispositivos APX existentes, WPA2 Personal con AES es la base segura y compatible. Una contraseña larga y única debe guardarse en el gestor de contraseñas y no en tickets ni capturas de pantalla. En SFOS 22, Sophos solo documenta los modos WPA3 para el Wi-Fi integrado de los modelos XGS 88w, 108w, 118w y 128w; por tanto, no se debe planificar WPA3 para APX.

La lista de seguridad también contiene No Encryption, WEP Open, modos WPA antiguos y modos mixtos WPA/WPA2. Estas entradas no son una recomendación para una Wi-Fi nueva o renovada: no utilice un perfil de invitados sin cifrado ni un mecanismo de respaldo WEP/TKIP; sustituya los clientes incompatibles o mígrelos por separado. En XGS 88w, 108w, 118w y 128w se pueden guardar perfiles con TKIP o AES/TKIP, pero no asignarlos a LocalWiFi0. En estos modelos, seleccione el modo WPA3 más robusto compatible con todos los clientes previstos, o WPA2 Personal con AES, y pruebe realmente la conexión.

Configurar una red Wi-Fi administrada por SFOS

1. Permitir la conexión del punto de acceso

En un APX externo, la red de administración y la red de clientes Wi-Fi son dos cosas distintas. El AP obtiene su propia dirección de administración mediante DHCP de la red conectada. En cambio, los clientes Wi-Fi posteriores reciben direcciones de la red planificada anteriormente, 10.30.40.0/24.

Abrir Wireless > Wireless settings.
Activar Enable wireless protection.
En Allowed zone, seleccione la zona a través de la cual el AP llega al firewall. SFOS ofrece DMZ, LAN y WiFi para ello. Acepte la selección y guarde los ajustes de Wireless con Apply antes de aceptar el AP.
Asegurarse de que el AP recibe mediante DHCP una dirección, un gateway y DNS. No se puede configurar una dirección de administración estática en el AP.
Comprobar que el puerto 2712 entre el AP y el firewall no esté bloqueado por un switch, una ACL o un dispositivo intermedio.
Abrir Wireless > Access points y aceptar un AP pending con Accept.
Establecer el Country correcto en el AP activo. De ello dependen los canales permitidos legalmente. Si se cambia el Country de un APX, guardar la configuración y reiniciar después el punto de acceso de forma controlada para que se aplique la nueva lista de canales.

En un firewall con dos tarjetas Wi-Fi, un cambio de Country afecta a ambas tarjetas y establece ambos canales en Auto. Documente previamente ambas configuraciones de radio y compruebe ambas después. Según la ayuda, en el APX 320 ambas radios deben estar configuradas en 5 GHz para enumerar todos los canales de 5 GHz disponibles; sin embargo, en Israel, Radio 0 solo admite 2.4 GHz. La autorización local del país tiene prioridad: no utilice otra selección de Country para forzar canales.

En Wireless > Wireless settings > Advanced settings, Timeout indica los minutos que transcurren entre el momento en que un punto de acceso queda offline y la notificación de tiempo de espera; una vez transcurrido ese periodo, SFOS considera el AP inactive. Para realizar una comprobación controlada, anote primero el valor actual y desconecte únicamente un AP de prueba sin clientes de producción durante una ventana de mantenimiento. Tras un periodo reducido temporalmente, pero seguro para la operación, deben aparecer la notificación y el estado inactive. A continuación, vuelva a conectar el AP, compruebe que recupera el estado active y restaure el valor anterior de Timeout.

La selección en Allowed zone se refiere a la ruta de administración del punto de acceso, no a la zona posterior de los clientes Wi-Fi. Si el AP todavía está registrado en otro Sophos Firewall o en Sophos Fusion, primero debe eliminarse de allí. Si no es posible, debe restablecerse a la configuración de fábrica. Para la retirada planificada del servicio, primero retire de la red el AP identificado de forma inequívoca y, a continuación, seleccione ese AP en Wireless > Access points y utilice Delete. Compruebe su identidad antes; después, compruebe que su entrada se ha eliminado y que los AP y SSID restantes siguen funcionando. Delete no equivale a eliminar una asignación Wi-Fi ni a desactivar un grupo; no elimine un AP en producción como prueba para resolver problemas.

La conexión de control por el puerto 2712 está cifrada con AES entre el firewall y el punto de acceso. Permitir el puerto no sustituye la limitación de la red de administración del AP a la zona que realmente la necesita.

2. Crear el Wireless Network

En Wireless > Wireless networks > Add se introducen los valores de ejemplo:

Name: Guest WiFi
Hardware name: GuestWiFi
SSID: Company Guest
Security mode: WPA2 Personal
Passphrase: una contraseña larga y única
Client traffic: Separate zone
Zone: WiFi
IP address: 10.30.40.1
Netmask: /24

El Hardware name puede tener como máximo diez caracteres formados por letras, números y guiones bajos, y no puede modificarse posteriormente. Name admite hasta 58 caracteres y el SSID entre 1 y 32 caracteres ASCII imprimibles. Ambos pueden adaptarse a la convención de nombres propia. El Name de la red inalámbrica puede modificarse posteriormente y se muestra en otros ajustes en lugar del Hardware name. En este campo se permiten todos los caracteres excepto '"<>#%\/,; no aplique esta restricción a SSID, Hardware name ni Passphrase.

En Advanced settings, estas decisiones son adecuadas para el ejemplo de invitados:

Encryption: AES
Frequency band: solo las bandas compatibles con el modelo utilizado y sus módulos de radio
Client isolation: activar si no se desean conexiones directas entre invitados
Hide SSID: dejar desactivado
Fast transition: utiliza IEEE 802.11r y requiere WPA2 como Security mode. APX no admite esta función. Utilícela únicamente en hardware compatible que no sea APX, después de comprobar el modelo, la compilación de SFOS y los clientes; esto no implica compatibilidad con AP6 ni aprobación para todos los modelos W o para WPA3.
Time-based access: controla los horarios de acceso permitidos para este SSID. Utilice Add new item para seleccionar una programación adecuada o crear una propia. Realice la activación y los cambios de configuración durante una ventana de interrupción planificada, porque la activación reinicia hostapd y desconecta a todos los clientes del AP afectado, como se describe a continuación. Utilice un cliente de prueba para comprobar tanto el periodo previsto de acceso permitido como el de acceso bloqueado; esta programación de acceso no es la programación de los escaneos de radio o de AP no autorizados.

Client isolation solo bloquea la comunicación directa entre clientes del mismo SSID y de la misma radio. No sustituye la separación mediante zonas, VLAN y reglas de firewall entre varios AP o módulos de radio. Un SSID oculto tampoco es un control de seguridad; únicamente evita que se muestre de forma visible el nombre de la red.

Con Wi-Fi integrado, el funcionamiento simultáneo en banda dual depende del hardware. XGS 87w y 107w solo transmiten en 2.4 GHz o 5 GHz. XGS 116w, 126w y 136w necesitan un segundo módulo de radio para utilizar ambas bandas. XGS 88w, 108w, 118w y 128w pueden utilizar ambas bandas simultáneamente sin un módulo adicional.

Al activar una programación Wireless, SFOS reinicia hostapd. Esto desconecta brevemente a todos los clientes Wi-Fi del punto de acceso afectado, no solo a los clientes de ese SSID. Los dispositivos deberían volver a conectarse automáticamente.

Si también se desea bloquear un dispositivo conocido, cree, por ejemplo, Bad hosts con Type: MAC list en Hosts and services > MAC host > Add, introduzca las direcciones MAC que realmente se van a bloquear y guarde. En el perfil de invitados, en Advanced settings > MAC filtering, seleccione la opción de lista de bloqueo, asigne esta MAC list y guarde el Wireless Network con Save. La ayuda de Separate zone denomina esta opción Blacklist; compruebe la denominación de la lista de bloqueo en la compilación utilizada. Compruebe con un dispositivo de prueba bloqueado y otro permitido que solo se rechaza el bloqueado. Una dirección MAC suplantada o aleatoria puede eludir este bloqueo: este no demuestra la detección de malware ni que un dispositivo esté limpio, y no sustituye las políticas de protección ni la separación de redes. Allowed zone permite la ruta de gestión del AP; activar Wireless Protection por sí solo no demuestra que se analicen todos los paquetes de la Wi-Fi o la LAN en busca de malware.

Validar por separado Wi-Fi Enterprise y RADIUS

Para una red Wireless con 802.1X, el servidor RADIUS se selecciona en Wireless > Wireless settings. El punto de acceso no se comunica directamente con el servidor RADIUS: utiliza el puerto 414 para comunicarse con el firewall durante la autenticación y el puerto 417 para Accounting. A continuación, el firewall reenvía Accounting al puerto RADIUS configurado, normalmente el 1813.

Para la autenticación Enterprise, utilice Wireless network Name como NAS ID, no automáticamente la SSID visible ni Hardware name. Estos valores pueden ser diferentes. Ajuste la política RADIUS a este nombre y compruebe en el registro de autenticación de un cliente de prueba que se utilizan la NAS ID y la política esperadas; compruebe la autenticación y la contabilidad por separado.

Accounting debe estar activado en el servidor RADIUS; este flujo Wireless no admite Interim Accounting Updates. El Secondary RADIUS server no debe planificarse como failover general: APX y los dispositivos compatibles con Wi-Fi solo pueden utilizar el servidor RADIUS primario, y los XGS Appliances no admiten un servidor RADIUS secundario para este flujo.

Para este flujo inalámbrico administrado por SFOS, los ajustes Wireless de SFOS 22 y 23 exigen una asignación NAT para las redes de los puntos de acceso cuando el servidor RADIUS está conectado al firewall mediante un túnel IPsec. La IP de origen debe traducirse a la dirección IP exacta del firewall que este utiliza para acceder al servidor RADIUS. Se trata de las redes de los AP, no de la red de clientes inalámbricos en general. La ayuda remite a la configuración mediante shell con sys-traffic-nat, pero no proporciona aquí un comando completo ejecutable. Esto no establece un requisito general de NAT para otras vías RADIUS.

Antes de realizar un cambio, documentar la versión y el build exactos de SFOS, las redes de los AP, la dirección de origen realmente utilizada, la IP prevista del firewall para la traducción, el túnel y los Traffic Selectors, la ruta de retorno y los logs de RADIUS. Sin una sintaxis confirmada para ese build y flujo de datos, no realizar cambios en la shell: solicitar a Sophos Support que confirme la shell compatible, los parámetros y las direcciones que deben utilizarse, junto con las comprobaciones previas, la verificación del éxito y la reversión exacta. Realizar el cambio únicamente en una ventana de mantenimiento siguiendo ese procedimiento confirmado; después, comprobar la autenticación 802.1X y Accounting con un cliente de prueba y comparar la IP de origen observada en el servidor RADIUS y la ruta de respuesta con los valores previstos. Si hay diferencias, no ampliar las reglas de acceso: revisar las pruebas con Support y utilizar la reversión confirmada si es necesario.

El tráfico de autenticación generado por el firewall debe distinguirse del tráfico de clientes reenviado. El artículo sobre rutas IPsec para tráfico reenviado explica system ipsec_route y NAT para ese flujo de reenvío; no contiene un procedimiento de sys-traffic-nat. Ni su DNAT/SNAT reflexivo ni una regla de LAN a VPN sustituyen la configuración NAT del tráfico de sistema requerida aquí.

Tras configurar los ajustes generales y avanzados y, si procede, los ajustes de Enterprise y del filtro MAC, guardar el Wireless Network con Save – incluso si no se utiliza ninguna lista de bloqueo de MAC. En Wireless > Wireless networks, comprobar que Guest WiFi aparece con los ajustes previstos. Solo entonces crear el servidor DHCP en esta interfaz y asignar la red a un AP como se describe a continuación. Unplugged antes de la asignación a un AP no es motivo para volver a crear el perfil ni para crearlo con un modo de tráfico diferente.

3. Añadir DHCP para la red de clientes

Para Separate zone no se proporciona automáticamente un servidor DHCP completo para los clientes. Por tanto, en Network > DHCP > Server > Add se crea, por ejemplo, esta configuración:

Name: dhcp-wifi-guest
Interface: Guest WiFi
Dynamic IP lease: 10.30.40.100 a 10.30.40.220
Subnet mask: /24
Gateway: Use interface IP as gateway
DNS server: adecuado para la arquitectura DNS propia
Conflict detection: activado

El rango comienza deliberadamente por encima de la IP de la interfaz y deja espacio para direcciones reservadas. En una red Wi-Fi para invitados con mucha rotación puede ser útil una concesión más corta que en una red de oficina estable. Sin embargo, las concesiones extremadamente cortas generan renovaciones innecesarias.

La elección de los servidores DNS que se distribuyen es una decisión de seguridad y de operación. Los servidores DNS internos de AD no deben quedar accesibles para los invitados solo por comodidad. Configurar Sophos Firewall como servidor DHCP explica la planificación completa y el control de las concesiones.

4. Comprobar la regla de firewall, NAT y los servicios locales

En Rules and policies > Firewall rules > Add firewall rule > New firewall rule se crea una regla para el acceso a Internet deseado. El formulario completo, el orden de las reglas y las Security Features se explican en el artículo sobre reglas de Sophos Firewall.

Rule name: WiFi_Guest_to_WAN
Action: Accept
Log firewall traffic: activado
Source zones: WiFi
Source networks and devices: objeto de red para 10.30.40.0/24
Destination zones: WAN
Destination networks: Any
Services: solo los servicios necesarios para la red Wi-Fi de invitados
Security features: políticas Web, Application e IPS adecuadas según la licencia y el uso previsto

Un objeto de red descriptivo como net_WiFi_Guest hace que la regla sea más específica y comprensible que Source networks: Any. La selección de servicios depende de si DNS y NTP se utilizan localmente en el firewall o directamente de forma externa. Una autorización genérica con Any es cómoda, pero dificulta los controles posteriores.

Además, una regla NAT debe traducir el tráfico saliente a la dirección WAN. La regla SNAT predeterminada existente con MASQ suele cubrir ya las nuevas redes internas, pero esto debe comprobarse en el conjunto de reglas concreto en lugar de crear una segunda regla NAT por precaución. Comprender NAT en Sophos Firewall explica esta relación.

Una regla de WiFi a WAN no impide automáticamente los accesos mediante reglas amplias de WiFi a LAN o Any que ya existan. Por tanto, hay que comprobar todo el orden de las reglas para detectar autorizaciones internas. Si los clientes de la misma red Separate Zone deben comunicarse entre sí a través de varios AP, se necesita además una regla de WiFi a WiFi. En una red Wi-Fi de invitados, esta comunicación solo debe permitirse de forma deliberada.

El acceso al propio firewall no se controla mediante la regla de firewall normal. En Administration > Device access, compruebe los permisos WiFi realmente configurados para HTTPS y SSH, en lugar de suponer una configuración predeterminada concreta. Por tanto, en Administration > Device access se eliminan para una red Wi-Fi de invitados las casillas WiFi de HTTPS, SSH y todos los demás servicios locales que no sean necesarios. DNS solo se deja permitido si los clientes utilizan realmente el firewall como resolver. Device Access y Local Service ACL explica los motivos.

5. Asignar la red Wi-Fi a un punto de acceso

Un Wireless Network guardado todavía no se transmite desde ningún punto de acceso:

Abrir Wireless > Access points.
Abrir el punto de acceso activo mediante su nombre o Edit.
Comprobar el Country correcto.
En Wireless networks, hacer clic en Add new item.
Seleccionar Guest WiFi, confirmar con Apply y hacer clic en Save.

Si hay varios puntos de acceso, resulta más claro utilizar un grupo en Wireless > Access point groups. De este modo, los SSID se asignan de forma coherente y no se administran de manera diferente en cada AP. Se pueden asignar hasta ocho Wireless Networks a un AP.

El grupo se crea en Wireless > Access point groups > Add con nombre, Wireless networks, VLAN tagging opcional y los Access points incluidos. Antes de guardar hay que comprobar que la asignación VLAN sea realmente adecuada para todos los AP seleccionados.

⚠️ Impacto operativo: Al desactivar un grupo de puntos de acceso, todos los AP incluidos dejan de emitir las redes Wi-Fi asignadas. Los cambios de grupo deben realizarse en una ventana de mantenimiento con una lista documentada de AP y SSID.

Cambiar conscientemente los parámetros de radio y los grupos de AP

En Wireless > Access points > AP > Advanced settings, el canal, Dyn chan, TX power y Channel width afectan a más de un cliente de prueba. Un cambio dinámico de canal puede obligar a los clientes conectados a volver a conectarse. Los canales más anchos pueden aumentar el rendimiento en entornos de baja densidad, pero el solapamiento adicional puede reducirlo en entornos de alta densidad. SFOS utiliza por defecto 20 MHz en 2,4 GHz y 40 MHz en 5 GHz. La potencia de transmisión y el ancho de canal deben medirse en cada ubicación, no maximizarse de forma general.

Turn on Spanning Tree Protocol (STP) protege las redes en bridge frente a bucles de capa 2 y las tormentas de broadcast resultantes. STP no debe tratarse como un ajuste de rendimiento. Después de un cambio se prueban al menos dos clientes reales, roaming, DHCP, DNS y una transferencia prolongada; con la selección automática de canal también se registra el momento del cambio y la reconexión correcta de los clientes.

Si la selección dinámica de canal debe ejecutarse solo en horarios establecidos, active primero Dyn chan y después Time-based scan para cada banda, y asigne el Schedule previsto en Select scan time > Add new item o créelo mediante Add. Después de Save, observe la hora del escaneo y una posible reconexión de los clientes. Antes de realizar cambios de grupo, identifique inequívocamente el AP mediante ID (número de serie), Label y Group. Puede volver a deseleccionar un WLAN individual en sus detalles del AP mediante remove; después, guarde y compruebe los demás SSIDs. Esto no equivale a desactivar todo el grupo de AP. Para un reinicio planificado del AP, puede reiniciar el AP seleccionado en Wireless > Access points mediante Restart; antes, guarde la lista de clientes y los registros y, después, repita las pruebas de conexión descritas a continuación.

Probar la red Wi-Fi de forma controlada

La validación no debe terminar con «el SSID es visible». Con un cliente de prueba se comprueba si realmente se utilizan la red y las reglas planificadas:

En Wireless > Access points, el AP debe estar activo. La interfaz Wireless permanece en Unplugged en Network > Interfaces mientras no haya ningún AP conectado con este Wireless Network.
Conectarse a Company Guest y comprobar el AP, SSID, frecuencia y señal en Wireless > Wireless client list.
En Network > DHCP > IPv4 lease, comprobar que el cliente ha recibido una dirección entre 10.30.40.100 y 10.30.40.220.
Comprobar la dirección IP, el gateway y DNS en el cliente. En Windows resultan útiles:

ipconfig /all
nslookup example.com

Probar una conexión a Internet permitida y, de forma intencionada, un destino interno no permitido.
En el Log Viewer, filtrar por la dirección IP del cliente y comprobar la Firewall Rule ID y la NAT Rule ID esperadas.

El éxito no consiste únicamente en tener acceso a Internet. El cliente debe utilizar el gateway correcto y los servidores DNS previstos, estar separado de los destinos internos no autorizados y pasar exactamente por las reglas de firewall y NAT esperadas. Probar correctamente las reglas de firewall muestra el procedimiento de comprobación general.

Analizar de forma controlada los puntos de acceso rogue

Rogue AP scan solo está disponible en appliances Sophos Firewall con Wi-Fi integrado; los puntos de acceso APX externos no pueden realizar este análisis. En Wireless > Rogue AP scan, Scan now busca puntos de acceso dentro del alcance de radio. Durante el análisis, los clientes Wi-Fi conectados se desconectan brevemente. Por tanto, un análisis manual o programado debe realizarse en una ventana conocida y no sin previo aviso durante la operación en producción.

Los dispositivos detectados aparecen en Unrecognized access points y se marcan de forma deliberada como autorizados o como Rogue AP. Esta clasificación no sustituye una investigación del incidente: se deben correlacionar el SSID, la BSSID, el canal, la señal, la ubicación y el posible puerto del switch antes de tratar una red Wi-Fi desconocida como un dispositivo de la propia LAN.

Para análisis recurrentes, se selecciona una programación en General settings > Schedule system-triggered scan at. Con LocalWiFi0, Bridge to Ethernet activado y una red Wireless en modo Bridge to AP LAN, el análisis solo muestra las redes cercanas que se encuentran en la misma banda de frecuencia que la red Wireless asignada. Esta limitación del producto debe documentarse al evaluar el resultado.

Aplique la programación del análisis con Apply. En los resultados, utilice las acciones Mark as “authorized access point” o Mark as “rogue access point” y compruebe la asignación resultante. Una entrada marcada como rogue es una clasificación, no un mecanismo acreditado para apagar o bloquear un punto de acceso ajeno.

Delimitar los errores habituales

El SSID no se muestra

Primero hay que comprobar si Wireless Protection está activo, si la zona de administración del AP aparece en Allowed zone y si el punto de acceso figura como active, no como pending o inactive, en Wireless > Access points. Después se comprueban el Country, el Wireless Network asignado, la Frequency band y una posible programación.

Una red guardada sin asignación a un AP no se transmite. En el Wi-Fi integrado, los límites del modelo para las bandas de radio o un modo de cifrado antiguo no compatible también pueden impedir que el perfil se vincule a LocalWiFi0.

La interfaz Separate zone permanece `Unplugged`

El estado Unplugged es normal mientras no haya ningún punto de acceso conectado o la Wireless Network no esté asignada a un AP. Si permanece así pese a que el APX está activo y la asignación es correcta, hay que comprobar la ruta de administración del punto de acceso.

En SFOS 21.5 MR1 Build 261, esto puede ocurrir cuando la IP del firewall utilizada por la red de administración del APX está configurada como alias en lugar de directamente en la interfaz principal (NC-175920). SFOS no puede crear entonces el túnel VXLAN para Separate zone. La solución consiste en trasladar el APX a una red de administración cuya IP del firewall esté configurada directamente en la interfaz principal. No se debe eliminar la IP alias sin haber confirmado antes la causa.

El cambio interrumpe las redes Wi-Fi emitidas por el AP. Por tanto, primero hay que comprobar DHCP, el gateway, Allowed zone y el puerto 2712 en la red de destino, y efectuar el cambio durante una ventana de mantenimiento. Después se verifican el estado del AP, la asignación de la red Wi-Fi, el estado de la interfaz y la conexión de un cliente de prueba. Sophos no indica una versión corregida; por tanto, en otras versiones de SFOS el estado Unplugged por sí solo no demuestra este problema.

El cliente no recibe una dirección IP

Con Separate zone, el servidor DHCP debe estar en la interfaz Wireless creada y el rango debe coincidir con la red de la interfaz. Con Bridge to AP LAN, responde en cambio el servidor DHCP de la LAN del AP. Con Bridge to VLAN, se comprueban conjuntamente el trunk del switch, la ID de VLAN y el servidor DHCP accesible en la VLAN de clientes.

No deben confundirse el DHCP de administración del AP y el DHCP de clientes: el AP puede estar online aunque todavía no exista un servidor DHCP funcional para los clientes Wi-Fi.

El cliente tiene una dirección IP, pero no acceso a Internet

En ese caso, DHCP y la conexión Wi-Fi ya funcionan y el siguiente punto que se debe comprobar es la política. A continuación se revisan el gateway y DNS, la regla de WiFi a WAN, el orden de las reglas, el logging y la regla MASQ/SNAT adecuada. El Log Viewer muestra si ha coincidido la Firewall Rule ID prevista o si la regla implícita #0 descarta el tráfico.

Si el cliente accede a Internet, pero al mismo tiempo también a sistemas internos, no se puede considerar un resultado correcto para una red Wi-Fi de invitados. En este caso, probablemente se estén aplicando reglas de WiFi a LAN, Any o reglas de red demasiado amplias.

La conexión del AP o la comunicación de los clientes siguen sin estar claras

El tráfico del firewall solo aparece de forma fiable en el Log Viewer si Log firewall traffic está activado en la regla y el tipo de log Firewall está activo en System services > Log settings > Local reporting. Los propios eventos Wireless no están disponibles allí como un tipo de log Wireless local normal; en System services > Log settings pueden enviarse a Sophos Fusion o a un servidor syslog.

Para un diagnóstico más profundo, Sophos documenta awed.log para la comunicación entre el firewall y APX, wc_remote.log para los clientes Wireless y hostapd.log para LocalWiFi. Comprobar servicios y logs de Sophos Firewall mediante la CLI explica cómo leer estos logs sin reiniciar servicios de forma incontrolada.

Si es necesario, el registro de un APX accesible puede leerse mediante awetool. Inicie sesión como admin en la CLI del firewall, seleccione 5 – Device Management y después 3 – Advanced Shell, e inicie awetool. Seleccione Connect to an AP, elija el AP de destino por su identidad, confirme con OK y complete la conexión con y. Solo en este AP, logread y logread -f son las comprobaciones de lectura documentadas. El comando reboot, que también se ofrece, desconecta a los clientes y modifica el estado; debe ejecutarse únicamente después de guardar los registros, durante una ventana de mantenimiento y con una comprobación posterior del estado del AP, la SSID, la lista de clientes y el tráfico real. No aplique estos pasos de shell de APX a AP6, a LocalWiFi integrado ni a UTM.

Las transferencias grandes son lentas o se interrumpen

Si solo se ven afectados los paquetes grandes o las transferencias largas, la encapsulación VXLAN de Separate zone puede ser una causa. No existe un valor de MTU válido para todos los casos. Primero se documentan la Rule ID, la ruta de datos, los Retransmits y una prueba de aplicación reproducible. Solo se realiza un cambio controlado cuando se ha demostrado un problema de MTU/MSS y, después, se repite la misma prueba.

Clasificar de forma segura los objetos Wireless mediante la API XML

Quien automatice los ajustes descritos anteriormente debe tratar por separado el perfil de red, el componente de radio local, el grupo de AP y los ajustes globales de Wireless. Las referencias XML para SFOS 22 y 23 documentan los siguientes objetos, pero no autorizan a enviar una solicitud de escritura copiada sin modificaciones. El acceso, las operaciones explícitas, la evaluación de respuestas y los reintentos seguros se explican en Proteger el acceso a la API XML de Sophos Firewall. Antes de realizar cambios, guardar el estado actual del objeto y sus dependencias, y asegurar una vía de reversión confirmada. En los conflictos entre fuentes que se indican a continuación, aclarar primero los campos de escritura afectados en API help de la compilación instalada o con el soporte; no enviarlos hasta entonces. Todos los códigos siguientes son valores de estado XML específicos del objeto, no códigos de estado HTTP; todos los símbolos Message.* son claves de referencia sin resolver, no textos confirmados de ejecución. Registrar conjuntamente la operación, el código y la respuesta real depurada.

WirelessLocalAP: identidad y parámetros de radio del modelo W

WirelessLocalAP corresponde al punto de acceso local integrado de un dispositivo Wireless compatible, no a la interfaz web local de un AP6 ni a su administración mediante Central/Fusion. Este contrato no establece un nuevo procedimiento de API para APX ni instrucciones para dispositivos AP/UTM antiguos. El campo obligatorio Id identifica el AP local existente; Label es una denominación opcional, no una identidad alternativa. El ejemplo de referencia utiliza LocalWifi0/LocalWifi1, mientras que la ayuda de la interfaz utiliza LocalWiFi0. No corregir silenciosamente las mayúsculas y minúsculas ni enviar la barra como parte de un ID conjunto: confirmar la identidad individual real en el resultado de lectura/exportación correspondiente a la compilación. Country debe corresponder a la ubicación real, no al ejemplo In.

En el ejemplo, las asignaciones de red aparecen en WirelessNetworks/Network. La tabla describe Network como un array y advierte de que los valores duplicados no se ignoran. Por ello, cotejar todas las asignaciones existentes y no enviar una lista de SSID ni nombres de red supuestos. El límite de ocho Wireless Networks asignadas y los límites de hardware de las bandas de radio siguen siendo relevantes también en la automatización.

Para la asignación de bandas, la tabla describe Band con 2.4GHz o 5GHz; para 2,4 GHz, Channel, ChannelWidth, TXPower, DynChan y TimeBasedScan; y para 5 GHz, en cambio, Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz y TimeBasedScan5GHz. El ejemplo muestra horarios de exploración en ScanTime/Time; la tabla incluye Time dos veces como array dependiente de la banda, sin mostrar claramente la estructura padre de ambas bandas. Confirmar la estructura padre correcta para cada banda antes de una solicitud de escritura, en lugar de agrupar todas las entradas Time o inventar un elemento padre para 5 GHz. Los horarios de exploración de radio no son el horario de acceso al SSID.

Varios datos se contradicen: el ejemplo utiliza Channel2.4GHz y la tabla, Channel; para DynChan y TimeBasedScan, el ejemplo indica Enable, mientras que las listas de valores solo indican t. Para TXPower, el ejemplo muestra 100 y la tabla, en cambio, 10%, 25%, 50%, 75%, 100%. Tampoco es inequívoco el texto relativo a la asignación de banda de DynChan. No se ha confirmado que estas formas sean valores intercambiables. Además, la descripción de exportación de DynChan5GHz distingue entre Disabled (canal estático, exploración dinámica desactivada), 1 (canal automático sin exploración dinámica) y Enabled (canal automático con exploración dinámica); no tratar automáticamente los valores de exportación como entradas de escritura válidas.

BridgeToEthernet, BridgeToPort y Zone afectan al puente Ethernet local, no al ID de VLAN de los clientes de un perfil de red. Siguen siendo aplicables los límites de Gen.1/Gen.2, los requisitos de IPv4/Bridge-to-AP-LAN y las comprobaciones de DHCP/acceso administrativo descritos anteriormente. Después de un cambio confirmado, comprobar las dos radios afectadas, el país, las asignaciones de red, el puente y un cliente real antes de modificar otros AP.

La Status Message Information de la operación Update Local AP asigna estos valores de estado XML en ambas versiones de la referencia:

200, 216: Message.WPAPkUpdateSuccessfully; 500, 541, 543, 544, 545: Message.WPAPUpdateFail.
523: Message.WPNetworkGroupMax; 524: Message.WPAccessPointMax; 542: Message.WPAccessPointMesh.
547: Message.WPAPUpdateFailVLANGroup; 548: Message.WPA3IsNotSupported.
561: Message.LegacyModeNotSupported; 564: Message.TKIPModeNotSupported; 565: Message.TopazToNonTopazImportFail.

Son claves de referencia literales sin resolver, no mensajes de ejecución comprobados. En particular, no deducir de Message.TopazToNonTopazImportFail una correspondencia entre modelos ni una migración de importación permitida. Ante una respuesta poco clara, consultar la identidad del AP, los parámetros de radio y las asignaciones guardados, en lugar de repetir automáticamente la misma actualización o debilitar el cifrado.

WiFi6Interface: interfaz existente, no SSID ni bridge

WiFi6Interface administra, en las referencias XML para SFOS 22 y 23, los ajustes de red y zona por puerto de LocalWiFi6, no un perfil de SSID ni un bridge físico. Los campos obligatorios son Name, Hardware y Zone: Name es la denominación descriptiva, con un máximo de 58 caracteres; Hardware designa el nombre de hardware de la interfaz ya existente. Antes de realizar un cambio, confirmar esta identidad en el resultado de lectura/exportación correspondiente a la compilación, sin deducirla del nombre visible, de SSID ni de WirelessNetworks.HardwareName. El requisito de diez caracteres de A-Za-z0-9_ para el nombre de hardware de un bridge físico no se aplica aquí; la tabla de WiFi6Interface solo indica una cadena para Hardware. El nombre del objeto de la API tampoco implica una correspondencia con una generación de hardware. Las comprobaciones de bridge en la GUI, DHCP y acceso administrativo descritas anteriormente, que dependen del modelo, siguen siendo aplicables sin cambios.

IPv4Address y Netmask son opcionales en este contrato. Esto no implica ni la obligación de establecer una dirección nueva ni un efecto confirmado al omitir valores existentes. Antes de realizar cambios, documentar el puerto real, la zona y, si existe, la dirección IP con su máscara; después, volver a consultar el estado de esa misma interfaz y compararlo con el plan de direccionamiento previsto. Esta comprobación de la interfaz no sustituye ni la verificación de la asignación a AP y del SSID ni la prueba con un cliente real.

Para la operación WiFi6Interface, ambas fuentes muestran 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail y 502/Message.InterfaceIPAlreadyInUsed. Son valores de estado XML específicos del objeto con claves de referencia sin resolver, no códigos HTTP ni textos de ejecución confirmados. Registrar conjuntamente la operación, el código y la respuesta real depurada. Si el resultado no está claro, consultar primero la identidad de hardware, el puerto, la zona y, si procede, la IP/Netmask, en lugar de repetir automáticamente la misma actualización o crear otro objeto Wireless. Un código de éxito por sí solo no demuestra ni una asignación de red correcta ni que el tráfico Wi-Fi funcione; aquí no se deduce ninguna nueva solicitud de escritura.

WirelessNetworks: distinguir la identidad de hardware, el perfil y el estado

En WirelessNetworks, el Hardware name inmutable, el nombre visible modificable Name y el SSID emitido son valores distintos. En el ejemplo de invitados, son GuestWiFi, Guest WiFi y Company Guest. La tabla de parámetros de adición/actualización exige HardwareName con un máximo de diez caracteres; la operación de eliminación también identifica el destino mediante HardwareName, no mediante el SSID ni el nombre visible. Antes de una eliminación, comprobar las asignaciones a AP, la interfaz, DHCP y las reglas, y eliminar únicamente el destino identificado inequívocamente y autorizado. Un error no es motivo para volver a crear el perfil con un nombre nuevo.

Sin embargo, el ejemplo de adición/actualización utiliza Hardware en lugar de HardwareName y ClientIsolation con Enable en lugar del valor de la tabla Enabled. La misma discrepancia aparece en HideSSID; la tabla indica Enabled/Disabled para TimeBasedAccess, ClientIsolation, HideSSID y FastTransition. Asimismo, MACFiltering con Allowlist/Blocklist aparece junto a una descripción más antigua de MACList con Whitelist/Blacklist. No resolver ninguna de estas discrepancias mediante suposiciones. Además, el contrato XML enumera modos de seguridad antiguos, mientras que la ayuda actual de la interfaz describe WPA3 solo para los modelos W mencionados anteriormente: de ello no se deriva una sintaxis de escritura completa para WPA3.

Los tokens de tráfico documentados SeparateZone, BridgetoAPLAN y BridgetoVLAN pertenecen a ClientTraffic. IPAddress y Netmask se refieren a Separate zone; BridgetoVLANid, a la VLAN de los clientes; y ClientVlanId, a Static o RadiusAndStatic. No confundir estos valores con la VLAN de administración del AP. No utilizar la clave del ejemplo, la IP pública del ejemplo ni TKIP(only abg): el objetivo sigue siendo AES o un modo de seguridad más robusto cuya compatibilidad esté comprobada, una frase de contraseña propia y segura, y una separación de redes controlada. ClientIsolation sigue sin sustituir un límite de firewall o VLAN entre varias radios/AP.

Para Add Wireless Network, ambas referencias indican las siguientes correspondencias:

200: Message.WPNetworkSuccess; 500, 541, 545: Message.WPNetworkFail.
502: Message.WPNetworkExists; 503: Message.WPNetworkInterfaceExists; 542: Message.WPNetworkInterfaceIPExists.
544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.

Para Update Wireless Network, varias claves difieren pese a tener los mismos códigos:

200: Message.WPNetworkUpdateSuccessfully; 500, 541, 543, 545, 549: Message.WPNetworkUpdateFail.
503: Message.WPNetworkInterfaceExistsForUpdate; 542: Message.WPNetworkInterfaceIPExistsForUpdate.
544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.
546: Message.WPBindWithLA; 547: Message.APNotSupport5GHzWP.
561: Message.SecModeChangedToLegacyFail; 562: Message.SecModeChangedToWAP3Fail; 563: Message.EncModeChangedToTKIPFail.

Para Delete Wireless Network, se documentan 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists y 542/Message.WPEnableDeteleFail. Incluso los aparentes errores tipográficos, como Message.SecModeChangedToWAP3Fail y Message.WPEnableDeteleFail, se mantienen sin cambios; no se renombran como supuestos mensajes de ejecución correctos. Ante estas respuestas, cotejar primero la identidad de hardware, la IP, las dependencias de DHCP, el puente y las asignaciones a AP realmente guardados. No afirmar una causa, una reversión correcta ni la seguridad de un reintento basándose únicamente en una clave.

WirelessNetworkStatus es un objeto independiente: su tabla describe expresamente Name como nombre de interfaz con un máximo de diez caracteres, no como alias automático del SSID o del nombre visible. Aquí, Status utiliza Enable/Disable, no los valores Enabled/Disabled de otros campos. Confirmar previamente el nombre real de la interfaz. Para Enable-Disable Wireless Network, se indican 200/Message.WPNetworkUpdateSuccessfully y 500/Message.WPNetworkUpdateFail. Un cambio de estado no asigna la red a ningún AP ni demuestra todavía que se esté emitiendo; comprobar por separado el estado guardado, la asignación a AP y la conexión del cliente.

WirelessGrouping: la pertenencia a un grupo no es una configuración de radio

WirelessGrouping describe un grupo de AP con Name y las entradas que pueden repetirse WirelessNetworks/Network y AccessPoints/AccessPoint. Utilizar las identidades de los AP del inventario existente, no el antiguo ejemplo AP30 de la referencia. La estructura de grupo configura las asignaciones de red y el etiquetado opcional para la administración de los AP, pero no los parámetros de radio locales dependientes de la banda. Los arrays opcionales no implican una semántica confirmada para listas vacías ni una actualización parcial segura.

VLANTagging indica Enable/Disable; APVLANID indica de 1 a 4094 y se aplica cuando el etiquetado está activado. Esta es la VLAN de administración de los AP, no BridgetoVLANid para los clientes. Antes de realizar cambios, comprobar la lista completa de miembros, el enlace troncal, el DHCP de administración, Allowed zone y la vía de reversión. Desactivar un grupo sigue deteniendo la emisión de sus AP; después de un cambio confirmado, comprobar cada AP afectado y los SSID previstos.

Para Add an Access Point Group, se indican 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP y 546/Message.WPA3IsNotSupported. Para Update an Access Point Group, en cambio, se indican 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate y 546/Message.WPA3IsNotSupported. La desconcertante clave Message.WPGroupCreated asociada a códigos de error no garantiza el éxito. Antes de un reintento, consultar el grupo y los miembros guardados, en lugar de crear un segundo grupo o incorporar más AP.

Ajustes globales: acceso de administración y efectos posteriores

WirelessProtectionGlobalSettings no es un perfil de SSID ni una zona de clientes. En el ejemplo, AllowedZone/Zone contiene las zonas de administración que pueden repetirse; NotificationTimeout corresponde al tiempo de espera para la notificación de desconexión, en minutos, explicado anteriormente. RADIUSServer designa el servidor seleccionado globalmente para la modalidad Enterprise descrita. Para el interruptor, el ejemplo utiliza WirelessProtection y la tabla, en cambio, EnableWirelessProtection: aclarar también estos nombres de campo discrepantes para la compilación específica antes de una solicitud de escritura.

Para Global Settings, ambas referencias indican 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed y 504/Message.WLANAPIntBaseVHExist. Otras distinciones son:

511: Message.WLANAPFailedWhileUnbinding; 512: Message.WLANAPFailedWhileDeleteDHCPServer; 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
516: Message.WLANAPFailedToUnbindInterface; 520: Message.WLANAPFailedToUnbindIfaceRCg; 521: Message.WLANAPEditRunConfigFailed.
523: Message.WLANAPWLAN1UnboundEditFaild; 524: Message.WLANAPOtherUnboundEditFaild.

Las claves no se interpretan como causas de error demostradas, pero muestran por qué un cambio global no debe tratarse como una prueba inocua: las vinculaciones de interfaces y la configuración de DHCP pueden verse afectadas. No desactivar y volver a activar Wireless Protection para realizar un diagnóstico rápido. Antes de un cambio planificado, guardar una copia de seguridad y registrar un acceso administrativo independiente, las interfaces, los servidores/relés DHCP y las asignaciones a AP. Después, consultar el estado global realmente guardado y los servicios afectados, comprobar la accesibilidad de los AP y los clientes, y solo con estas evidencias decidir si se repite la operación o se utiliza la vía de reversión confirmada. Un código de éxito XML por sí solo no demuestra ni el efecto sobre la radio ni el éxito completo de la configuración.