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

1. Confirmar que el proveedor o la red interna realmente entrega la dirección adicional a través de la misma interfaz física.
2. Documentar la interfaz principal, la versión IP, la dirección, la máscara de subred y la finalidad.
3. Comprobar Device Access, las reglas existentes y una vía de administración independiente.
4. Vincular la dirección a la interfaz principal en Network > Interfaces > Add interface > Add alias.
5. Si es necesario para las reglas y NAT, crear un IP Host con un nombre claro y exactamente esta dirección.
6. Configurar DNAT o SNAT solo para el flujo previsto; tratar el tráfico del sistema por separado.
7. Comprobar la ruta del proveedor, ARP, Firewall Rule ID, NAT Rule ID y ambos sentidos mediante una conexión nueva.
8. 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:

1. Seleccionar Add interface > Add alias.
2. En Physical interface, seleccionar Port2 o la interfaz principal real.
3. Establecer IP version en IPv4.
4. En IPv4/Netmask, introducir 203.0.113.10 y la máscara confirmada por el proveedor.
5. Guardar con Save.

Para un alias IPv6, establecer IP version en IPv6, de modo que coincida con la interfaz principal seleccionada. En IPv6/Prefix, introducir la dirección IPv6 y el prefijo correspondiente asignados al entorno propio en lugar de los valores IPv4 del ejemplo. A continuación, 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. Situar el puntero sobre una de las direcciones IP visibles para que aparezca la barra de desplazamiento. 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. Add alias no configura un gateway independiente ni una ruta predeterminada propia. Esto no excluye rutas directamente conectadas o locales asociadas a la dirección o a su subred. Especialmente si el alias pertenece a otra subred, comparar la tabla de routing antes y después de guardar; la ruta del proveedor y los requisitos para varias subredes indicados más abajo siguen siendo esenciales.

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 Any de 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: Port2 o 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 siguiente ejemplo opcional utiliza Port2, el destino 198.51.100.25 y la IP alias 203.0.113.10. Se conserva como plantilla, pero no debe ejecutarse hasta que se hayan confirmado la sintaxis y el ámbito real de coincidencia para el build instalado:

⚠️ 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. En la sintaxis documentada, destination y snatip son parámetros obligatorios; netmask e interface son opcionales. Sin embargo, las descripciones públicas de SFOS 22/23 no explican qué campo de dirección delimita netmask ni cómo interface limita la coincidencia. Antes de utilizar estos parámetros opcionales, confirmar la sintaxis y la delimitación mediante documentación específica del build o a través de Sophos Support. Sin esta confirmación, no ejecutar el ejemplo; no deducir de la lista de parámetros una limitación garantizada por interfaz o red de destino. Si la entrada prevista ya existe o se solapa con una configuración existente cuyo alcance no está aclarado, detener la prueba sin añadir ni eliminar nada. Después del cambio, probar exactamente el servicio afectado y su flujo real de paquetes, y volver a comprobar la entrada con show advanced-firewall.

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Para el rollback, se elimina exactamente la misma entrada con delete:

⚠️ La eliminación restablece la dirección de origen del tráfico del sistema afectado. Primero, comparar la entrada mostrada por show advanced-firewall con el estado inicial registrado y comprobar las dependencias. Eliminar solo la entrada añadida para esta prueba; después, volver a comprobar el servicio afectado y el estado de la configuración.

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

La máscara /32 255.255.255.255 del ejemplo se ha elegido deliberadamente para el único host de destino previsto, pero no es un requisito de sintaxis ni demuestra ese ámbito sin una semántica de coincidencia confirmada. Incluso con una máscara más amplia, no asumir de forma general que se traduce toda la red de destino. Confirmar primero el campo de dirección realmente afectado y el ámbito resultante para el build instalado; utilizar únicamente un ámbito intencionado y documentado, y comprobar el servicio afectado y los flujos no afectados.

IPsec mediante un alias con varias interfaces WAN

Cuando existen varias interfaces WAN y una conexión IPsec utiliza una dirección alias como dirección local, Sophos requiere la ruta basada en origen para alias. La opción no es un switch general de alias y no se activa solo por DNAT, SNAT o una segunda subred.

Activar para el caso de IPsec descrito: Antes del cambio, documentar el estado anterior de la opción, las interfaces WAN, el alias, la dirección local del túnel, la tabla de routing, las SA activas y el plan de rollback.

Las descripciones oficiales de routing para SFOS 22 y 23 documentan el setter de esta opción, pero no un getter ni un valor predeterminado. Antes de establecerla, deben estar disponibles un método de lectura documentado para el build instalado o confirmado por Sophos Support, el valor inicial real obtenido mediante ese método y una forma confirmada de restablecer exactamente ese valor. Si falta alguno de estos requisitos, no modificar la opción; no adivinar ningún comando de lectura o restablecimiento. La tabla de routing, las SA activas y las pruebas de conexión son comprobaciones operativas adicionales, no una lectura del estado del switch. Si la opción ya estaba activada, dejarla sin cambios y no desactivarla durante el rollback.

