Reenviar una IP virtual por IPsec a varios servidores
Una IP virtual puede apuntar a varios servidores internos a través de un túnel IPsec basado en rutas ya existente. El sitio remoto utiliza una única dirección de destino estable. Sophos Firewall enruta el tráfico por la interfaz XFRM y después traduce la dirección virtual a una lista de servidores mediante DNAT.
No se trata de un DNAT de Internet convencional: el túnel, las direcciones XFRM, las rutas SD-WAN, las reglas VPN y NAT deben funcionar como un único recorrido en ambos firewalls.
Procedimiento breve
- Validar un túnel basado en rutas Any-to-Any con interfaces XFRM direccionadas en ambos firewalls.
- Crear un gateway para cada dirección XFRM del peer.
- Configurar rutas SD-WAN simétricas para la red remota, las redes locales y la IP virtual.
- Crear reglas de firewall restrictivas para el origen remoto, la IP virtual y el servicio necesario.
- En el lado de los servidores, crear una regla DNAT desde la IP virtual a una lista de servidores con Round-robin.
- Verificar varias conexiones nuevas mediante Log Viewer, Rule IDs, NAT Rule ID y Packet Capture.
⚠️ Una conexión IPsec verde o un gateway XFRM activo todavía no demuestran que DNAT y la ruta de retorno funcionen. Antes del cambio productivo debe poder seguirse el flujo real de la aplicación en ambas direcciones.
Cuándo encaja este diseño
Este procedimiento encaja cuando los hosts de un sitio remoto deben acceder a un servicio interno mediante una dirección virtual fija y las direcciones reales de los servidores deben permanecer ocultas. Una lista de servidores puede distribuir las conexiones nuevas entre dos servidores de aplicaciones equivalentes, por ejemplo.
Para una única conexión directa a un servidor conocido suele bastar una ruta normal más una regla de firewall. Si el servicio debe publicarse en Internet, se utiliza en su lugar el procedimiento DNAT o WAF habitual. La planificación general del túnel se explica en Configurar una VPN IPsec Site-to-Site.
Este diseño no es adecuado para IPsec basado en políticas ni para túneles basados en rutas con Traffic Selectors concretos. El recorrido descrito requiere un túnel basado en rutas con Any como redes local y remota, interfaces XFRM direccionadas y enrutamiento explícito.
Topología de ejemplo
En el ejemplo, los clientes de 192.168.3.0/24 acceden a la dirección virtual 10.10.10.1. Los servidores 172.16.16.2 y 172.16.16.3 se encuentran detrás de Firewall 1. Las direcciones de transferencia XFRM son 10.255.255.1/30 y 10.255.255.2/30.
Remote clients Route-based IPsec Server site
192.168.3.0/24 → xfrm2 10.255.255.2 ⇄ 10.255.255.1 xfrm1 → VIP 10.10.10.1
│ DNAT
┌───────────────┴───────────────┐
172.16.16.2 172.16.16.3
Todas las direcciones son valores de ejemplo y deben sustituirse por las redes reales. Las direcciones XFRM deben formar una red de transferencia propia que no se utilice en ningún otro lugar. La IP virtual no puede solaparse con un host real, una interfaz, una red VPN ni otra publicación NAT.
Preparar el túnel y XFRM
Túnel Any-to-Any y direcciones de transferencia
En Firewall 1, el túnel se crea como Route-based (Tunnel interface) con Respond only; en Firewall 2 se utiliza Initiate the connection. En ambos lados se configura Any en Local subnet y Remote subnet.
A continuación se asignan las direcciones de transferencia a las interfaces XFRM en Network > Interfaces:
- Firewall 1,
xfrm1:10.255.255.1/30 - Firewall 2,
xfrm2:10.255.255.2/30
Los parámetros de Phase 1 y Phase 2, los IDs y la autenticación deben estar ya validados. Las direcciones XFRM no se modifican en un túnel productivo sin probar.
Crear gateways XFRM
Cada firewall necesita un gateway hacia la dirección XFRM del peer para las rutas SD-WAN:
- Firewall 1: Gateway IP
10.255.255.2a través dexfrm1 - Firewall 2: Gateway IP
10.255.255.1a través dexfrm2
El estado del gateway solo comprueba el Monitoring Target seleccionado. Crear y comprobar un Custom Gateway explica por completo el objeto, el Health Check y la prueba funcional.
Crear las reglas y rutas SD-WAN
Firewall 1 en el sitio de los servidores
La regla de firewall entrante solo permite el flujo previsto:
- Source zone:
VPN - Source networks and devices:
192.168.3.0/24 - Destination zone:
Any, como en el ejemplo de Sophos para la dirección virtual - Destination networks:
10.10.10.1y otras redes locales solo si son necesarias - Services: solo el servicio de la aplicación, por ejemplo
HTTPS - Log firewall traffic: activado
Any en Destination zone no justifica orígenes, destinos o servicios amplios. La IP virtual no está asignada a una interfaz normal. Por eso debe comprobarse la Rule ID con tráfico real.
La ruta SD-WAN de Firewall 1 envía el tráfico de retorno a la red remota mediante el gateway XFRM. En Source networks se introducen las redes locales realmente necesarias y 10.10.10.1; en Destination networks, 192.168.3.0/24.
Firewall 2 en el sitio remoto
La regla saliente utiliza LAN como Source zone y VPN como Destination zone. El origen es 192.168.3.0/24, el destino es como mínimo 10.10.10.1, el servicio coincide con la aplicación y el logging permanece activado durante la implantación.
La ruta SD-WAN de Firewall 2 envía el tráfico de 192.168.3.0/24 a 10.10.10.1 mediante el gateway XFRM. Route only through specified gateways evita un recorrido alternativo por otra ruta cuando el servicio solo debe ser accesible a través de este túnel.
La decisión sobre esta opción forma parte del plan de fallo. Sin ella puede asumir el tráfico otra ruta; con ella SFOS descarta el tráfico si el gateway especificado no está disponible. Crear y probar una ruta SD-WAN explica la configuración completa.
Traducir la IP virtual a la lista de servidores mediante DNAT
En Firewall 1 se crea una regla específica en Rules and policies > NAT rules > Add NAT rule > New NAT rule:
- Original source:
192.168.3.0/24 - Translated source:
Original - Original destination:
10.10.10.1 - Original service: el servicio real de la aplicación, por ejemplo
HTTPS - Translated destination: objeto de lista de servidores con
172.16.16.2y172.16.16.3 - Translated service:
Original - Load balancing method:
Round-robin
DNAT no permite tráfico por sí solo. La regla de firewall, la ruta SD-WAN y la ruta de retorno siguen siendo requisitos independientes. Entender NAT en Sophos Firewall explica los valores originales y traducidos y el orden de las reglas.
Round-robin distribuye las nuevas conexiones coincidentes entre los miembros de la lista de servidores. Por eso un canal de navegador o aplicación reutilizado no es una prueba de distribución válida. El método de selección tampoco confirma automáticamente el estado de la aplicación en cada backend. Ambos servidores se comprueban por separado con sesiones nuevas.
Validar el recorrido completo
Antes de la prueba se documentan el estado del túnel, las direcciones XFRM, el estado de los gateways, la posición de las rutas SD-WAN y las Rule IDs. Después se crean varias conexiones nuevas desde la red remota hacia la IP virtual.
En Log Viewer deben verse el origen 192.168.3.0/24, el destino 10.10.10.1, la Firewall Rule ID esperada y la NAT Rule ID. El Traffic Count de la ruta SD-WAN debe aumentar. Un Packet Capture restrictivo muestra si los paquetes entran por la interfaz XFRM, se envían al servidor seleccionado tras DNAT y regresan por el mismo túnel.
La prueba se repite con ambos backends. En los servidores deben ser correctos la dirección de cliente esperada, el servicio y la ruta de retorno. Un ping a la IP virtual no sustituye una prueba real de HTTPS, SAP u otra aplicación.
Probar una regla de firewall con Log Viewer y Packet Capture ayuda a comprobar conjuntamente la regla, NAT y el recorrido de paquetes.
Delimitar errores sistemáticamente
El túnel está verde, pero la IP virtual no responde
Primero se comprueba la ruta SD-WAN en Firewall 2: ¿coinciden origen, destino, servicio y gateway XFRM? Después se controlan la Rule ID y la NAT Rule ID en Firewall 1. Si falta la NAT Rule ID, no coinciden Original source, Original destination, el servicio o la posición de la regla.
DNAT coincide, pero el servidor no responde
Se comprueban el objeto de lista de servidores, el servicio local y el gateway del servidor. La ruta de retorno debe pasar por Firewall 1 para que la sesión NAT existente traduzca la respuesta de nuevo a 10.10.10.1. No se añade una regla MASQ amplia como atajo, ya que puede falsear el diagnóstico.
Solo un servidor recibe conexiones
Se utilizan varias sesiones realmente nuevas y se cierran las conexiones Keep-alive existentes. Después se comparan la lista de servidores, Load balancing method y la NAT Rule ID. Si un backend no funciona directamente, primero se repara su servicio o su recorrido local.
El tráfico toma otra ruta
Se comprueban la posición y el Traffic Count de las rutas SD-WAN y los gateways XFRM seleccionados. Policy Tester no tiene en cuenta por completo las rutas SD-WAN; se utilizan conjuntamente Log Viewer, Route lookup y Packet Capture.
Revertir de forma segura
Antes del cambio se documentan el backup de configuración, el estado del túnel, las direcciones XFRM, los objetos de gateway, las reglas y las rutas. Si el nuevo recorrido no funciona:
- Desactivar la nueva regla DNAT.
- Desactivar las dos rutas SD-WAN nuevas.
- Restaurar las reglas de firewall específicas a su estado anterior.
- Eliminar los gateways XFRM y las direcciones de transferencia solo si ninguna otra ruta los utiliza.
- Volver a probar el túnel y el flujo de aplicación originales.
No se elimina un gateway ni una interfaz XFRM mientras Object usage siga mostrando dependencias. Backup y restauración de Sophos Firewall explica el procedimiento seguro de copia y recuperación.