Solucionar problemas de ARP en Sophos Firewall después de la migración

Después de una migración de firewall, puede ocurrir que el nuevo Sophos Firewall esté generalmente en línea, pero algunas direcciones IP públicas o direcciones IP alias no sean accesibles. Esto es especialmente típico después de un cambio de otro fabricante a Sophos Firewall o después de una migración de hardware XG a XGS. Las direcciones IP permanecen iguales, pero la dirección MAC en la interfaz WAN cambia.

Si un router anterior, un CPE del proveedor o un switch aún tiene entradas ARP antiguas en el caché, seguirá enviando paquetes a la dirección MAC anterior. Esto da la impresión de que solo ciertas direcciones IP alias, destinos DNAT o pruebas de ping no funcionan. Para la planificación general de la migración, también es útil el artículo ¿Cuál es la diferencia entre un firewall XG y XGS?.

Síntomas típicos

Los problemas de ARP después de un cambio suelen manifestarse inmediatamente después del cambio o después de una restauración en nuevo hardware.

Indicaciones típicas:

La interfaz WAN del Sophos Firewall está en línea.
La dirección IP principal funciona, pero algunas direcciones IP alias no.
El ping a ciertas IP públicas falla, mientras que otras IP en la misma interfaz responden.
Las reglas DNAT o WAF parecen estar configuradas correctamente, pero no llegan al servidor interno.
Un servicio es accesible internamente, pero externamente solo está afectado en ciertas IP públicas.
Después de un tiempo, funciona de repente porque un caché ARP expira automáticamente.

Es importante delimitar: no todos los problemas de accesibilidad después de una migración son problemas de ARP. También deben verificarse las reglas de firewall, las reglas NAT, las zonas, la configuración de alias, el enrutamiento del proveedor y las rutas de retorno.

Por qué ARP puede causar problemas después de una migración

ARP resuelve direcciones IPv4 en direcciones MAC. En un segmento local de capa 2, un dispositivo pregunta: ¿qué dirección MAC pertenece a esta dirección IP? La respuesta se almacena en el caché ARP para que no cada paquete desencadene una nueva consulta ARP.

En una migración de firewall, la dirección IP a menudo permanece igual, pero la dirección MAC cambia. Esto puede ser problemático:

El router del proveedor aún conoce la IP pública con la dirección MAC anterior.
Un switch o router anterior mantiene entradas ARP obsoletas.
Se ha configurado correctamente una IP alias en el nuevo firewall, pero el vecino sigue enviando al hardware antiguo.
Solo una parte de las IP ya se ha aprendido nuevamente, por lo que algunas direcciones funcionan y otras no.

Con direcciones IP alias individuales, esto es especialmente confuso porque la conexión básica parece funcionar. Entonces, rápidamente se busca en NAT, reglas de firewall o enrutamiento, aunque el error ya ocurre antes en la capa 2.

Verificar antes del comando CLI

Antes de activar ARP, la configuración básica debe ser correcta. De lo contrario, un ping ARP solo cubrirá otro problema.

Verificar:

En Network > Interfaces, verificar si la dirección IP afectada o la dirección IP alias está en la interfaz correcta.
Verificar la zona de la interfaz, por ejemplo, WAN.
Verificar la puerta de enlace, la máscara de subred y la lógica de red de alias.
En Rules and policies > NAT rules, verificar si la regla DNAT apunta a la IP pública correcta.
En Rules and policies > Firewall rules, verificar si existe una regla adecuada para el tráfico.
En Log Viewer, verificar si los paquetes llegan a la firewall.
Si es necesario, usar Sophos Firewall Packet Capture en WebAdmin para verificar si los paquetes entrantes son visibles en la interfaz WAN.

Si en el Packet Capture no llegan paquetes para la IP pública afectada, el problema probablemente esté antes del firewall: router del proveedor, switch anterior, caché ARP o enrutamiento en el proveedor. Si los paquetes llegan pero son descartados, primero se deben verificar NAT, reglas de firewall y zonas. Para la lógica de interfaces y zonas, ayuda Configurar zonas e interfaces en Sophos Firewall.

