Configurar y probar Wireless Mesh en una instalación APX existente de Sophos Firewall

Wireless Mesh en Sophos Firewall conecta uno o varios Sophos Access Points APX de forma inalámbrica con un AP raíz cableado. Puede cubrir una zona sin cobertura cuando no hay cableado Ethernet en la ubicación remota. El backhaul mesh no es el SSID WLAN visible: SFOS crea para él una red WPA2-Personal oculta con una contraseña aleatoria. Los clientes siguen usando un Wireless Network configurado por separado.

⚠️ Importante: Esta guía se aplica a instalaciones APX existentes gestionadas directamente por SFOS. APX solo puede formar un mesh con APX. AP6, LocalWiFi integrado, módulos Wi-Fi de SD-RED y series de AP Sophos mezcladas no forman parte de este procedimiento. Un mesh tampoco sustituye a una redundancia cableada: Al menos un AP permanece conectado por LAN y SFOS no cambia automáticamente el AP raíz si este falla.

Ámbito de aplicación: instalaciones existentes, no una nueva plataforma WLAN

Los siguientes pasos describen un mesh heredado gestionado por el firewall para un conjunto APX existente, no la creación de una nueva plataforma APX o UTM. Antes de realizar cualquier cambio, debe confirmarse la compatibilidad del modelo concreto de AP, su revisión de hardware y el build de SFOS realmente utilizado. La ayuda de Wireless de SFOS 22 y SFOS 23 incluye procedimientos mesh antiguos; la existencia de una página de ayuda no demuestra que el hardware sea compatible. En particular, no debe deducirse de ella que se pueda actualizar una instalación APX a SFOS 23. Si la compatibilidad no está confirmada, mantener la configuración existente y aclarar primero la compatibilidad entre modelo y build y la migración.

AP6 mesh utiliza una vía de gestión distinta: Un conjunto AP6 gestionado de forma centralizada se configura en Sophos Fusion, anteriormente Sophos Central, no en Wireless > Mesh networks del firewall. Una Sophos Firewall puede seguir actuando como router y perímetro de seguridad en la ruta de datos, pero no se convierte en el controlador de AP6. APX y AP6 no deben formar parte del mismo mesh. El registro y los requisitos de red de esta vía independiente se explican en Requisitos de Sophos Central Wireless; la planificación específica, la configuración mesh y la validación se describen en Planificar y configurar AP6 mesh. Los roles APX, las asignaciones de SSID y los pasos de reversión mostrados aquí no se aplican a AP6.

El modelo para exteriores APX 320X no forma parte de este procedimiento gestionado por el firewall. Las referencias a la antigua serie de AP Sophos y a los roles manuales en guías anteriores explican instalaciones históricas, no una instalación nueva compatible en la actualidad. Tampoco LocalWiFi integrado ni los módulos Wi-Fi de SD-RED pueden sustituir a los dos APX externos del ejemplo; sus requisitos de WLAN y de modelo deben comprobarse por separado. Aquí no se actualizan las guías de UTM ni se recomiendan como vía para una nueva instalación.

Procedimiento breve:

1. Conectar primero ambos APX por LAN, aceptarlos en Wireless > Access points y comprobar firmware, Country y planificación de radio.
2. Configurar el mismo canal fijo en todos los AP participantes para la banda mesh y desactivar Dyn chan.
3. Configurar Mesh-ID, Frequency band y los APX en Wireless > Mesh networks > Add.
4. Asignar el SSID visible de clientes por separado a ambos APX.
5. Guardar la configuración, desconectar el cable LAN del AP mesh, reiniciar los APX y esperar hasta cinco minutos.
6. Comprobar de forma controlada estado del AP, conexión del cliente, DHCP, Rule ID, acceso a internet y fallo de la ruta raíz.

Cuándo encaja un mesh APX

Un mesh encaja en una instalación APX existente cuando un único punto de acceso remoto no dispone de Ethernet y el enlace de radio con el AP raíz es suficientemente estable. Algunos ejemplos son una pequeña zona de almacén, una sala de reuniones o un área temporal que se cableará más adelante.

