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 de forma selectiva o se ejecuta un ping ARP desde la Device Console 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.

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.

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.

1. 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.
2. Si las direcciones alias pertenecen a otra subred, compruebe si el upstream de esa subred es accesible como gateway para el firewall. Usar varias interfaces WAN independientes en la misma subred no es una solución adecuada y puede provocar problemas de ARP; según el diseño, deben utilizarse interfaces alias o LAG.
3. 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.
4. Capture el tráfico de la interfaz WAN en Diagnostics > Packet capture. Para comprobar la capa 2, filtre por interfaz y Ethernet type: ARP; para el servicio, filtre después por la IP de destino afectada y el protocolo.
5. 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 en la WAN: Compruebe el ARP upstream, el enrutamiento del proveedor, el CPE o el switch situado delante del firewall.
• Los paquetes llegan y se descartan: Compruebe la regla de firewall, la DNAT, la zona y el servicio.
• Los paquetes se reenvían internamente, 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 de forma selectiva la asignación ARP

Vaciar la caché 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, reiniciar el router responsable también puede renovar la caché. Debe hacerse en una ventana de mantenimiento porque el reinicio interrumpe otras conexiones. Si se trata de un dispositivo del proveedor, facilítele la IP afectada, las direcciones MAC anterior y nueva, y el CPE responsable, en lugar de reiniciar indiscriminadamente toda la ruta.

Ejecutar un ping ARP desde la Device Console

Sophos Firewall ofrece una herramienta de diagnóstico ARP en la Device Console. Un ping ARP con la dirección IP de origen afectada y la interfaz WAN puede iniciar la actualización en el upstream conectado directamente.

Después de iniciar sesión por consola o SSH, abra Option 4: Device Console y ejecute el comando con los valores reales:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Ejemplo con direcciones reservadas para documentación:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

En este ejemplo, 198.51.100.21 es la IP alias afectada en Port2; 198.51.100.1 es el upstream directamente accesible en el mismo segmento de capa 2. La IP de origen, la interfaz y el destino deben corresponder entre sí. Si hay varias IP alias afectadas, pruebe cada dirección por separado para poder identificar el efecto.

El comando no sustituye una configuración de alias incorrecta ni corrige una entrada ARP estática del proveedor. Tampoco es la solución adecuada si el proveedor enruta las direcciones en lugar de resolverlas localmente mediante ARP. Conectar Sophos Firewall mediante SSH explica cómo acceder de forma segura a la Device Console.

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.

1. Compruebe en el upstream si la IP afectada apunta ahora a la nueva dirección MAC WAN.
2. Repita el ping externo o la prueba del puerto TCP con el mismo origen y destino.
3. Compruebe en Packet Capture si los paquetes llegan ahora a la interfaz WAN.
4. Si llegan paquetes, compruebe Firewall Rule ID y NAT Rule ID en Log Viewer.
5. 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, se espera una dirección MAC virtual o física incorrecta.

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 ping ARP,
• 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 ejecutado un ping ARP con los parámetros correctos.
• 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