Ejecutar un ping ARP a través de la Device Console

Sophos Firewall puede activar un ping ARP con una IP de origen y una interfaz definidas a través de la Device Console. Esto es útil cuando se desea anunciar activamente una IP alias en la red después de la migración.

Importante: El comando solo debe ejecutarse cuando esté claro qué IP de origen, qué interfaz y qué destino en el segmento local se utilizarán. Valores incorrectos no ayudan y pueden distorsionar el análisis. Antes de realizar cambios en una migración productiva, debe haber un Backup de Sophos Firewall actualizado.

El comando se ejecuta en la Device Console, no en el Advanced Shell:

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Ejemplo:

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 un destino accesible en el mismo segmento de capa 2, típicamente la puerta de enlace upstream o el CPE del proveedor. Esto hace que el firewall genere tráfico ARP con la IP de origen correcta a través de la interfaz correcta.

Si SSH aún no está configurado, Conectar Sophos Firewall por SSH describe cómo acceder a la Device Console. En migraciones, SSH no debe permitirse ampliamente desde el WAN de forma permanente. Es mejor un acceso administrativo temporal y restringido desde una red confiable.

Procedimiento recomendado

1. Recopilar direcciones IP afectadas

Primero se documenta qué direcciones IP funcionan y cuáles no. Con direcciones IP alias, se debe comparar directamente la lista con la configuración de la interfaz.

Anotar:

Interfaz, por ejemplo, Port2
Dirección IP principal y direcciones IP alias
Puerta de enlace upstream o CPE del proveedor
Reglas NAT o WAF afectadas
Resultado de ping, prueba de puerto y Packet Capture

2. Delimitar el problema de ARP

Desde un sistema de prueba externo, verificar la IP pública afectada. Paralelamente, iniciar el Packet Capture en el Sophos Firewall en la interfaz WAN.

Interpretación:

No llegan paquetes a la interfaz WAN: Verificar upstream, ARP, enrutamiento del proveedor o dispositivo anterior.
Llegan paquetes pero son descartados: Verificar regla de firewall, NAT, zona o servicio.
Llegan paquetes y se envían internamente, falta respuesta: Verificar ruta de retorno, servidor interno, SNAT o firewall del servidor.
Solo afecta a la IP alias, la IP principal funciona: Verificar específicamente caché ARP o configuración de alias.

3. Ejecutar ping ARP por cada IP alias afectada

Para cada IP alias afectada, se ejecuta el ping ARP con la IP de origen adecuada y la interfaz correcta. Después, no se deben cambiar inmediatamente muchas otras cosas, sino primero probar si el comportamiento cambia.

Ejemplo con marcadores de posición:

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

Si varias direcciones IP alias están afectadas, el comando se ejecuta individualmente por dirección. Esto hace que la verificación sea comprensible y evita que al final no se sepa qué medida ayudó.

4. Validar la accesibilidad

Después del ping ARP, se debe repetir la misma prueba:

Ping o prueba de puerto TCP desde el exterior.
Packet Capture en la interfaz WAN.
Filtrar en Log Viewer la IP de destino afectada.
Verificar regla NAT y de firewall si ahora llegan paquetes.

Si el upstream aprende correctamente la información ARP nueva, los paquetes para la IP alias deberían llegar ahora al nuevo firewall. Si el servicio publicado funciona después de eso, también depende de NAT, reglas de firewall, servidor interno y ruta de retorno.

Si el ping ARP no ayuda

Si el ping ARP no trae mejoras, no se deben probar comandos adicionales arbitrariamente. Entonces es útil una delimitación estructurada.

Otras verificaciones:

El dispositivo upstream puede seguir manteniendo entradas ARP obsoletas.
El proveedor debe recargar el caché ARP o el CPE.
La IP alias está en la interfaz incorrecta o en una red incorrecta.
La IP pública es enrutada por el proveedor en lugar de ser aprendida directamente en el segmento local por ARP.
La regla DNAT apunta a la dirección pública incorrecta.
La regla de firewall no permite el tráfico.
El servidor interno responde a través de otra puerta de enlace.
En HA o cambio de hardware, se esperaba la dirección MAC incorrecta.

Reiniciar el CPE del proveedor o un router anterior puede vaciar cachés ARP, pero no debería ser la primera medida. En entornos productivos, es más limpio primero recopilar pruebas con Packet Capture y Log Viewer.

Incluir específicamente al proveedor o upstream

Si en la interfaz WAN no llegan paquetes para la IP pública afectada, la solicitud al proveedor o responsables del upstream debe ser lo más concreta posible. Un informe general como “el firewall no es accesible” a menudo lleva a bucles innecesarios. Es mejor una breve prueba técnica que muestre qué IP está afectada y qué se ha verificado en el Sophos Firewall.

Información útil:

IP pública o IP alias afectada: El proveedor puede verificar específicamente la entrada ARP o de enrutamiento.
Interfaz WAN y nueva dirección MAC: Muestra qué asignación se espera después de la migración.
Puerta de enlace upstream o dirección CPE: Delimita qué dispositivo vecino debe aprender la dirección.
Momento de la prueba de ping ARP: Facilita la comparación con registros del proveedor o estado del CPE.
Resultado de Packet Capture: Demuestra si los paquetes llegan al Sophos Firewall.
Regla DNAT y de firewall verificada: Evita que el caso se clasifique prematuramente como un problema de reglas locales. La dirección MAC de la interfaz WAN puede documentarse en la interfaz WebAdmin bajo Network > Interfaces. Si el proveedor necesita vaciar un caché ARP o recargar un CPE, debe estar relacionado con la IP concreta o la interfaz afectada. Un reinicio general de todos los dispositivos involucrados solo es útil si la responsabilidad, la ventana de mantenimiento y el impacto están claros.

Lista de verificación

Documentadas las direcciones IP principales y alias afectadas.
Verificada la configuración de interfaz, zona, puerta de enlace y alias.
Verificadas las reglas NAT y de firewall para la IP afectada.
Packet Capture muestra si los paquetes llegan a la interfaz WAN.
Ping ARP ejecutado solo con la IP de origen, interfaz y IP de destino correctas.
Accesibilidad externa probada nuevamente después de cada cambio.
Si es necesario, contactar al proveedor o responsables del upstream con IP concreta, dirección MAC, momento de la prueba y observación de Packet Capture.

FAQ

¿Es necesario actualizar manualmente ARP después de cada migración de firewall?

No. En muchos entornos, los dispositivos vecinos aprenden automáticamente la nueva dirección MAC. Las medidas ARP manuales son especialmente relevantes cuando algunas direcciones IP no son accesibles después del cambio, aunque la configuración del firewall parezca correcta.

¿Es un problema de NAT o un problema de ARP?

Si los paquetes no llegan a la interfaz WAN en el Packet Capture, NAT en el Sophos Firewall aún no es el primer sospechoso. Si los paquetes llegan pero no se reenvían, se deben verificar NAT, reglas de firewall, zonas y rutas de retorno internas.

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

El upstream puede haber aprendido diferentes entradas ARP para cada dirección IP. Por lo tanto, una IP puede ya estar correctamente apuntando a la nueva dirección MAC, mientras que otra aún apunta al firewall antiguo.

¿Deberían reiniciarse simplemente los routers o switches?

Solo si la intervención es operativamente justificable y la responsabilidad está clara. Es mejor primero una verificación específica: Packet Capture en el Sophos Firewall, estado ARP en el dispositivo upstream y, si es posible, vaciado específico del caché ARP en el dispositivo afectado.

¿Se necesita la Advanced Shell para esto?

No. El ping ARP mostrado se ejecuta en la Device Console de Sophos Firewall. No se necesita Advanced Shell y debe evitarse para verificaciones de migración simples.