Configurar y comprobar Proxy ARP en Sophos Firewall

Proxy ARP solo se necesita en Sophos Firewall cuando un dispositivo del segmento IPv4 conectado directamente consulta por una dirección de destino adicional y el firewall debe responder en su nombre con su dirección MAC. Esto puede ocurrir, por ejemplo, con una IP pública adicional que después se reenvía mediante DNAT a un servidor interno.

El punto decisivo es que Proxy ARP solo resuelve la vecindad antes del flujo IP real. No crea ninguna regla de firewall, regla NAT ni ruta de retorno. Por eso, primero se confirma mediante una captura ARP que falta exactamente esa respuesta. Solo entonces se añade una única entrada Proxy ARP y se comprueba junto con el servicio real.

⚠️ No activar Proxy ARP de forma preventiva para todo un rango de direcciones públicas. Antes del cambio hay que documentar la asignación del proveedor, la interfaz, el estado ARP original, el backup, un acceso de gestión independiente y el rollback. Una dirección de destino incorrecta o duplicada puede atraer tráfico al firewall equivocado.

Proxy ARP en ocho pasos

Aclarar con el proveedor o el equipo upstream si la dirección IPv4 adicional se consulta mediante ARP en el segmento WAN o se enruta hacia el firewall como prefijo.
Descartar que la dirección ya se utilice como alias, en otro dispositivo o mediante un diseño existente.
Crear una captura ARP en la interfaz de entrada esperada mientras se inicia una conexión nueva.
Continuar solo si llega la solicitud ARP para la dirección de destino y se demuestra que falta la respuesta necesaria del firewall.
En Device Console, añadir una entrada con set proxy-arp add para exactamente una dirección IPv4.
Configurar o comprobar por separado la regla de firewall, DNAT o la ruta, así como la ruta de retorno.
Probar la respuesta ARP, Firewall Rule ID, NAT Rule ID y el servicio real con una conexión nueva.
Repetir la misma prueba después de un failover HA o durante el rollback y eliminar la entrada de forma específica con set proxy-arp del.

Distinguir Proxy ARP, alias y routing

Qué hace realmente Proxy ARP

Antes de que un dispositivo IPv4 pueda enviar un paquete a un vecino del mismo segmento de capa 2, necesita su dirección MAC. Para ello envía una solicitud ARP. Con Proxy ARP, Sophos Firewall responde a dicha solicitud para otra IP de destino con la dirección MAC de la interfaz seleccionada.

El equipo upstream envía así las tramas Ethernet siguientes al firewall. Solo después deciden el routing, NAT y las reglas de firewall qué sucede con el paquete IP. Por tanto, una respuesta ARP correcta todavía no demuestra que el servicio publicado funcione.

El comando de Device Console documentado por Sophos se aplica a ARP y, por tanto, a IPv4. IPv6 utiliza Neighbor Discovery para resolver vecinos. De este comando no puede deducirse un procedimiento de Proxy NDP.

Qué variante encaja con la asignación del proveedor

IP alias: La dirección adicional se vincula localmente a una interfaz física del firewall. Esto encaja cuando el firewall debe poseer la dirección o utilizarla específicamente para NAT o tráfico del sistema. Configurar una IP alias en Sophos Firewall muestra el proceso completo.
Proxy ARP: El firewall responde en nombre de una dirección IPv4 reenviada o traducida. Este comando no añade la dirección como dirección normal de interfaz.
Prefijo enrutado: El equipo upstream enruta una red completa hacia la dirección WAN o hacia un next hop acordado. En ese caso, normalmente no consulta mediante ARP cada dirección de destino del prefijo en el segmento WAN. Una entrada Proxy ARP manual sería la reparación equivocada.
Vecino estático: Asigna una dirección MAC fija a un vecino alcanzable directamente. Es la perspectiva opuesta y no sustituye a Proxy ARP. La diferencia se explica en Comprobar la caché de vecinos ARP y NDP.

Una regla DNAT tampoco implica automáticamente que sea necesario un Proxy ARP manual. Primero se prueba el flujo existente. La entrada CLI solo está justificada cuando el diseño del proveedor y la captura demuestran realmente que falta la respuesta ARP.

Ejemplo y valores sustituibles

El ejemplo utiliza una asignación IPv4 pública conectada directamente. Un servicio HTTPS debe estar disponible mediante la dirección adicional 203.0.113.10:

Interfaz WAN: Port2
Dirección WAN del firewall: 203.0.113.9/29
Gateway del proveedor: 203.0.113.14
IP pública de destino adicional: 203.0.113.10
Host de prueba externo: 198.51.100.25
Servidor interno: 10.20.40.20
Servicio: HTTPS

203.0.113.0/24 y 198.51.100.0/24 son redes de documentación. No funcionan como direcciones productivas y deben sustituirse por completo por la asignación real del proveedor y un host de prueba externo autorizado. Port2 también es solo un ejemplo; se utiliza exactamente la interfaz en la que llega de forma demostrable la solicitud ARP.