⚠️ Esta opción modifica el tratamiento del routing basado en origen para las direcciones alias. Activarla en Device Console solo para la necesidad confirmada y con una vía de administración independiente disponible:

set routing source-base-route-for-alias enable

enable crea el tratamiento de routing basado en origen necesario para direcciones alias, pero no crea un túnel IPsec, una regla de firewall ni una ruta XFRM, estática o SD-WAN. Route-based IPsec sigue necesitando una ruta hacia la interfaz XFRM; policy-based IPsec sigue utilizando las redes locales y remotas configuradas.

Después de activar la opción, volver a obtener su valor real mediante el mismo método de lectura confirmado y compararlo con el estado previsto. Además, probar una conexión nueva en ambos sentidos y comparar la tabla de routing y las SA activas con el estado inicial.

Rollback condicional, no el siguiente paso de configuración: disable solo es el rollback si la opción estaba antes desactivada y ninguna otra conexión IPsec mediante un alias depende de ella. Comprobar primero ambas condiciones con la configuración documentada.

⚠️ Desactivar la opción retira el tratamiento del routing basado en origen y puede afectar a las conexiones IPsec que dependen de él. Ejecutar en Device Console solo después de confirmar el estado anterior y comprobar las dependencias:

set routing source-base-route-for-alias disable

Después del rollback, volver a obtener el valor real de la opción mediante el mismo método de lectura confirmado y confirmar que coincide exactamente con el valor inicial registrado.

Después, volver a comprobar la tabla de routing, las SA activas y una conexión nueva en ambos sentidos. Configurar Site-to-Site IPsec VPN explica tipos de túnel y routing; Crear una IPsec Route cubre la ruta XFRM.

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:

1. En Network > Interfaces, comprobar la interfaz principal, la dirección alias, la máscara y el estado del enlace.
2. En el dispositivo del proveedor o upstream, comprobar que la IP alias sea accesible mediante la dirección MAC o el vecino esperados.
3. Desde 198.51.100.25, abrir una conexión HTTPS nueva hacia la IP alias.
4. En Log Viewer, comprobar Firewall Rule ID, NAT Rule ID, la fuente, Original destination y el destino traducido esperados.
5. En el Packet Capture integrado, comparar la entrada por Port2 y la salida hacia el servidor.
6. En el servidor interno, confirmar que la conexión llega y que la respuesta vuelve a través de Sophos Firewall.
7. Probar negativamente un puerto no permitido de forma intencionada y una fuente no autorizada.
8. 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.

Para el ejemplo IPv4, comparar por separado las entradas ARP de la dirección principal 203.0.113.9 y de la IP alias 203.0.113.10 con la dirección MAC WAN actual. Si la dirección principal funciona, pero el alias sigue apuntando a la MAC antigua y no llegan paquetes a Port2 durante la prueba externa, una entrada upstream obsoleta es una pista concreta. Si ya llegan paquetes, investigar primero la ruta de firewall/NAT y la respuesta del servidor, en lugar de reiniciar el router por sospecha. La ausencia de una entrada no demuestra por sí sola la causa; para un bloque enrutado del proveedor, comprobar también la ruta confirmada y su siguiente salto. IPv6 utiliza Neighbor Discovery en lugar de ARP.

⚠️ Vaciar una caché o reiniciar un router no garantiza una reparación sin interrupciones. Antes, involucrar al responsable del dispositivo o del proveedor, confirmar el procedimiento documentado y el alcance de la intervención, y asegurar acceso por consola o una vía de administración independiente. El acceso remoto al firewall también puede pasar por este router y quedar interrumpido. Si no se controla el dispositivo upstream, solicitar la intervención del proveedor indicando la IP afectada, las direcciones MAC antigua/nueva y el resultado de la prueba. Tras el cambio, verificar la entrada nueva, repetir la misma prueba HTTPS externa y comprobar un servicio no afectado; si el problema persiste, escalar los resultados en lugar de vaciar repetidamente toda la caché.

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:

1. Documentar los usos activos del alias y del IP Host asociado.
2. Retirar de forma controlada los servicios publicados de DNS, monitorización o load balancing.
3. Desactivar primero las reglas de firewall y NAT asociadas y confirmar la interrupción del flujo previsto.
4. Utilizar el comando delete exacto para eliminar únicamente las entradas sys-traffic-nat que se hayan añadido durante este cambio y que no estuvieran presentes en el estado inicial guardado. Conservar las entradas existentes; si se ha modificado una entrada existente, restablecer exactamente su configuración anterior documentada y comprobarla con show advanced-firewall y una prueba del servicio. La retirada de entradas que ya están en producción requiere una eliminación autorizada por separado tras comprobar las dependencias.
5. Eliminar el alias y el objeto host solo cuando no quede ninguna dependencia productiva.
6. Volver a comprobar la interfaz principal, la dirección principal, el gateway y los servicios no afectados.
7. 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.

Preguntas frecuentes