Un uplink Ethernet sigue siendo la mejor base técnica para una capacidad elevada sostenida, latencia estable y failover predecible. El backhaul mesh comparte tiempo de radio con otras transmisiones. Por eso hay que medir el rendimiento real con los clientes y aplicaciones previstos, en lugar de deducir la capacidad útil a partir del estado del enlace.

El límite de producto también importa en instalaciones nuevas: APX ya está End-of-Sale y alcanza el End-of-Life el 31 de diciembre de 2027. Por eso conviene incluir en la planificación a medio plazo el ciclo de vida de APX y AP6 como sucesor. AP6 no se gestiona mediante SFOS.

Entender backhaul mesh, SSID de cliente y roles

Estos componentes cumplen funciones diferentes:

• Mesh network: backhaul de radio oculto entre los APX. La Mesh-ID identifica el grupo; SFOS gestiona la contraseña WPA2 aleatoria.
• AP raíz: APX con conexión Ethernet existente al firewall. En APX, este rol se deriva automáticamente del cableado.
• AP mesh: APX sin uplink Ethernet que alcanza el AP raíz por radio.
• Wireless Network: SSID visible para clientes con Security mode, Client traffic, DHCP y reglas. La base completa se explica en Configurar WLAN directamente en Sophos Firewall.

En series antiguas de AP Sophos hay que asignar explícitamente los roles raíz y mesh. Este artículo utiliza solo APX y por eso no traslada esa antigua pantalla de roles a los pasos de ejemplo.

Repetidor o wireless bridge

En modo repetidor, el AP mesh emite el SSID de cliente asignado en la ubicación remota. Los endpoints se conectan por Wi-Fi y el AP transporta sus datos al AP raíz mediante el backhaul mesh.

Con un wireless bridge se conecta además un segmento Ethernet al puerto de red del AP mesh. Este diseño amplía Layer 2 y puede crear bucles si existe al mismo tiempo una segunda ruta por cable. Por eso debe aplicarse en una ventana de mantenimiento con una vía de recuperación documentada. STP debe encajar con todo el diseño de switches y bridges; no se desactiva simplemente porque bloquee una ruta.

Para la mayoría de ampliaciones pequeñas, el modo repetidor resulta más claro. Solo se debe usar un bridge cuando el segmento Ethernet remoto sea realmente necesario y se entiendan su comportamiento de broadcast, VLAN y bucles.

Comprobar los límites antes de configurar

Un mesh APX tiene límites de producto claros:

• Todos los access points participantes deben pertenecer a la serie APX.
• Solo se puede usar una red mesh por AP.
• Al menos un APX debe permanecer conectado por LAN al firewall.
• Todos los AP mesh usan el mismo canal en la banda mesh.
• Dynamic Channel Selection, es decir, Dyn chan, no debe estar activo en esa banda porque, tras un reinicio, los AP podrían acabar en canales diferentes.
• En APX no se pueden configurar ambas radios a 5 GHz al mismo tiempo cuando se usa mesh.
• Los AP con VLAN asignada solo pueden formar un mesh si las VLAN no usan el modo Client traffic Bridge to VLAN.
• Una segunda red mesh en el mismo AP no funciona.
• Otro AP mesh no asume automática e ininterrumpidamente el fallo del AP raíz.

La ayuda actual de Sophos menciona 2.4 GHz para el backhaul mesh y 5 GHz para los SSID de clientes como posible punto de partida. No es una práctica recomendada universal. Distancia, paredes, interferencias, canales disponibles, Country regulatorio y capacidad necesaria determinan el diseño real.

Cómo interpretar la discrepancia entre documentos: La guía de despliegue antigua indica 5 GHz en el AP raíz y 2.4 GHz en el AP mesh; en cambio, la guía para añadir un mesh distingue entre 5 GHz para los SSID de clientes y 2.4 GHz para el backhaul mesh. Estas formulaciones no deben llevar a configurar bandas de backhaul distintas en el AP raíz y el AP mesh. En el procedimiento documentado aquí para instalaciones existentes, ambos AP deben utilizar la misma banda mesh seleccionada y el mismo canal fijo. El ejemplo 2.4 GHz no es obligatorio; antes de utilizar otra banda, comprobar la compatibilidad del modelo y el build, así como la ruta de radio. Sigue vigente la limitación de APX que impide configurar ambas radios a 5 GHz al mismo tiempo.