La máscara /29 no se utiliza en el comando Proxy ARP. Solo explica la red del ejemplo. La entrada se aplica deliberadamente solo a 203.0.113.10. Solo se responde por un rango completo cuando la propiedad, el uso y la sintaxis están claramente documentados para cada dirección y se han probado en el build utilizado.

Comprobar la ruta del proveedor y ARP antes del cambio

Antes de usar la CLI se distinguen tres resultados posibles:

No llega ninguna solicitud ARP al firewall: La ruta del proveedor, la VLAN, el puerto de switch o la suposición sobre la asignación deben aclararse antes del paso de Proxy ARP.
La solicitud llega y ya responde un dispositivo: No se debe generar una segunda respuesta. Primero hay que identificar al propietario de la dirección MAC visible.
La solicitud llega, pero nadie responde: Solo este resultado encaja con la ausencia de una respuesta Proxy ARP en el firewall.

Para capturar, iniciar sesión mediante SSH o la consola local y abrir Option 4: Device Console. Conectar con Sophos Firewall mediante SSH explica el acceso y la diferencia entre Device Console y Advanced Shell.

El siguiente filtro BPF es de solo lectura y muestra únicamente el tráfico ARP para la dirección de ejemplo:

tcpdump 'arp and host 203.0.113.10'

A continuación, iniciar una conexión nueva a 203.0.113.10 desde la ruta de prueba externa autorizada. Si el equipo upstream todavía conserva una entrada en caché, actualizar solo esa entrada mediante el procedimiento documentado del router o proveedor, o dejar que caduque. Vaciar todas las cachés ARP o reiniciar un router es desproporcionado para el diagnóstico inicial.

La interfaz, la IP de destino y la hora de la captura deben coincidir con la prueba. Una solicitud ARP en otra VLAN o interfaz no se resuelve mediante una entrada en Port2.

Añadir una única entrada Proxy ARP

Si la comprobación previa es concluyente, se añade exactamente la dirección confirmada en Device Console:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

Las partes fijas son set proxy-arp add interface y dest_ip. Port2 y 203.0.113.10 se sustituyen por la interfaz real y la dirección IPv4 confirmada individualmente.

Sophos también documenta dst_iprange, pero la página de ayuda actual no publica un ejemplo de rango completo y probado. Por eso aquí no se adivina ningún formato. Para rangos públicos, una sola dirección también es el piloto más seguro: limita el impacto y permite pruebas positivas y negativas inequívocas.

Inmediatamente después del comando se genera otra solicitud ARP nueva y se repite la captura. Se espera una respuesta con la dirección MAC de la interfaz prevista del firewall. Si responde otra MAC o aparecen varias respuestas, se detiene el rollout y se resuelve primero el conflicto de direcciones.

Implementar por separado la regla, NAT y la ruta de retorno

Proxy ARP atrae la trama Ethernet hacia el firewall. El flujo IP posterior sigue necesitando su propia configuración técnicamente adecuada.

Para el servidor HTTPS interno del ejemplo, esto incluye:

una regla DNAT restringida de 203.0.113.10:443 a 10.20.40.20:443;
una regla de firewall correspondiente desde la fuente WAN autorizada hacia la zona del servidor;
logging durante la validación;
una ruta de retorno del servidor a través de Sophos Firewall;
loopback, si se necesita, solo como caso interno planificado por separado.

Publicar un servidor mediante DNAT explica la posición de las reglas, Original Destination, la zona de destino, loopback y las funciones de protección. NAT en Sophos Firewall explica SNAT, DNAT, MASQ y PAT.

Si la dirección pública adicional debe enrutarse a un sistema posterior sin DNAT, el firewall necesita en su lugar una ruta inequívoca y reglas adecuadas. Una red solapada no debe ocultarse con una ruta estática adivinada ni con un rango Proxy ARP. El prefijo del proveedor, el direccionamiento interno y la ruta de retorno deben definirse primero como un diseño de routing coherente.

Validar ARP y el servicio real

La validación consta de una comprobación de capa 2 y otra de IP/aplicación:

Generar una solicitud ARP nueva para 203.0.113.10.
Confirmar en la captura la solicitud en Port2 y exactamente una respuesta con la MAC esperada del firewall.
Abrir una conexión HTTPS nueva desde el host de prueba 198.51.100.25.
Comprobar en Log viewer la Firewall Rule ID y NAT Rule ID esperadas.
Comparar en el Packet Capture integrado la entrada en Port2 y la salida hacia el servidor.
Confirmar en el servidor que llega la conexión y que la respuesta vuelve a través del firewall.
Probar negativamente un puerto no permitido y una fuente no autorizada.
Si se utiliza HA, comprobar una conexión nueva y un nuevo intercambio ARP después de un failover controlado.

El éxito solo queda demostrado cuando son correctos tanto la respuesta ARP como el servicio real. Un ping no basta: ICMP puede tratarse de forma intencionadamente distinta a HTTPS en Device Access o en la regla de firewall. Packet Capture en Sophos Firewall explica filtros, Status, Reason, Rule ID y comparación de interfaces; comprobar sistemáticamente reglas de firewall muestra la validación completa.

