Comprobar la caché de vecinos ARP y NDP en Sophos Firewall
Si un dispositivo no está accesible aunque tenga la dirección IP correcta, no significa necesariamente que la regla de firewall o la ruta sean incorrectas. En la red local, Sophos Firewall también necesita la dirección MAC correcta del destino. Esta asignación se guarda en la caché de vecinos.
En Network > Neighbors (ARP–NDP) se puede comprobar qué dirección MAC e interfaz están asociadas actualmente a cada dirección IP. Primero se documenta la entrada existente y se compara con la situación real de la red. La caché afectada solo se vacía y se vuelve a aprender si la asignación está obsoleta.
Las etiquetas y los comandos de este procedimiento corresponden a SFOS 22.0. El diagnóstico comienza en WebAdmin; la Device Console solo se utiliza para las comprobaciones adicionales descritas expresamente a continuación.
⚠️ Flush vacía la caché IPv4 o IPv6 seleccionada, no solo una fila. En un firewall de producción conviene registrar primero la entrada actual, limitar el alcance de la prueba y no vaciar la caché durante un pico de carga.
Qué hacen ARP, NDP y la caché de vecinos
ARP asigna una dirección IPv4 a una dirección MAC dentro del segmento local de capa 2. Se trata de un dispositivo accesible directamente, normalmente en la misma VLAN. Para IPv6, el Neighbor Discovery Protocol (NDP) realiza esta función mediante ICMPv6. El firewall necesita esta información antes de poder enviar un paquete al siguiente vecino a través de una interfaz conectada directamente.
Con IPv4, un dispositivo utiliza una solicitud ARP para pedir la dirección MAC correspondiente a una dirección IP. La respuesta proporciona la asignación con la que el firewall actualiza su caché de vecinos. Las asignaciones IP-MAC ya aprendidas se reutilizan para reducir el tráfico de difusión; en IPv6, NDP realiza la resolución de vecinos correspondiente.
Las entradas dinámicas de vecinos se aprenden y se actualizan continuamente. El tiempo de espera predeterminado documentado para las solicitudes ARP y NDP es de 600 segundos (10 minutos). Esto no garantiza que cada entrada desaparezca exactamente al cabo de 600 segundos: las cachés persisten hasta que se realiza un vaciado automático o manual. Después, el firewall puede volver a aprender las asignaciones actuales. Una entrada obsoleta puede aparecer, por ejemplo, tras un cambio de dispositivo, tarjeta de red o VM. En cambio, una dirección IP asignada por duplicado puede hacer que la dirección MAC visible cambie repetidamente.
En Neighbor cache entry timeout se puede cambiar el intervalo de vaciado automático y aplicarlo con Apply. Un valor más corto fuerza un reaprendizaje más frecuente y no corrige direcciones IP duplicadas, VLAN incorrectas ni enlaces estáticos obsoletos. Antes de modificarlo se anota el valor inicial. Si la prueba no aporta ninguna mejora, se restablece exactamente ese valor, se pulsa Apply y se vuelve a probar el flujo de datos real.
Para la automatización XML: La referencia XML para SFOS 22.0 y 23.0 describe el parámetro ARPCacheEntryTimeOut dentro de ARPConfiguration como intervalo de vaciado de la caché: valor predeterminado documentado de 2 minutos, rango de 1–500; el ejemplo indica Minutes. Estos son valores de referencia, no una prueba del valor actual en tiempo de ejecución ni de que se trate del mismo control que el descrito en la ayuda de la interfaz para el tiempo de espera de 600 segundos de las solicitudes ARP/NDP. Esta entidad ARP de IPv4 tampoco demuestra que exista una configuración general de todas las propiedades NDP de IPv6. No se debe adoptar ninguno de estos valores documentados como valor automático de restablecimiento o ajuste: el valor de referencia sigue siendo el valor actual registrado antes de cualquier cambio, que debe restablecerse exactamente al revertirlo; después se vuelve a comprobar el servicio original.
La caché de vecinos solo afecta a los vecinos accesibles directamente dentro del segmento de capa 2 correspondiente. Para un destino remoto, el firewall guarda la dirección MAC del siguiente router, no la del servidor de destino.
No es lo mismo que Proxy ARP: en ese caso, el firewall responde en una interfaz en nombre de otra dirección de destino a su solicitud ARP de IPv4. Este caso especial se trata por separado en Configurar y comprobar Proxy ARP en Sophos Firewall.
Identificar ARP flux en varias interfaces
ARP flux puede producirse cuando varias interfaces Ethernet físicas de Sophos Firewall están conectadas al mismo medio de capa 2 o a la misma broadcast domain. En ese caso, el firewall puede responder a una solicitud ARP a través de ambas interfaces y el dispositivo solicitante observa asignaciones MAC cambiantes o inesperadas. Dos VLAN separadas, un LAG mal configurado o una dirección IP duplicada normal no constituyen automáticamente ARP flux.
Una captura de paquetes breve se utiliza únicamente para verificar el comportamiento ARP: se comprueba si la misma solicitud llega a ambos puertos físicos y si responden las dos interfaces del firewall. La captura no muestra el valor configurado de arp-flux.
Se accede a la Device Console desde la consola local o mediante SSH. Los requisitos y el acceso por SSH se describen en Conectar con Sophos Firewall mediante SSH. Después de iniciar sesión, se selecciona Option 4: Device Console. Antes de cambiar nada, se ejecuta la comprobación previa autoritativa de SFOS 22.0:
show arp-flux
Se registra exactamente el valor devuelto, on u off. El ajuste es global, no específico de una interfaz. Solo se modifica temporalmente si ambas interfaces comparten deliberadamente la misma broadcast domain, la captura confirma el comportamiento problemático y el valor actual requiere un cambio. Si se registró on, durante una ventana de mantenimiento se prueba el modo de respuesta específico de la interfaz con:
set arp-flux off
Con off, el firewall responde a las solicitudes ARP a través de la interfaz Ethernet correspondiente. Después se comprueban por ambos caminos la accesibilidad, las entradas de vecinos, el servicio original y el comportamiento ARP mediante una nueva captura.
Al finalizar la prueba se restaura exactamente el valor registrado con show arp-flux, independientemente del resultado. Si el valor inicial era on, se ejecuta:
set arp-flux on
Si el valor inicial era off, se ejecuta en su lugar:
set arp-flux off
Se vuelve a ejecutar show arp-flux para confirmar el valor restaurado. Después se repiten las pruebas de ruta y la captura de paquetes se usa únicamente para verificar el comportamiento resultante.
Si no se demuestra que existe una broadcast domain compartida o el error no cambia con off, no se deben modificar más ajustes ARP por conjetura. Se vuelve a analizar la VLAN, el bridge, el LAG, la tabla MAC del switch, el cableado y las direcciones IP duplicadas.
Comprobar primero la caché de vecinos
- Abrir Network > Neighbors (ARP–NDP).
- En Show, seleccionar IPv4 neighbor cache o IPv6 neighbor cache.
- Buscar la dirección IP afectada.
- Anotar la dirección IP, la dirección MAC y la interfaz.
- En Static neighbor table, descartar que exista un enlace fijo pero incorrecto para la misma dirección IP.
- Comparar la dirección MAC con el dispositivo final, el hipervisor, el switch o el siguiente router.
La interfaz es tan importante como la dirección MAC. Una asignación IP-MAC correcta en el puerto equivocado suele indicar un problema de VLAN, bridge, LAG o cableado. La dirección MAC esperada se puede consultar, por ejemplo, en la información de red del dispositivo final, en la tabla MAC del switch o en el router conectado directamente. Si la entrada no aparece, se envía desde el firewall un ping dirigido a la dirección IP afectada y después se vuelve a comprobar la vista.
Para IPv4 e IPv6, las dos vistas de caché de WebAdmin son el punto de comprobación documentado. Muestran la interfaz además de la dirección y evitan trasladar por error una observación de IPv4 a un problema de IPv6.
Límites de la API XML: Get Dynamic Neighbour Entries permite leer y comprobar entradas; Flush All Dynamic Entries elimina entradas dinámicas de la caché, no una entrada estática individual. La referencia de SFOS 22.0 y 23.0 indica el parámetro escalar opcional IPFamily con IPv4 e IPv6, pero no un valor predeterminado. No se puede deducir si omitirlo selecciona una de las dos familias, ambas o cualquier otro alcance. Ninguna de las dos versiones incluye un payload de solicitud; por tanto, la tabla de parámetros no proporciona una solicitud de operación ejecutable. Para comprobar y vaciar la caché se utiliza el procedimiento existente de la GUI, seleccionando explícitamente la familia IP. La advertencia sigue siendo válida: Flush vacía toda la caché seleccionada.
Volver a aprender de forma controlada una asignación obsoleta
Vaciar la caché es un paso de diagnóstico, no una solución permanente. Tampoco elimina un enlace estático incorrecto. No existe una reversión directa de las entradas dinámicas eliminadas; el firewall vuelve a aprenderlas con el tráfico nuevo. Si reaparece la misma asignación errónea, la causa sigue estando en la red.
- Documentar la dirección IP, la dirección MAC y la interfaz actuales.
- Reproducir el problema con un solo ping o intento de conexión.
- Si se sospecha de una dirección IP duplicada o de una manipulación, guardar primero el estado actual y una captura breve. Un vaciado inmediato eliminaría este indicio.
- En Show, seleccionar la caché IPv4 o IPv6 afectada.
- Hacer clic en Flush. De este modo se vacía la caché seleccionada.
- Volver a generar tráfico dirigido desde el dispositivo afectado.
- Comprobar qué dirección MAC e interfaz se han vuelto a aprender.
- Probar de nuevo el servicio original con la misma fuente y el mismo destino.
Para realizar una prueba controlada desde la Device Console se pueden enviar, por ejemplo, cuatro paquetes a una dirección de destino documentada:
ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4
Estas direcciones son ejemplos y deben sustituirse por el destino IPv4 o IPv6 real. Un ping correcto solo confirma la accesibilidad básica; después aún se debe probar el servicio que presentaba el problema originalmente.
Durante el nuevo aprendizaje puede producirse un breve retraso. Reducir mucho el tiempo de espera de forma general rara vez es la mejor solución: el firewall tendría que resolver los vecinos con más frecuencia, sin corregir una dirección IP duplicada ni un puerto de switch incorrecto.
Si después de vaciar la caché solo una dirección IP pública sigue sin pasar a la nueva dirección MAC del firewall, la entrada obsoleta probablemente se encuentra en el proveedor o en un router anterior. Para este caso existe el procedimiento específico Resolver problemas de ARP después de migrar un firewall.
Crear un vecino estático solo para asignaciones fijas
Un vecino estático vincula permanentemente una dirección IP con una dirección MAC y una interfaz física. Solo puede existir un vínculo de este tipo por dirección IP. Cuando llega una solicitud al puerto correspondiente, el firewall comprueba primero la tabla de vecinos estáticos y, al guardar, elimina las referencias dinámicas de la misma dirección IP. Si no hay una entrada estática, comprueba las cachés de vecinos y añade la dirección MAC si es necesario. Para un par IP-MAC vinculado de forma estática, el firewall no responde en ningún otro puerto. Si más adelante la dirección IP, la dirección MAC o el puerto dejan de coincidir, la conexión puede fallar aunque el dispositivo final esté configurado correctamente.
Por tanto, las entradas estáticas son apropiadas para sistemas estables, como un dispositivo de infraestructura con dirección IP fija y cableado permanente. En general no son adecuadas para clientes DHCP, dispositivos móviles, cambios de HA o máquinas virtuales ni puertos de switch variables.
En Network > Neighbors (ARP–NDP), abrir Static neighbor table y seleccionar Add. A continuación, configurar los valores siguientes:
- IP version: Seleccionar IPv4 o IPv6.
- IPv4/IPv6 address: Introducir la dirección fija del dispositivo.
- MAC address: Introducir la dirección MAC real del dispositivo.
- Interface: Seleccionar la interfaz física a través de la cual se accede al vecino.
Un ejemplo documentado podría utilizar 192.0.2.10, 02:00:00:00:00:10 y Port1. Estos valores son marcadores de posición y deben sustituirse por completo por la dirección IP, la dirección MAC y el puerto reales.
Antes de guardar, se registra si está seleccionada la opción Add as a trusted MAC address to prevent a spoofing attempt. La opción añade la asignación IP-MAC a la lista de MAC de confianza. Solo se debe activar si esta estrategia de protección se utiliza de forma deliberada, ya que un cambio posterior de VM, NIC o puerto puede aparecer como un conflicto legítimo. Comprobar la protección contra la suplantación y los ajustes de DoS de Sophos Firewall explica cómo interactúan las entradas MAC de confianza con redes dinámicas, DHCP y virtualización.
Con Save se crea el enlace y, a continuación, se prueba específicamente el dispositivo afectado. Al revertir la prueba, se elimina la entrada nueva de la Static neighbor table, se genera tráfico dirigido y se comprueba la asignación aprendida dinámicamente. Después se abre Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Si permanece una entrada MAC de confianza correspondiente creada para esta prueba, se elimina por separado; no se debe suponer que al borrar el vecino estático también se borra esa entrada. También conviene documentar quién actualizará una entrada conservada cuando cambien el hardware, la dirección IP o el puerto. Sin una responsabilidad definida, un enlace estático puede convertirse más adelante en una causa invisible de errores.
Límites de la API Add/Edit
La referencia de Add/Edit para vecinos estáticos en SFOS 22.0 y 23.0 describe un contrato de API propio, distinto de la entidad de tiempo de espera ARPConfiguration explicada anteriormente. Exige neighname para la identidad del vecino guardado o seleccionado; en cambio, neighid es opcional. Ambos deben distinguirse de IPAddress, MACAddress e Interface. Los valores de IP, MAC y puerto físico de la GUI no proporcionan ni esa identidad ni una solicitud JSON o XML ejecutable. La referencia describe la operación como JSON, pero no muestra ningún ejemplo que aclare con certeza el formato o la correspondencia de la identidad; por tanto, no se debe deducir ningún identificador a partir de los valores de la GUI.
Las especificaciones de las direcciones también son contradictorias: el parámetro obligatorio IPFamily permite IPv4 e IPv6, mientras que IPAddress se limita al tipo IPADDRESS, con un máximo de 15 caracteres y clases de direcciones propias de IPv4. De ello no se puede deducir una codificación fiable para IPv6; tampoco refuta la compatibilidad con IPv6 del procedimiento de la GUI descrito anteriormente. Para el parámetro opcional AddAsATrustedMACAddress, la referencia solo indica Enable. Esto no demuestra ni la existencia de un valor Disable ni el efecto de omitir el parámetro. La selección de una MAC de confianza sigue siendo una decisión deliberada, y cualquier entrada MAC de confianza que permanezca se elimina por separado, como se ha descrito anteriormente. Mientras la identidad, el formato de la solicitud y el esquema de direcciones IPv6 no estén claros para la versión concreta de SFOS, se utiliza la GUI existente para crear o editar entradas en lugar de una solicitud de API basada en conjeturas.
Delete Static ARP Entry es una operación independiente: la referencia de SFOS 22.0 y 23.0 exige IPAddress para identificar la entrada, no el contrato Add/Edit con neighname y neighid. La restricción al tipo IPADDRESS, un máximo de 15 caracteres y clases de direcciones propias de IPv4 no establece una representación fiable para eliminar entradas IPv6. Ninguna de las dos versiones incluye un ejemplo de solicitud de eliminación ni una tabla de estados; no se deduce ningún formato de solicitud, payload de eliminación ni contrato de resultados. En lugar de adivinar una solicitud de eliminación de la API, se utiliza la GUI existente para seleccionar y eliminar únicamente la entrada estática guardada que se pretende quitar. Se sigue comprobando y eliminando por separado cualquier entrada MAC de confianza residual correspondiente, como se ha descrito anteriormente; no se garantiza una eliminación en cascada.
Comprobar posibles intentos de envenenamiento de vecinos
Un enlace estático define la combinación esperada de dirección IP, dirección MAC e interfaz. Si la misma IP aparece con otra dirección MAC, o la misma combinación IP-MAC aparece en otro puerto vinculado, el firewall lo considera una posible manipulación y no actualiza la caché con la asignación diferente.
Un enlace por dirección IP no significa que una dirección MAC solo pueda corresponder a una dirección IP. En el ejemplo de ARP para IPv4, tanto IP1 como IP2 están vinculadas a MAC1 y al puerto A. Si cada dirección IP aparece con MAC1 en el puerto A, no se trata de un intento de envenenamiento de vecinos. Lo importante es que cada combinación IP-MAC-puerto coincida con su propio enlace estático.
En el mismo ejemplo, IP3 con MAC1 y sin una entrada ARP estática para IP3 tampoco se clasifica como un intento de envenenamiento de vecinos. Por tanto, compartir la dirección MAC no genera por sí solo un conflicto con los enlaces de IP1 o IP2. Estos ejemplos explican la comprobación de enlaces ARP estáticos; no constituyen una aprobación general de la seguridad del tráfico.
En Network > Neighbors (ARP–NDP) se puede activar Log possible neighbor poisoning attempts y guardar con Apply. Antes de una prueba de duración limitada se anota si la casilla está seleccionada y después se restablece ese estado visible. La opción ayuda en el diagnóstico, pero no debe llevar a interpretar inmediatamente cualquier diferencia como un ataque. Una dirección IP duplicada, una tarjeta de red sustituida, una VM trasladada o un cambio de puerto también pueden generar un conflicto.
Los paquetes ARP IPv4 descartados se pueden mostrar en la Device Console durante una prueba breve:
drop-packet-capture 'arp'
Si hay muchas interfaces, la salida se puede limitar a un puerto físico:
drop-packet-capture interface Port1 'arp'
Port1 es un ejemplo y debe sustituirse por la interfaz afectada. A continuación, reproducir el problema una vez y detener la salida en directo con Ctrl+C. El filtro solo muestra paquetes ARP descartados y no es un archivo de registro permanente. Para NDP de IPv6 o un análisis general de paquetes, se utiliza Captura de paquetes en WebAdmin y se delimitan específicamente la fuente, el destino, el protocolo y la interfaz.
Interpretar los síntomas habituales
- El destino sigue sin estar accesible después de sustituir un dispositivo o una NIC: Comparar la dirección MAC antigua con el valor aprendido de nuevo, vaciar la caché de forma controlada y volver a probar.
- La dirección MAC cambia repetidamente: Comprobar si existe una dirección IP duplicada, una concesión DHCP, una VM clonada o un comportamiento de HA. Una entrada estática solo ocultaría el conflicto real.
- La asignación aparece en la interfaz equivocada: Comprobar la VLAN, el bridge, el LAG, el puerto de switch y el cableado.
- Un dispositivo con enlace estático deja de funcionar tras un cambio: Comparar la dirección IP, la dirección MAC y el puerto físico con el enlace, y actualizar o eliminar la entrada de forma consciente.
- Solo está afectado IPv6: Comprobar la caché de vecinos IPv6, los Router Advertisements, la VLAN y la ruta ICMPv6. Un comando ARP de IPv4 no aporta información para este caso.
- Los paquetes llegan al firewall, pero el servicio sigue sin funcionar: Comprobar por separado la regla de firewall, NAT, el routing y la ruta de retorno. La caché de vecinos solo demuestra la entrega local en capa 2.
Comprobación final
- Se han documentado la dirección IP afectada, la dirección MAC esperada y la interfaz.
- Se ha comprobado la caché IPv4 o IPv6 antes de realizar cambios.
- Si era necesario, solo se ha vaciado la caché seleccionada y se ha generado tráfico dirigido.
- Se ha comparado la asignación aprendida de nuevo con el dispositivo final, el switch, el hipervisor o el router.
- Solo se ha usado un enlace estático cuando la combinación IP-MAC-puerto es permanentemente estable.
- Se ha diferenciado una advertencia de envenenamiento de una IP duplicada, la sustitución de un dispositivo y los cambios de red.
- Se ha vuelto a probar el servicio original después de la comprobación de capa 2.