Planificar la topología de ejemplo

El ejemplo utiliza estos nombres:

• Firewall: fw01
• APX cableado: ap-office-root
• APX inalámbrico: ap-warehouse-mesh
• Mesh-ID: OfficeMesh
• Wireless Network visible: Company WiFi
• Banda mesh: 2.4 GHz
• Canal mesh: un canal fijo probado en la ubicación

OfficeMesh es un ejemplo de documentación y se sustituye por un nombre corto y único de la instalación. No se debe confundir la Mesh-ID con el SSID visible. En el ejemplo, Company WiFi ya existe con Client traffic, DHCP, reglas de firewall y NAT adecuados.

Antes del cambio se preparan un backup actual de la configuración, un acceso de gestión cableado y un plan de rollback. Ambos APX reciben PoE y, para su configuración inicial, se prueban dentro del alcance de sus ubicaciones definitivas. El AP raíz debe seguir siendo accesible allí por Ethernet.

Preparar los access points y el canal de radio

Aprovisionar primero ambos APX por LAN

1. Conectar ap-office-root y ap-warehouse-mesh por Ethernet a la red de gestión prevista.
2. En Wireless > Wireless settings, comprobar que Wireless Protection está activo y que la zona de gestión está permitida en Allowed zone.
3. En Wireless > Access points, aceptar ambos APX pending con Accept.
4. Configurar el Country correcto para ambos APX. Después de cambiar Country, guardar y reiniciar los APX de forma controlada para actualizar la lista de canales.
5. Comprobar que ambos APX están activos y han recibido su configuración actual.

El cableado inicial no es una comodidad opcional. Un APX que no haya recibido la configuración mesh no puede incorporarse después al grupo únicamente por radio.

Antes del despliegue también hay que planificar la versión de firmware APX mediante las actualizaciones de patrones de Sophos Firewall. Una actualización de firmware y la transición al mesh no deben realizarse simultáneamente sin control.

Configurar un canal fijo común

1. En Wireless > Access points, abrir el primer APX.
2. En Advanced settings, configurar un canal fijo probado localmente en el campo Channel 2.4 GHz o Channel 5 GHz correspondiente.
3. Desactivar Dyn chan para esa banda.
4. Aplicar la misma configuración al segundo APX.
5. Cuando sea posible, colocar los AP cercanos que no forman parte del mesh en otro canal con pocas interferencias.

No se elige un canal solo porque funcione bien en el ejemplo. Un escaneo local, los requisitos de Country y el uso de canales vecinos determinan la elección. Después de cada cambio de canal, ambos AP mesh deben volver a mostrar el mismo valor.

Crear Wireless Mesh en SFOS

Crear la red mesh

Para el backhaul mesh se crea una red mesh nueva e independiente, o un nuevo SSID mesh; el SSID visible de clientes existente, Company WiFi, no se convierte en una red mesh. La ayuda utiliza tanto Mesh-ID como mesh-enabled SSID para referirse a ello. Si la interfaz existente solo ofrece Enable mesh mode al crear un SSID nuevo, utilizar esta vía heredada documentada únicamente con el modelo y el build cuya compatibilidad se haya confirmado, y mantener separado el SSID de cliente. Solo se admite una red mesh por AP. Todos los AP participantes deben recibir la misma Mesh-ID y comparten la contraseña WPA2-Personal generada aleatoriamente por SFOS. No es la contraseña de la WLAN de clientes.

1. Abrir Wireless > Mesh networks.
2. Seleccionar Add.
3. Introducir OfficeMesh como Mesh-ID.
4. En Frequency band, seleccionar la banda común planificada, 2.4 GHz en el ejemplo.
5. Añadir ap-office-root y ap-warehouse-mesh.
6. Guardar.

Con APX no es necesario asignar un rol manualmente en este procedimiento. Mientras ambos APX siguen cableados, primero reciben la configuración. Después de desconectar ap-warehouse-mesh, ap-office-root permanece como AP raíz por su conexión Ethernet.

