Solucionar problemas de ARP tras migrar Sophos Firewall

Tras cambiar un firewall, el nuevo Sophos Firewall puede estar conectado mientras algunas direcciones IP alias públicas siguen sin ser accesibles. A menudo, el router upstream todavía asocia estas direcciones con la dirección MAC WAN del dispositivo anterior. En ese caso, los paquetes ni siquiera llegan al nuevo firewall, aunque el alias, la DNAT y la regla de firewall parezcan correctos.

Esta guía muestra cómo acotar este problema de IPv4 mediante la comprobación de interfaces, Packet Capture y ARP upstream. La caché ARP solo se actualiza en el dispositivo que conserva la entrada obsoleta cuando se ha demostrado que la causa está en la capa 2. Para la migración general de hardware, consulte también Comparar Sophos XG y XGS Appliance.

Cuándo sospechar realmente de ARP

Este problema suele aparecer inmediatamente después de sustituir un dispositivo, restaurar una configuración o cambiar de fabricante. La IP pública permanece igual, pero cambia la dirección MAC de la interfaz WAN.

Los indicios más claros son:

La IP principal de la interfaz WAN funciona, pero una o varias direcciones IP alias no.
Una prueba externa no alcanza un servicio publicado en determinadas IP públicas.
Packet Capture no muestra ningún paquete entrante para la IP afectada.
El servicio empieza a funcionar de repente cuando caduca una caché upstream, sin realizar más cambios en el firewall.
El router upstream sigue mostrando la dirección MAC del dispositivo anterior para la IP pública.

ARP no es automáticamente la causa. Si los paquetes llegan a la interfaz WAN, el siguiente paso es comprobar la DNAT, la regla de firewall, la zona, el servidor interno o la ruta de retorno. Este procedimiento tampoco se aplica a IPv6, que utiliza Neighbor Discovery para resolver vecinos.

Para comprobar en cambio la caché ARP o NDP local de Sophos Firewall, consulte Comprobar la caché de vecinos ARP y NDP. También explica cuándo conviene vaciar la caché y cuándo el problema sigue estando en el proveedor o el dispositivo upstream.

Por qué las IP alias pueden fallar tras una sustitución

ARP asigna una dirección IPv4 a una dirección MAC dentro del segmento local de capa 2. El router guarda esta asociación en la caché ARP. Después de sustituir el dispositivo, el upstream debería aprender la dirección MAC WAN del nuevo firewall. Si esto no sucede para una IP alias, seguirá enviando los paquetes al hardware anterior.

Esto explica por qué la IP principal puede funcionar mientras falla una IP alias: el upstream mantiene una entrada distinta para cada dirección IP. Una asociación puede estar actualizada mientras otra todavía apunta a la dirección MAC anterior.

Sin embargo, primero hay que determinar cómo entrega el proveedor las direcciones públicas:

Red conectada directamente: El upstream resuelve por ARP tanto la IP principal como las IP alias. Después de cambiar el hardware, es plausible que queden entradas antiguas.
Bloque público enrutado: El proveedor enruta el bloque hacia la IP WAN principal. En ese caso, no tiene por qué existir una entrada ARP propia para cada IP pública; la ruta del proveedor y la configuración local de alias o NAT son más importantes.

Diagnóstico antes de intervenir

El diagnóstico debe mostrar primero en qué punto termina el flujo de paquetes. Así se evita cambiar a la vez ARP, NAT y las reglas de firewall.

