Configurar y probar una IP alias en Sophos Firewall
Una IP alias vincula una dirección IPv4 o IPv6 adicional a una interfaz física existente de Sophos Firewall. Resulta práctica cuando un proveedor entrega varias direcciones públicas a través de la misma conexión WAN o cuando una interfaz interna debe atender una segunda subred durante una migración.
La diferencia importante es que un alias no es una segunda conexión a Internet, una zona propia ni una ruta de gateway independiente. La dirección utiliza la misma interfaz física principal. Por tanto, el routing, las reglas de firewall, NAT y Device Access deben seguir ajustándose al diseño existente de la interfaz.
⚠️ Antes de añadir una IP alias pública, documentar un backup actual, una conexión administrativa independiente, la asignación del proveedor, el estado ARP original y las reglas de firewall y NAT previstas. Una dirección adicional no publica por sí sola un servidor, pero puede hacer accesibles servicios locales del firewall según las reglas de Device Access de la zona principal.
El ejemplo utiliza IPv4 en una interfaz WAN. SFOS también admite alias IPv6 si la versión IP coincide con la interfaz principal. Sin embargo, Neighbor Discovery de IPv6 y NAT66 no forman parte de este ejemplo concreto.
IP alias en ocho pasos
- Confirmar que el proveedor o la red interna realmente entrega la dirección adicional a través de la misma interfaz física.
- Documentar la interfaz principal, la versión IP, la dirección, la máscara de subred y la finalidad.
- Comprobar Device Access, las reglas existentes y una vía de administración independiente.
- Vincular la dirección a la interfaz principal en Network > Interfaces > Add interface > Add alias.
- Si es necesario para las reglas y NAT, crear un IP Host con un nombre claro y exactamente esta dirección.
- Configurar DNAT o SNAT solo para el flujo previsto; tratar el tráfico del sistema por separado.
- Comprobar la ruta del proveedor, ARP, Firewall Rule ID, NAT Rule ID y ambos sentidos mediante una conexión nueva.
- Probar el equipo de sustitución, el failover de HA y el rollback en una ventana de mantenimiento con el mismo flujo.
Cuándo es adecuada una IP alias
Una IP alias es adecuada cuando varias direcciones deben utilizar la misma ruta física de capa 2 y el mismo gateway. Casos habituales:
- varias direcciones IPv4 públicas en una conexión WAN estática;
- una dirección pública propia para DNAT, WAF o un servicio de correo;
- una dirección de origen fija para tráfico reenviado seleccionado;
- una segunda subred interna en el mismo segmento físico durante una migración controlada;
- varias direcciones del proveedor en la misma subred, para las que interfaces WAN separadas provocarían problemas de ARP.
Varias interfaces WAN en la misma subred no son una alternativa limpia. Sophos advierte que los gateways pueden quedar inaccesibles por problemas de ARP y menciona un alias o LAG como tipos de interfaz apropiados. Zonas e interfaces en Sophos Firewall explica la elección básica entre puertos físicos, VLAN, LAG, bridge y XFRM.
Un alias no es adecuado si se necesita una segunda línea, un gateway propio, un estado de enlace independiente, otra zona de seguridad o un failover real. En esos casos se requiere un diseño propio de interfaz, VLAN, LAG, WAN o routing.
Si el firewall no debe poseer localmente una dirección IPv4 adicional, sino únicamente responder en su nombre a la solicitud ARP en un segmento conectado directamente, se trata de otro diseño. Configurar Proxy ARP en Sophos Firewall explica la decisión y el procedimiento limitado de CLI y pruebas.
Ejemplo y valores sustituibles
El ejemplo publica un servicio HTTPS interno mediante una segunda dirección pública:
- Interfaz principal:
Port2 - Zona principal:
WAN - Dirección principal:
203.0.113.9/29 - Gateway del proveedor:
203.0.113.14 - IP alias:
203.0.113.10/29 - Objeto host del alias:
WAN_ALIAS_APP_203.0.113.10 - Servidor interno:
APP-DMZ_10.20.40.20 - IP del servidor:
10.20.40.20 - Servicio:
HTTPS - Host de prueba externo:
198.51.100.25
203.0.113.0/24 y 198.51.100.0/24 están reservadas para documentación. En la configuración productiva se sustituyen por las direcciones asignadas por el proveedor y por un host de prueba externo autorizado.
La máscara /29 es solo un ejemplo realista. No debe copiarse si el proveedor entrega un bloque enrutado, una única dirección /32 u otro tamaño de red. Son determinantes la documentación del proveedor, el modelo de ARP o routing y la versión IP utilizada en la interfaz principal.
Añadir el alias a la interfaz física
En Network > Interfaces, la dirección se vincula directamente a la interfaz existente:
- Seleccionar Add interface > Add alias.
- En Physical interface, seleccionar
Port2o la interfaz principal real. - Establecer IP version en
IPv4. - En IPv4/Netmask, introducir
203.0.113.10y la máscara confirmada por el proveedor. - Guardar con Save.
La dirección adicional aparece después en la interfaz principal. Si existen más de tres alias, SFOS muestra inicialmente solo los tres primeros. Es posible desplazarse dentro del área visible de direcciones para ver las demás entradas.
Un alias no puede activarse o desactivarse de forma independiente. Si se desactiva la interfaz física principal o pierde el enlace, sus direcciones alias dejan también de ser accesibles. A la inversa, guardar un alias no crea una nueva entrada de gateway ni una ruta propia.
El formulario Add alias no incluye un campo de zona propio. Por eso, la zona de la interfaz principal sigue siendo relevante para los servicios locales del firewall. Antes de añadir una IP alias pública, comprobar en Administration > Device access qué servicios son accesibles desde WAN y utilizar una Local Service ACL Exception restrictiva para fuentes de administración fijas. SSO o MFA no justifican un acceso amplio a WebAdmin.
Utilizar el alias en reglas y NAT
El alias vinculado y un IP Host cumplen funciones distintas:
- El alias hace que la dirección esté presente localmente en la interfaz física.
- El IP Host permite seleccionar la misma dirección de forma comprensible en los campos de reglas y NAT.
Un objeto host por sí solo no vincula una dirección a la interfaz. Del mismo modo, un alias por sí solo no publica un servidor ni permite tráfico reenviado. Utilizar correctamente IP Hosts y servicios explica en detalle los límites de estos objetos.
Publicar un servicio entrante mediante DNAT
Para el ejemplo, se crea en Hosts and services > IP host el objeto WAN_ALIAS_APP_203.0.113.10 de tipo IP con la dirección 203.0.113.10. Después se crean una regla DNAT restrictiva y una regla de firewall adecuada:
- Original source: redes externas autorizadas o
Anyde forma consciente - Original destination:
WAN_ALIAS_APP_203.0.113.10 - Original service:
HTTPS - Translated destination (DNAT):
APP-DMZ_10.20.40.20 - Translated service (PAT):
Original - Inbound interface:
Port2o la entrada realmente confirmada - Translated source (SNAT): normalmente
Original - Log firewall traffic: activado
La regla de firewall permite el mismo servicio externo desde WAN hacia la zona del servidor interno y utiliza como Destination network la dirección alias pública de Original destination. La fuente, el servicio y las funciones de protección se limitan todo lo posible. La configuración completa con posición de la regla, loopback y refuerzo se encuentra en Publicar un servidor mediante DNAT.
Enviar tráfico reenviado mediante la IP alias
Si solo un servidor interno concreto debe aparecer externamente como 203.0.113.10, se crea una regla SNAT propia exactamente para este flujo. Translated source (SNAT) utiliza entonces el IP Host de la dirección alias. La fuente, el destino, el servicio y las interfaces se mantienen tan restringidos como permita el caso de uso.
La regla NAT no sustituye una regla de firewall. Además, las reglas NAT solo se evalúan para el primer paquete de una conexión nueva. Tras un cambio debe abrirse una conexión nueva; una sesión ya existente no demuestra la nueva ruta NAT. NAT en Sophos Firewall explica el procesamiento de SNAT, DNAT y PAT.
Tratar por separado el tráfico del sistema del firewall
El tráfico DNS, de autenticación, correo u otro tráfico generado por el propio firewall no sigue automáticamente una regla SNAT para clientes reenviados. Sophos documenta expresamente que las configuraciones de routing utilizan la interfaz principal. Si un flujo concreto y justificado de tráfico del sistema debe usar la IP alias como origen, se necesita una configuración CLI separada.
Antes del cambio, guardar el estado inicial en la Device Console:
show advanced-firewall
El ejemplo siguiente traduce únicamente el tráfico del sistema a través de Port2 hacia el destino individual 198.51.100.25, utilizando la IP alias 203.0.113.10:
set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10
⚠️ Este comando cambia la dirección de origen del tráfico del firewall. No crea una ruta ni es un sustituto general de una regla NAT. El destino, la máscara
/32, la interfaz y la IP alias deben ajustarse a la aplicación real. Después del cambio, probar exactamente el servicio afectado y volver a comprobar la entrada conshow advanced-firewall.
Para el rollback, se elimina exactamente la misma entrada con delete:
set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10
Las máscaras más amplias traducen el tráfico hacia toda una red de destino. Solo deben utilizarse cuando este ámbito mayor sea intencionado, esté documentado y se haya probado.
Planificar alias de subredes diferentes
Sophos permite varias direcciones alias de subredes diferentes en la misma interfaz física, pero establece dos condiciones:
- Sophos Firewall debe ser el gateway predeterminado de los hosts internos.
- Los dispositivos upstream que actúan como gateway para el tráfico del firewall deben tener una dirección adecuada en cada subred alias utilizada.
Por tanto, un alias no hace funcionar automáticamente una segunda subred de extremo a extremo. El gateway del host, los equipos remotos, la ruta de retorno, ARP o Neighbor Discovery, las reglas de firewall y NAT también deben ser correctos para esa subred.
Para una segmentación permanente suele ser más comprensible utilizar una VLAN o una interfaz física propia. Un alias de varias subredes es más apropiado para una transición planificada de forma consciente o una arquitectura de proveedor en la que ambas redes comparten realmente la misma ruta de capa 2.
No se pueden configurar DHCP Server ni DHCP Relay en un Interface Alias. Además, un alias no es un Dedicated HA link válido. Estos requisitos deben utilizar una interfaz física o virtual compatible.
Validar la ruta de datos y ARP
La validación debe seguir la tarea real y no limitarse a un ping:
- En Network > Interfaces, comprobar la interfaz principal, la dirección alias, la máscara y el estado del enlace.
- En el dispositivo del proveedor o upstream, comprobar que la IP alias sea accesible mediante la dirección MAC o el vecino esperados.
- Desde
198.51.100.25, abrir una conexión HTTPS nueva hacia la IP alias. - En Log Viewer, comprobar Firewall Rule ID, NAT Rule ID, la fuente, Original destination y el destino traducido esperados.
- En el Packet Capture integrado, comparar la entrada por
Port2y la salida hacia el servidor. - En el servidor interno, confirmar que la conexión llega y que la respuesta vuelve a través de Sophos Firewall.
- Probar negativamente un puerto no permitido de forma intencionada y una fuente no autorizada.
- En HA, repetir un failover controlado con una conexión nueva, sin suponer que una sesión existente continúa sin interrupciones.
Un ping a la IP alias solo es significativo si Ping está permitido de forma consciente para la zona principal en Device Access. Para un servicio HTTPS publicado, la prueba TCP y de aplicación real es una evidencia mejor del éxito. Packet Capture en Sophos Firewall explica los filtros, la comparación de interfaces y la exportación.
Delimitar los errores sistemáticamente
El alias es visible, pero no es accesible desde el exterior
- Confirmar que el proveedor realmente entrega la dirección concreta a través de
Port2. - Comparar la IP, la máscara y la interfaz principal con la asignación del proveedor.
- Comprobar la entrada ARP o de vecino en el dispositivo upstream.
- Investigar Device Access solo para accesos al propio firewall.
- Para servicios reenviados, comprobar Firewall Rule ID, NAT Rule ID y la ruta de retorno del servidor.
Después de sustituir un firewall, el router upstream puede conservar todavía la dirección MAC antigua para la IP alias. Sophos indica en este caso que se vacíe la caché del router o se reinicie el router. En la práctica, actualizar primero solo la entrada ARP o de vecino afectada mediante el procedimiento documentado del dispositivo upstream; un reinicio completo debe realizarse en una ventana de mantenimiento.
El tráfico saliente sigue utilizando la dirección principal
Para tráfico reenviado, comprobar si la regla SNAT esperada coincide con una conexión nueva. Source, Destination, Service, Inbound interface, Outbound interface y NAT Rule ID deben coincidir.
Para el tráfico del sistema del firewall, una regla SNAT normal no es la evidencia correcta. En ese caso, comprobar la entrada sys-traffic-nat concreta, la ruta, el destino y el flujo de paquetes real. No añadir una traducción amplia por sospecha.
Solo la segunda subred interna no funciona
Comprobar si Sophos Firewall es realmente el gateway predeterminado de los hosts afectados y si el dispositivo upstream tiene una dirección adecuada en esta subred. Después, comprobar por separado la ruta de retorno, la máscara del host, ARP, la regla de firewall y NAT. Un alias visible no demuestra estas dependencias.
El túnel IPsec mediante un alias está activo, pero no transporta tráfico
Guardar primero la versión y el build de SFOS, el modelo del appliance, el uso de PPPoE, la vinculación del alias, IPsec Acceleration y la ruta real de los paquetes. SFOS 22 presenta casos especiales de alias y aceleración vinculados a versiones concretas que no deben aplicarse a cualquier incidencia de alias. El procedimiento delimitado está en Solución de problemas de IPsec para interfaces alias.
Operación, equipo de sustitución y rollback
Las direcciones alias deben documentarse junto con la asignación del proveedor, DNS, certificados, NAT, reglas de firewall y el servicio responsable. Antes de sustituir un firewall, los alias públicos y el cambio esperado de ARP o vecino deben formar parte de la validación.
Para un rollback:
- Documentar los usos activos del alias y del IP Host asociado.
- Retirar de forma controlada los servicios publicados de DNS, monitorización o load balancing.
- Desactivar primero las reglas de firewall y NAT asociadas y confirmar la interrupción del flujo previsto.
- Eliminar cualquier entrada
sys-traffic-natcon el comandodeleteexacto. - Eliminar el alias y el objeto host solo cuando no quede ninguna dependencia productiva.
- Volver a comprobar la interfaz principal, la dirección principal, el gateway y los servicios no afectados.
- En HA, repetir la misma validación después de un failover planificado.
Un alias no puede utilizarse como Dedicated HA link. HA en Sophos Firewall explica las interfaces, las direcciones de administración del peer y las pruebas de failover necesarias para un clúster.
Lista de comprobación
- Se han confirmado la asignación del proveedor, la interfaz principal, la versión IP, la dirección y la máscara.
- Hay un backup y una conexión administrativa independiente disponibles.
- Se han comprobado Device Access y Local Service ACL de la zona principal.
- No se confunden el alias y el IP Host del mismo nombre.
- Las reglas de firewall y NAT están limitadas al flujo previsto.
- El tráfico del sistema solo se traduce por separado cuando existe una necesidad justificada.
- Se han confirmado Firewall Rule ID, NAT Rule ID, ARP y ambos sentidos.
- Se han probado negativamente una fuente no autorizada y un servicio no permitido.
- El equipo de sustitución, el failover de HA y el rollback están documentados.