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 elegidas, las reglas VPN y NAT deben funcionar como un único recorrido en ambos firewalls.

Procedimiento breve

1. Validar un túnel basado en rutas Any-to-Any con interfaces XFRM direccionadas en ambos firewalls.
2. Si se utiliza SD-WAN, crear en cada firewall un gateway hacia la dirección XFRM del peer.
3. Enrutar VIP-App (198.51.100.10/32) y la red cliente hacia XFRM con rutas estáticas, dinámicas o SD-WAN según la arquitectura existente.
4. Crear reglas de firewall restrictivas para el origen remoto, la IP virtual y el servicio necesario.
5. En el lado de los servidores, crear una regla DNAT desde la IP virtual a una lista de servidores con Round-robin.
6. 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. Crear primero un backup de configuración y documentar el estado inicial. 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 procedimiento concreto requiere un túnel basado en rutas con Any como redes local y remota, interfaces XFRM direccionadas y enrutamiento explícito. Un túnel basado en rutas con Traffic Selectors puede servir para el mismo objetivo, pero SFOS crea sus rutas a partir de los selectores, por lo que los pasos de gateway XFRM no se aplican sin cambios. Este procedimiento no se aplica a IPsec basado en políticas.

Topología de ejemplo

En el ejemplo, los clientes de 192.0.2.0/24 acceden a la dirección virtual 198.51.100.10. Los servidores 10.0.20.21 y 10.0.20.22 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.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        10.0.20.21           10.0.20.22

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.

El ejemplo conserva las direcciones de cliente con Translated source (SNAT): Original. Por tanto, ambos backends necesitan una ruta de retorno a 192.0.2.0/24 a través del firewall de los servidores. Si esto no es posible, puede requerirse un SNAT planificado; oculta la dirección del cliente y no es una solución general para un routing incorrecto.

192.0.2.0/24 y 198.51.100.0/24 son redes de documentación; 10.0.20.0/24 es la red de servidores del ejemplo.

Conservar el estado inicial

Antes de cambiar nada, crear un backup de configuración y documentar el estado de IPsec, las direcciones XFRM, el orden de routing y SD-WAN, las Rule IDs de firewall y NAT, los contadores existentes y los gateways predeterminados de los backends. Las sesiones ya establecidas no se utilizan como prueba.

Crear los objetos IP

En el firewall de los servidores, abrir Hosts and services > IP host > Add. Crear VIP-App con IP version IPv4, Type IP y la dirección virtual, y Remote-Clients con Type Network. Crear App-Backends con Type IP list y las direcciones de los servidores separadas por comas. En SFOS 22 una IP list admite hasta 800 direcciones y no puede pertenecer a un IP host group. La lista se usa directamente como Translated destination (DNAT).

Los valores concretos de los objetos del ejemplo son:

• VIP-App: IP version IPv4, Type IP, IP address 198.51.100.10.
• Remote-Clients: Type Network, IP address 192.0.2.0, Subnet /24.
• App-Backends: IP version IPv4, Type IP list, IP addresses 10.0.20.21,10.0.20.22.

Definir las rutas del túnel

Las rutas SD-WAN siguientes solo son necesarias si SD-WAN ya es el método de enrutamiento elegido. Un túnel Any-to-Any también puede usar rutas estáticas o dinámicas: en el sitio cliente, enrutar VIP-App (198.51.100.10/32) hacia XFRM; en el sitio servidor, Remote-Clients hacia XFRM. No deducir ni duplicar rutas sin revisar la route precedence existente.

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.

Si SD-WAN ya es el estándar de routing

Cada firewall necesita un gateway hacia la dirección XFRM del peer para las rutas SD-WAN:

• Firewall 1: Gateway IP 10.255.255.2 a través de xfrm1
• Firewall 2: Gateway IP 10.255.255.1 a través de xfrm2

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.

La ruta SD-WAN de Firewall 2 envía el tráfico de 192.0.2.0/24 a 198.51.100.10 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.

Firewall 1 necesita una ruta efectiva hacia 192.0.2.0/24 mediante XFRM. No se debe presuponer que una ruta SD-WAN simétrica gestione las respuestas: las rutas SD-WAN solo se aplican a reply packets si está activado set routing sd-wan-policy-route reply-packet enable. Comprobar este ajuste global o utilizar el diseño estático o dinámico existente.

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:

• Rule name: DNAT-VPN-VIP-App
• Rule position: por encima de reglas NAT más amplias que también puedan coincidir
• Original source: 192.0.2.0/24
• Translated source: Original
• Original destination: 198.51.100.10
• Original service: el servicio real de la aplicación, por ejemplo HTTPS
• Translated destination: objeto de lista de servidores con 10.0.20.21 y 10.0.20.22
• Translated service: Original
• Inbound interface / Outbound interface: Any (obligatorio en los campos NAT para tráfico VPN)
• Load balancing method: Round robin
• Health check: activado, Probe method TCP, Port 443

DNAT no permite tráfico por sí solo. La regla de firewall, la ruta del túnel elegida 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.

Round robin envía las solicitudes nuevas de forma secuencial. Sin Health check, SFOS considera disponibles todos los miembros y puede elegir un servidor caído. Configurar Probe interval, Response time-out y Deactivate host after; una sonda TCP no sustituye la prueba de la aplicación. NAT solo se aplica al primer paquete: un cambio no mueve sesiones establecidas y debe probarse con conexiones nuevas.

Crear la regla de firewall correspondiente

La regla saliente utiliza LAN como Source zone y VPN como Destination zone. El origen es 192.0.2.0/24, el destino es 198.51.100.10, el servicio coincide con la aplicación y el logging permanece activado durante la implantación.

La regla de firewall entrante solo permite el flujo previsto:

• Rule name: Allow-VPN-VIP-App
• Rule position: por encima de reglas que se solapen
• Action: Accept
• Source zone: VPN
• Source networks and devices: 192.0.2.0/24
• Destination zone: zona de los backends traducidos, LAN en este ejemplo
• Destination networks: solo 198.51.100.10
• Services: solo el servicio de la aplicación, por ejemplo HTTPS
• Log firewall traffic: activado

SFOS busca primero DNAT y después usa en la regla de firewall la zona del destino traducido. Destination networks sigue siendo la VIP original. Comprobar la posición y la Rule ID con tráfico real.

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 confirmarse el origen, la Firewall Rule ID esperada y la NAT Rule ID. La VIP antes de NAT y el backend traducido se comparan con un Packet Capture restrictivo; no se deduce la traducción de un campo de destino ambiguo. La captura también muestra si los paquetes entran por XFRM y las respuestas vuelven por el mismo firewall.

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

Sin NAT Rule ID

Comprobar Original source, VIP-App, HTTPS y la posición de la regla NAT. Verificar también que ninguna regla NAT anterior coincida primero. Tras una corrección debe iniciarse una conexión nueva, porque las sesiones existentes no se vuelven a evaluar contra NAT.

DNAT coincide, pero la regla de firewall no

Las Destination zones deben corresponder a la zona de las direcciones de backend traducidas, no a la VIP ni genéricamente a VPN. Destination networks sigue siendo VIP-App. Comprobar de nuevo la Rule ID y el evento de descarte en Log Viewer.

Un backend sigue sin estar disponible

Comparar el estado del Health Check, el método de sonda y el puerto con el servicio real. Sin Health Check, SFOS puede seleccionar un miembro caído. Incluso una sonda TCP correcta no valida la aplicación, TLS o la autorización; probar el backend directamente en la red de servidores y después mediante una sesión VIP nueva.

La respuesta sale por la ruta incorrecta

Comprobar el gateway predeterminado o la ruta específica del backend, la ruta a Remote-Clients y Packet Capture en el firewall de los servidores. No añadir una regla MASQ amplia como atajo de diagnóstico. Con SD-WAN, comprobar también la posición, la route precedence, la monitorización y Route only through specified gateways.

Revertir de forma segura

Primero desactivar DNAT para impedir sesiones nuevas; después dejar terminar o cerrar las existentes durante la ventana de mantenimiento. Los cambios NAT no se vuelven a evaluar para una conexión establecida. Desactivar únicamente las reglas y rutas creadas para este recorrido y restaurar el orden documentado.

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:

1. Desactivar la nueva regla DNAT.
2. Desactivar solo las rutas estáticas o SD-WAN creadas para este recorrido.
3. Restaurar las reglas de firewall específicas a su estado anterior.
4. Eliminar solo los gateways nuevos y quitar solo las direcciones XFRM recién asignadas cuando no existan dependencias.
5. Volver a probar el túnel y el flujo de aplicación originales.

No se elimina un gateway mientras Object usage siga mostrando dependencias. La interfaz XFRM la crea el túnel; no se elimina un túnel existente que transporte otras redes. Backup y restauración de Sophos Firewall explica el procedimiento seguro de copia y recuperación.

FAQ