En Network > Interfaces, compruebe la interfaz WAN física y las direcciones afectadas. Una IP alias se vincula a la interfaz física correcta mediante Add interface > Add alias; la versión de IP, la dirección y la máscara de red deben ajustarse al diseño. Si hay más de tres alias, SFOS solo muestra inicialmente tres direcciones. Pase el puntero por una dirección visible y desplácese por la lista antes de volver a crear un alias que parezca ausente.
Si las direcciones alias pertenecen a otra subred, los hosts internos deben usar Sophos Firewall como gateway predeterminado y el upstream debe tener en cada subred de alias una dirección que actúe como gateway accesible para el firewall. Según Sophos, varias interfaces WAN independientes en la misma subred provocan problemas de ARP y gateways inaccesibles; use interfaces alias o LAG según el diseño.
Compruebe la misma IP pública y el mismo servicio desde un sistema de prueba realmente externo. Un ping por sí solo no basta, ya que ICMP puede estar bloqueado; añada una prueba sobre un puerto TCP conocido.
En Diagnostics > Packet capture, active la captura y abra Display filter. Para comprobar la capa 2, seleccione Interface name y Ethernet type: ARP. Para el servicio, use Ethernet type: IPv4, la Destination IP afectada y, si es necesario, Destination port. Sin Wrap capture buffer once full, la captura se detiene cuando se llena el búfer de 2048 KB; pulse Clear y repita la prueba reproducible. Con la opción activada, la captura continúa desde el principio del búfer y sobrescribe los paquetes anteriores.
Solo cuando lleguen paquetes IP, busque en Log viewer la IP de destino, el servicio y las identificaciones Firewall Rule ID y NAT Rule ID. ARP se analiza mediante Packet Capture, no con el registro normal de una regla de firewall.

Utilizar Packet Capture en Sophos Firewall explica la vista con más detalle. Para comprobar la interfaz, la zona y la asignación del alias, consulte Configurar zonas e interfaces en Sophos Firewall.

Las observaciones indican con claridad el siguiente paso:

No hay paquetes IPv4 en la WAN: Compruebe el ARP upstream, el enrutamiento del proveedor, el CPE o el switch situado delante del firewall.
Estado Incoming o Violation: El paquete llega al firewall. Con Violation, Reason, la regla de firewall, la DNAT, la zona y el servicio ofrecen las siguientes pistas.
Estado Forwarded, pero no hay respuesta: Compruebe la ruta de retorno, el servidor interno, la SNAT y el firewall del servidor.
Solo está afectada una IP alias: Compare la configuración del alias y la entrada upstream específicamente para esa IP.

Actualizar la asignación ARP en el dispositivo upstream

La corrección más limpia se realiza en el dispositivo que conserva la entrada incorrecta. Si gestiona el router upstream o el CPE del proveedor, elimine de forma selectiva la entrada ARP de la IP afectada. A continuación, el upstream deberá aprender la nueva dirección MAC WAN.

Si no es posible vaciar una entrada concreta, Sophos indica como alternativa reiniciar el router responsable. Debe hacerse en una ventana de mantenimiento porque interrumpe otras conexiones y no puede deshacerse. Eliminar una entrada dinámica no requiere revertir la configuración: el router vuelve a aprenderla. Si revierte la migración, elimine de nuevo la entrada tras reconectar el dispositivo anterior para que pueda aprenderse la MAC antigua. Para un dispositivo gestionado por el proveedor, facilítele la IP afectada, las direcciones MAC anterior y nueva, y el CPE responsable.

Esta corrección no requiere ningún comando adicional de Device Console. La ayuda actual de SFOS 22 indica expresamente que, para entradas ARP de alias obsoletas, se debe vaciar la caché del router o reiniciar el router. Si el proveedor enruta las direcciones en lugar de resolverlas localmente mediante ARP, ambas acciones sobre la entrada alias son ineficaces; compruebe en su lugar la ruta del proveedor y la configuración local de alias o NAT.

Validar la accesibilidad después de la corrección

Repita la misma prueba después de aplicar una única medida. Así podrá determinar qué acción solucionó el problema.

Compruebe en el upstream si la IP afectada apunta ahora a la nueva dirección MAC WAN.
Repita el ping externo o la prueba del puerto TCP con el mismo origen y destino.
Compruebe en Packet Capture si los paquetes llegan ahora a la interfaz WAN.
Si llegan paquetes, compruebe Firewall Rule ID y NAT Rule ID en Log Viewer.
Pruebe el servicio publicado hasta el servidor interno y también la ruta de retorno.

Una entrada ARP actualizada solo demuestra que el upstream puede enviar los paquetes al nuevo firewall. El funcionamiento del servicio sigue dependiendo de la DNAT, la regla de firewall, el destino interno y la ruta de retorno. Publicar un servidor mediante DNAT muestra el recorrido completo de las reglas.