Asignar el SSID visible de clientes

La red mesh no es visible para los endpoints. Por eso, en Wireless > Access points o mediante un Access Point Group adecuado, también se asigna Company WiFi a ambos APX.

El SSID de cliente conserva su propio Security mode y Client traffic. Con Separate zone deben ser correctos especialmente Wireless interface, DHCP, regla de firewall, NAT y Device Access. Un mesh funcional no corrige una regla WLAN ausente ni una ruta DHCP incorrecta.

Trasladar el AP mesh a su ubicación

1. Comprobar que la configuración y el SSID visible de clientes han llegado a ambos APX.
2. Retirar el cable Ethernet solo de ap-warehouse-mesh.
3. Mantener cableado ap-office-root.
4. Colocar el AP mesh en la ubicación prevista y encenderlo; de este modo arranca ya sin Ethernet.
5. Reiniciar el AP raíz de forma controlada. Si el traslado no ha cortado la alimentación del AP mesh, reiniciarlo también en este momento.
6. Esperar hasta cinco minutos antes de considerar fallida la conexión.

En el funcionamiento mesh normal solo queda un APX conectado por LAN. Si el segundo APX se conecta por error a la misma red Layer 2, hay que comprobar el diseño en busca de bucles y revisar el efecto de STP.

Validar Wireless Mesh de forma controlada

La validación combina el estado del controlador, la ruta de radio y tráfico de usuario real:

1. En Wireless > Access points, ambos APX deben estar activos. ap-office-root permanece cableado; ap-warehouse-mesh es accesible sin Ethernet.
2. Comprobar la asignación mesh y el canal idéntico en ambos APX.
3. Conectar un cliente de prueba cerca de ap-warehouse-mesh a Company WiFi.
4. En Wireless > Wireless client list, mostrar el cliente de prueba por AP o SSID y comprobar que está asociado al AP mesh esperado y a Company WiFi. Anotar la intensidad de señal y la frecuencia, y repetir la comprobación en condiciones similares al comparar con el AP raíz; la frecuencia de cliente mostrada, por sí sola, no demuestra qué banda utiliza el backhaul.
5. Comparar dirección IP, gateway y DNS del cliente con el Wireless Network planificado.
6. Probar un destino permitido y otro bloqueado de forma deliberada.
7. En Log Viewer, filtrar por la IP del cliente y comprobar la Firewall Rule ID y NAT Rule ID esperadas.
8. Ejecutar una prueba realista de rendimiento y latencia y compararla con un cliente en el AP raíz.

Un estado verde del AP todavía no confirma toda la ruta de datos. El éxito significa que el cliente usa el AP, la dirección y las reglas previstas, y que el rendimiento es suficiente para la aplicación. El procedimiento general se describe en Probar correctamente las reglas de firewall.

Probar conscientemente el límite de fallo

El AP raíz es una dependencia conocida. En una ventana de mantenimiento se puede desconectar brevemente su uplink y documentar cuánto tiempo se interrumpe el acceso de los clientes. SFOS no promete un cambio automático de root. Es posible que haya que reiniciar y cablear un AP mesh para establecer un nuevo rol.

Esta prueba no es motivo para apagar sin planificación un AP raíz productivo. En áreas críticas conviene utilizar un uplink cableado para el AP o planificar otra arquitectura WLAN.

Interpretar de forma segura el objeto Mesh en la XML API

Las referencias XML de SFOS 22 y 23 describen Add Mesh Networks y Update Mesh Networks para el objeto WirelessMeshNetworks. Se trata de una estructura de objeto documentada, no de una autorización adicional de hardware: el alcance limitado a los APX existentes, la comprobación del modelo y la compilación, y la vía de administración independiente para AP6 indicados anteriormente permanecen sin cambios. La protección del acceso, las operaciones explícitas, las respuestas XML y los reintentos seguros se explican en Proteger el acceso a la XML API de Sophos Firewall.

Distinguir MeshID, banda y rol del AP

Al preparar una automatización, deben distinguirse estos campos:

• MeshID es una cadena escalar obligatoria de un máximo de diez caracteres. OfficeMesh sirve como nombre de ejemplo breve; sigue siendo el ID del backhaul, no el SSID visible para los clientes. No interpretar el marcador de referencia adicional APINTERFACENAME como una regla de caracteres autoexplicativa ni como la identidad del AP; confirmar el formato permitido en la compilación instalada.
• FrequencyBand es obligatorio y admite exactamente 5GHz o 2.4GHz. La tabla indica 5 GHz como valor predeterminado documentado, no como recomendación para todas las rutas de radio. La notación combinada 5GHz/2.4GHz del ejemplo de referencia no figura en la lista de valores permitidos y no se adopta como valor único del campo. Todos los AP implicados siguen necesitando la misma banda de backhaul confirmada y el mismo canal fijo; Dyn chan permanece desactivado en esa banda.
• Description es una cadena escalar opcional. Un elemento vacío en el ejemplo no demuestra cómo trata una actualización una descripción existente.
• AccessPoints contiene MeshNetwork en el ejemplo XML; dentro de este aparecen juntos AccessPoint y Role. La tabla de parámetros describe ambos campos como arrays opcionales con varios valores y señala que los duplicados no se ignoran. No deducir de ello que se trata de dos listas que pueden ordenarse de forma arbitraria e independiente ni que existe una deduplicación automática. Comprobar conjuntamente la identidad del AP y su rol asociado frente a la configuración existente y API help de la compilación.
• Para Role están documentados exactamente MeshAccessPoint y RootAccessPoint; la tabla indica Root Access Point como valor predeterminado. Estos valores XML proceden de la referencia de la API, no de los términos Root, Mesh o Repeater de la GUI. En particular, la asignación automática de roles de APX mediante Ethernet no demuestra si Role debe establecerse, omitirse o tratarse de otra manera en el payload APX concreto. Si no se ha aclarado la correspondencia entre el modelo y la compilación, no enviar ninguna solicitud de escritura.

El siguiente fragmento limitado de la estructura XML no es una solicitud ejecutable ni una asignación de roles de APX. Solo muestra el anidamiento documentado con un valor de referencia para Role; AP_IDENTITAET_AUS_API_HELP es un marcador de posición que no puede enviarse. La identidad AP30 del ejemplo del fabricante no se adopta como ejemplo de APX:

<WirelessMeshNetworks>
  <MeshID>OfficeMesh</MeshID>
  <FrequencyBand>2.4GHz</FrequencyBand>
  <Description />
  <AccessPoints>
    <MeshNetwork>
      <AccessPoint>AP_IDENTITAET_AUS_API_HELP</AccessPoint>
      <Role>RootAccessPoint</Role>
    </MeshNetwork>
  </AccessPoints>
</WirelessMeshNetworks>

Antes de realizar un cambio, consultar y guardar la configuración del conjunto realmente almacenada, incluidos el ID de mesh, las identidades de los AP, las asignaciones y los parámetros de radio, y compararla con el estado de destino previsto. El fragmento no contiene ni inicio de sesión ni operación alguna y no sustituye a un payload completo confirmado. La estructura XML no garantiza ni un reintento seguro ni una conexión de radio funcional; sigue siendo necesaria la validación independiente del estado de los AP, el SSID de los clientes, DHCP y la ruta de tráfico de datos.

Distinguir las respuestas por operación, código y símbolo

Las referencias asignan a las dos operaciones los siguientes códigos de estado XML y claves literales Message.*. Las claves no están resueltas: no son mensajes de ejecución confirmados y no se traducen como si fueran textos de mensajes de error. La correspondencia específica del objeto debe contrastarse con API help de la compilación instalada; en particular, no interpretar aquí 521 y 522 únicamente a partir de la tabla general de estados del artículo central sobre la API.

Add Mesh Networks:

• 200: Message.WLANAPAddSuccessful.
• 500: Message.WLANAPAddFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 521: Message.WLANAPAddRunConfigFailed.
• 522: Message.WLANAccessPointUnbound.

Update Mesh Networks:

• 200: Message.WLANAPEditSuccessful.
• 500: Message.WLANAPEditFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 511: Message.WLANAPFailedWhileUnbinding.
• 512: Message.WLANAPFailedWhileDeleteDHCPServer.
• 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
• 516: Message.WLANAPFailedToUnbindInterface.
• 520: Message.WLANAPFailedToUnbindIfaceRCg.
• 521: Message.WLANAPEditRunConfigFailed.
• 523: Message.WLANAPWLAN1UnboundEditFaild.
• 524: Message.WLANAPOtherUnboundEditFaild.

También se conserva exactamente la grafía Faild. No deducir de los nombres de los símbolos una causa demostrada, la reversión completa de un cambio ni que ya se haya eliminado una dependencia de DHCP o de una interfaz. Tras una respuesta ambigua o fallida, comparar primero el estado de mesh y de los AP realmente guardado, así como las configuraciones dependientes de redes inalámbricas, interfaces y DHCP, con el estado inicial guardado; conservar la respuesta y los registros depurados para aclarar lo ocurrido. Solo después de la aclaración específica de la compilación debe decidirse si se realiza otro cambio; no repetir automáticamente el mismo Add o Update. Tampoco 200 sustituye la consulta posterior del objeto de destino ni la validación de radio y clientes indicada anteriormente.

Acotar errores según el síntoma

El AP mesh no aparece o permanece offline

Después de configurar, esperar hasta cinco minutos. Si el AP sigue offline, comprobar primero si estuvo activo durante el aprovisionamiento inicial por LAN y recibió la configuración mesh. Después revisar serie APX, asignación mesh, banda, canal común, Dyn chan, Country y alimentación.

El AP raíz debe permanecer cableado. Si ambos AP son inalámbricos o se ha desconectado de Ethernet el AP equivocado, falta la ruta al firewall. Tras corregirlo, reiniciar los APX de forma controlada y volver a esperar.

Si, en un procedimiento anterior, la opción Enable mesh mode no aparece para un SSID existente, hay que crear un SSID nuevo en vez de reutilizar el SSID visible de clientes. Si la causa sigue sin estar clara, se puede aislar la ruta durante una ventana de mantenimiento emitiendo únicamente la red mesh en el AP raíz y únicamente el SSID visible de clientes en el repetidor. Si el SSID de cliente aparece en el repetidor, esto indica inicialmente que se está emitiendo la configuración de clientes, pero todavía no demuestra por completo que el backhaul funcione ni que haya acceso a internet. Comprobar además que el repetidor sea realmente accesible sin uplink LAN, que el cliente de prueba aparezca en la lista de clientes asociado a ese AP y que funcionen el DHCP esperado y la ruta de datos permitida. Después se restauran las asignaciones normales. Si el mesh sigue sin poder utilizarse, hay que comprobar si STP bloquea la configuración mesh. STP no debe desactivarse sin más: evita bucles en las topologías bridge.

El SSID de cliente no es visible

La Mesh-ID no se emite deliberadamente como SSID de cliente. En Wireless > Access points debe asignarse al AP mesh un Wireless Network visible adicional. Si solo está configurado OfficeMesh, los endpoints no disponen de una red visible.

También hay que revisar Frequency band, horario, Security mode y asignación de AP del SSID de cliente. Una segunda red mesh en el mismo AP no es la solución, porque solo se admite una por AP.

El cliente se conecta pero no obtiene una dirección IP

En ese caso, la ruta de radio ya funciona al menos parcialmente. A continuación se revisan Client traffic, Wireless interface, servidor DHCP o DHCP relay y posibles rutas VLAN. Con Bridge to VLAN también debe respetarse el límite del producto mesh: los AP con VLAN asignadas solo pueden formar un mesh si las VLAN no utilizan este modo Client traffic.

Reiniciar el servicio inalámbrico no es un paso estándar. Primero hay que demostrar a qué AP está conectado el cliente y si las solicitudes DHCP recorren la ruta esperada.

El cliente tiene una dirección IP pero no internet

En Log Viewer se buscan primero la Firewall Rule ID y NAT Rule ID esperadas. Si faltan ambas, el problema está probablemente en zona, objeto de red, orden de reglas o ruta de datos, y no en el propio mesh. Si las reglas coinciden, se revisan después DNS, gateway y ruta WAN.