Diagnóstico sistemático

No llega ninguna solicitud ARP

Comprobar la asignación del proveedor, el routing upstream, la VLAN, el puerto de switch y la interfaz de entrada real. Una entrada Proxy ARP local no puede responder a una solicitud que nunca llega a la interfaz. Con un prefijo enrutado, la ausencia de una solicitud ARP para cada IP de destino es incluso esperable; en ese caso se comprueban la ruta y el next hop en vez de Proxy ARP.

La solicitud ARP llega, pero no sale ninguna respuesta

Comparar la IP de destino y la interfaz del comando con la captura. Después, descartar que haya cambiado la interfaz, que la dirección esté mal escrita o que la prueba se haya ejecutado desde otro segmento de capa 2. No ampliar el rango de IP para hacer que una prueba individual poco clara parezca funcionar.

Si la entrada documentada en la interfaz confirmada sigue sin responder, recopilar la versión del firmware, una captura breve y la topología exacta para Sophos Support. Las modificaciones no documentadas de ARP o parámetros del kernel en Advanced Shell no son un paso estándar seguro.

Responden varias direcciones MAC

Se detiene la prueba. Las causas habituales son una IP duplicada, un equipo antiguo todavía activo, un alias en un segundo firewall u otra entrada Proxy ARP. Primero hay que identificar al propietario de cada MAC y resolver el conflicto de direcciones. Una regla de firewall no puede corregir respuestas ARP concurrentes.

ARP es correcto, pero el servicio sigue sin estar disponible

Proxy ARP ya ha cumplido su función. A continuación se comprueban Firewall Rule ID, NAT Rule ID, orden de reglas, zona de destino, servicio, gateway del servidor y ruta de retorno. Debe utilizarse una conexión nueva para no reutilizar una sesión antigua.

La dirección queda inaccesible brevemente tras una sustitución o failover HA

Volver a comprobar ARP y el servicio real en el nodo activo en el momento del evento. El equipo upstream puede conservar todavía una asignación MAC antigua. Primero se actualiza de forma controlada solo la entrada afectada; resolver problemas ARP tras una migración del firewall muestra el proceso completo para cachés antiguas del proveedor o router.

No se promete la continuación sin interrupciones de las conexiones existentes. Lo decisivo es una solicitud ARP nueva, una sesión de aplicación nueva y los logs del nodo que realmente procesó el tráfico.

Rollback y operación

Antes de eliminar la entrada se documentan la dirección publicada y el servicio que dependen de ella. Durante una ventana de mantenimiento se elimina exactamente el mismo valor con del:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

A continuación se genera una solicitud ARP nueva. El firewall ya no debe responder por esta entrada manual, siempre que ningún alias, peer HA u otro mecanismo legítimo atienda la misma dirección. Las reglas de prueba dependientes y la configuración NAT temporal se devuelven al estado anterior documentado.

La entrada debe figurar en la documentación operativa porque no aparece como una dirección de interfaz normal que explique por qué el firewall responde por la IP adicional. Tras una modificación de interfaces, un equipo de sustitución, un restore, un cambio de firmware o una prueba HA, se vuelven a comprobar la dirección de destino, la interfaz, la respuesta ARP y el servicio real.

Lista de comprobación

Asignación del proveedor y modelo ARP en lugar de routing confirmados.
La IP de destino pertenece de forma demostrable a la propia organización y no está duplicada.
La solicitud ARP llega a la interfaz documentada.
La respuesta ausente se ha demostrado mediante captura antes del cambio.
Solo se ha introducido una dirección piloto con dest_ip.
Regla de firewall, NAT o ruta y ruta de retorno comprobadas por separado.
Dirección MAC, Firewall Rule ID y NAT Rule ID esperadas confirmadas.
Fuente no permitida y puerto no permitido probados negativamente.
Failover HA o ruta de sustitución probados con una conexión nueva.
Comando del exacto y estado original documentados.

FAQ

¿Necesita cada regla DNAT una entrada Proxy ARP manual?

No. DNAT y Proxy ARP son funciones distintas. Proxy ARP manual solo se añade cuando el equipo upstream utiliza ARP para la dirección IPv4 adicional en el segmento conectado directamente y falta de forma demostrable la respuesta necesaria del firewall.

¿Cuál es la diferencia entre una IP alias y Proxy ARP?

Una IP alias vincula la dirección a una interfaz física del firewall. Proxy ARP solo hace que el firewall responda en nombre de la dirección a una solicitud ARP IPv4. El diseño del proveedor, el routing, NAT y el tráfico del sistema determinan qué opción encaja.

¿Funciona el comando también para IPv6?

No. El comando documentado se refiere a ARP y, por tanto, a IPv4. IPv6 utiliza Neighbor Discovery. Proxy ARP no debe trasladarse a IPv6 sin un procedimiento SFOS documentado y probado por separado.