Si la incidencia persiste

Si la IP sigue sin ser accesible pese a haber actualizado la entrada ARP, no pruebe más comandos de shell, sino cambie de hipótesis.

Entre las causas alternativas habituales se incluyen:

La IP alias está asignada a la interfaz física incorrecta o utiliza una máscara de red errónea.
El proveedor enruta el bloque público de una forma distinta a la prevista.
Una entrada ARP o MAC estática en el upstream impide el aprendizaje dinámico.
Un switch situado delante del firewall conserva una asociación MAC antigua o utiliza Port Security.
La regla DNAT apunta a otra IP pública.
La regla de firewall no permite el origen, el servicio o la zona.
El servidor interno responde a través de otro gateway.
En un entorno HA, el dispositivo primario responde a las solicitudes ARP con la dirección MAC virtual de la interfaz. Solo los dispositivos virtuales con Use host or hypervisor-assigned MAC address activado utilizan en su lugar la dirección MAC asignada por el host o el hipervisor.

La pérdida recurrente de ARP tampoco debe resolverse ejecutando periódicamente un comando creado para este fin. En ese caso, el proveedor, el CPE, el diseño de capa 2 y, si procede, Sophos Support deben investigar la causa.

Implicar de forma selectiva al proveedor o al equipo upstream

Si la captura WAN no muestra paquetes para la IP afectada, el proveedor necesita un diagnóstico preciso en lugar de una indicación general de que el firewall no es accesible.

Tenga preparados los siguientes datos:

IP principal o alias afectada,
interfaz WAN y nueva dirección MAC,
gateway upstream o CPE,
hora de la prueba externa y del vaciado de la caché o el reinicio,
resultado de Packet Capture,
tipo de entrega esperado: red conectada directamente o bloque enrutado,
resultado para la IP principal y las demás IP alias.

Con estos datos, el proveedor puede comprobar la entrada ARP concreta, una asociación estática o la ruta hacia el bloque público. Los datos de configuración confidenciales o las capturas de paquetes completas solo deben enviarse a través de un canal de soporte acordado.

Comprobación final

Se han documentado la IP principal, las IP alias y el tipo de entrega.
Se han comprobado la interfaz física, la versión de IP y la máscara de red.
Se han realizado una prueba TCP externa y un Packet Capture con destinos idénticos.
El tráfico ARP y el tráfico IP se han analizado por separado durante el diagnóstico.
Se ha eliminado de forma selectiva la entrada upstream o se ha reiniciado el router en una ventana de mantenimiento coordinada.
Se ha confirmado la nueva asociación MAC en el upstream.
Se han comprobado posteriormente la DNAT, Firewall Rule ID, NAT Rule ID y la ruta de retorno.
Se han documentado la causa y la medida aplicada en el registro de cambios o de migración.

FAQ

¿Hay que vaciar la caché ARP después de cada migración de firewall?

No. Normalmente, el upstream aprende automáticamente la nueva dirección MAC. Solo es necesario intervenir cuando una entrada concreta permanece obsoleta y Packet Capture muestra que la IP afectada no llega al nuevo firewall.

¿Por qué funciona la IP principal, pero no una IP alias?

El upstream guarda la asociación por dirección IPv4. La entrada de la IP principal ya puede apuntar a la nueva dirección MAC WAN, mientras que una IP alias sigue asociada a la dirección MAC anterior.

¿Es un problema de ARP, NAT o de una regla de firewall?

Si durante la prueba externa no llega ningún paquete a la interfaz WAN, la causa se encuentra antes de la evaluación local de la DNAT y las reglas de firewall. Si el paquete llega, compruebe NAT Rule ID, Firewall Rule ID, el destino interno y la ruta de retorno.

¿Se puede reiniciar simplemente el CPE del proveedor?

Un reinicio puede renovar la caché ARP, pero también interrumpe otras conexiones. Es preferible eliminar de forma selectiva la entrada afectada; si no es posible, el reinicio debe realizarse durante una ventana de mantenimiento coordinada.