Una regla Any amplia no sirve como diagnóstico mesh. La misma prueba de cliente se realiza una vez en el AP raíz y otra en el AP mesh. Si solo funciona en el root, se sigue investigando el backhaul; si falla en ambos AP, el error pertenece probablemente a la configuración común de WLAN o firewall.

La conexión es inestable o lenta

Comprobar canal idéntico en todos los AP mesh, Dyn chan desactivado, calidad de señal, interferencias, distancia y paredes. Los AP que no pertenecen al mesh no deberían ocupar innecesariamente el mismo canal. Además, debe quedar capacidad de radio suficiente para backhaul y clientes.

El rendimiento se compara con la misma aplicación, el mismo cliente y condiciones tan similares como sea posible en AP raíz y AP mesh. Así se separa la ruta mesh de un problema general de WAN, DNS o cliente.

El estado del controlador o del cliente sigue sin estar claro

Los logs de servicio de Sophos Firewall ayudan en el diagnóstico local del nodo. En Advanced Shell son útiles estas comprobaciones de solo lectura:

tail -n 200 /log/awed.log
tail -n 200 /log/wc_remote.log

awed.log muestra la comunicación entre controlador y APX; wc_remote.log ayuda con los clientes inalámbricos. Una entrada aislada del log no demuestra la ruta de tráfico. Hay que correlacionar marcas de tiempo, estado del AP, lista de clientes, logs del firewall y una prueba reproducible. Los LED y códigos de parpadeo de los Sophos Access Points ayudan además a clasificar estados de arranque, actualización y mesh en el dispositivo.

Revertir el mesh de forma segura

Distinguir entre SSID mesh y SSID de cliente al revertir la configuración: La ayuda antigua describe la desactivación mediante la eliminación del SSID mesh. Se refiere al objeto de configuración mesh correspondiente, no, de forma general, al SSID visible de clientes Company WiFi. Antes de eliminarlo, cotejar la Mesh-ID, las asignaciones de AP y las dependencias, guardar una copia de la configuración y garantizar que los AP sean accesibles por la ruta cableada prevista. Eliminar el backhaul interrumpe la conexión de los AP enlazados por radio; eliminar un SSID de cliente que siga siendo necesario desconectaría además a sus usuarios WLAN. Según la interfaz heredada, la reversión se realiza mediante la red mesh o su SSID mesh. Si no se puede identificar inequívocamente el objeto correspondiente, no eliminar nada por suposición: aclarar primero la configuración concreta del modelo y el build.

El rollback se realiza de forma controlada mientras funciona el acceso de gestión cableado:

1. Documentar qué APX es root y cuál es el AP mesh.
2. Volver a conectar el AP mesh por LAN a la red de gestión y esperar hasta que esté activo.
3. Si es necesario, trasladar el SSID visible de clientes a un AP cableado que permanezca.
4. Quitar la red mesh de los APX o eliminarla en Wireless > Mesh networks.
5. Restaurar las configuraciones anteriores de canal y Dyn chan solo de forma consciente.
6. Reiniciar ambos APX de forma controlada.
7. Volver a comprobar IP del cliente, DNS, reglas y acceso a internet.

Un reset de fábrica solo tiene sentido cuando el APX ya no acepta una configuración gestionada pese a que cableado, alimentación y ruta al controlador son correctos. No sustituye a un rollback documentado.

Lista de comprobación operativa

• Todos los dispositivos participantes son APX compatibles y se aprovisionaron primero por LAN.
• Hay exactamente una red mesh asignada por AP.
• Un APX permanece cableado de forma permanente como root.
• La banda mesh y el canal fijo coinciden en todos los APX participantes.
• Dyn chan está desactivado en la banda mesh.
• El SSID visible de clientes se ha asignado por separado.
• Se han comprobado DHCP, Firewall Rule ID, NAT Rule ID y un destino bloqueado.
• Se han comparado rendimiento y estabilidad en AP raíz y AP mesh.
• Se han documentado fallo del root, ausencia de takeover automático y rollback.
• Se han planificado el End-of-Life de APX y un cambio posterior de plataforma WLAN.

FAQ