Usar NAT en redes IPsec solapadas en Sophos Firewall

Si la central y la sucursal utilizan la misma subred real, ningún firewall puede decidir solo por la dirección de destino si un paquete debe permanecer en la red local o atravesar el túnel IPsec. El túnel puede aparecer en verde sin que exista un flujo inequívoco. La solución es un plan de traducción coordinado en ambos lados: cada sede se presenta ante la contraparte mediante una red traducida única.

El tipo de túnel determina el método. IPsec policy-based e IPsec route-based con traffic selectors concretos utilizan los ajustes NAT directamente en la conexión IPsec. Route-based Any-to-Any utiliza en cambio reglas DNAT y SNAT y una ruta hacia la red remota traducida. Configurar una VPN IPsec Site-to-Site explica la elección general del tipo de túnel.

Elegir el método correcto

Sophos admite traducción 1:1, 1:n o n:n para IPsec policy-based. Con n:n, la red original y la traducida deben tener el mismo tamaño. Por ejemplo, un /24 se asigna a otro /24, no a un /25.

Bastan tres preguntas para elegir:

• ¿La conexión IPsec contiene Local y Remote subnets concretas? Se utiliza Network address translation (NAT) en la conexión.
• ¿Ambas subredes están en Any en un túnel route-based? Se utiliza DNAT con una regla SNAT reflexiva y una ruta por XFRM.
• ¿Las redes no se solapan? Normalmente NAT es innecesario y dificulta logs, reglas y troubleshooting.

⚠️ Los dos métodos no se mezclan. Antes del cambio se guardan ambas configuraciones de túnel, reglas NAT y de firewall, rutas, respuestas DNS y un acceso administrativo independiente. Una regla MASQ amplia o una dirección traducida improvisada no son soluciones seguras.

Crear un plan de direcciones para ambas sedes

En el ejemplo, la central y la sucursal utilizan la misma red real 192.0.2.0/24. Cada lado recibe su propia red virtual para el túnel:

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

Por tanto, un cliente de la central contacta con un servidor de la sucursal mediante su dirección en 203.0.113.0/24. Un cliente de la sucursal utiliza la dirección correspondiente de 198.51.100.0/24 para un servidor de la central. La dirección real 192.0.2.x permanece local en cada sede.

Las tres redes proceden de los bloques IPv4 reservados para ejemplos por RFC 5737 y deben sustituirse conjuntamente por redes libres del plan real. Las dos redes traducidas deben ser únicas, no pueden coincidir con ninguna LAN, VLAN, VPN, red cloud o doméstica y deben documentarse de forma simétrica en ambos firewalls. Si las aplicaciones utilizan nombres, el DNS de cada sede debe devolver la dirección traducida del sistema remoto.

Configurar IPsec policy-based con NAT

En Hosts and services > IP host > Add, IPsec policy-based requiere tres objetos de red en cada firewall: la red local real, la red traducida propia y la red traducida de la contraparte. En el ejemplo de la central son HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 y BO_LAN_NAT_203.0.113.0.

Configurar la central

En Site-to-site VPN > IPsec > Add, la conexión se crea como Policy-based con Gateway type Respond only. Perfil, autenticación, interfaz WAN y dirección del peer deben coincidir con la contraparte. Se utilizan estas asignaciones:

• Activate on save: activado
• Create firewall rule: activado
• Local subnet: HO_LAN_NAT_198.51.100.0
• Remote subnet: BO_LAN_NAT_203.0.113.0
• Network address translation (NAT): activado
• Original subnet: HO_LAN_REAL_192.0.2.0

El firewall traduce su red local real a la red traducida propia antes de enviarla. El tráfico entrante destinado a la red traducida vuelve a asignarse a la red real.

Configurar la sucursal de forma simétrica

Esta asignación de roles resulta especialmente útil cuando la sucursal tiene una dirección IP dinámica y la central no dispone de una dirección fiable de la contraparte para iniciar la conexión: en ese caso, la sucursal inicia hacia el extremo de la central, accesible de forma estable. Sin embargo, una dirección dinámica no es un impedimento absoluto si la dirección del peer puede resolverse de forma fiable y el diseño permite iniciar desde la central. A medida que se añaden sucursales, el establecimiento de conexiones escala mejor si cada sucursal reintenta su propia conexión en lugar de que la central tenga que reintentar todas las conexiones de las sucursales.

En la sucursal, la conexión Policy-based se crea con Gateway type Initiate the connection. La asignación se invierte por completo:

• Activate on save: activado
• Create firewall rule: activado
• Local subnet: BO_LAN_NAT_203.0.113.0
• Remote subnet: HO_LAN_NAT_198.51.100.0
• Network address translation (NAT): activado
• Original subnet: BO_LAN_REAL_192.0.2.0

Local y Remote subnet contienen las redes traducidas, mientras que Original subnet contiene la red local real. Si el tamaño o la dirección no coinciden, puede establecerse Phase 2, pero el tráfico se traduce de forma incorrecta o no encuentra ruta de retorno.

Revisar las reglas de firewall automáticas

Con Create firewall rule, SFOS crea reglas VPN entrantes y salientes. Se revisan en Rules and policies > Firewall rules, dentro del grupo Automatic VPN rules. Las reglas deben permitir las redes traducidas en la dirección correcta y solo los servicios necesarios. Una regla VPN general existente puede adaptarse; no es obligatorio crear una regla amplia por túnel.

Las reglas se evalúan de arriba abajo. Coloque estas reglas VPN por encima de cualquier regla más amplia que entre en conflicto y, durante una prueba real, compruebe Rule ID, zonas de origen y destino, redes de origen y destino, servicios y logging. Crear reglas de firewall en Sophos Firewall explica la lógica general.

Establecer la conexión cuando sea necesario

Compruebe el estado del túnel solo después de configurar ambas sedes y revisar las reglas de firewall. Activate on save activa la entrada de configuración, pero no demuestra que el túnel esté establecido. Si el túnel aún no está establecido y es necesario iniciarlo manualmente, vaya a Site-to-site VPN > IPsec en el lado iniciador – la sucursal en este ejemplo – y pulse el botón de estado de la columna Connection de la conexión correspondiente.

No desconecte ni restablezca una SA de producción ya establecida para realizar este paso; no es necesario pulsar ese botón en la central que responde. Un indicador de conexión verde confirma el establecimiento del túnel, no el funcionamiento del flujo de datos: a continuación, realice en ambas direcciones las comprobaciones de servicio, Child SA y captura descritas más abajo.

Configurar route-based Any-to-Any con DNAT y SNAT

Este método requiere un túnel route-based Any-to-Any funcional. La interfaz XFRM tiene una dirección de tránsito única, existen reglas LAN-to-VPN y VPN-to-LAN adecuadas y una ruta estática, SD-WAN o dinámica conduce a la red traducida de la contraparte. Solo entonces se añade NAT.

Las conexiones route-based con traffic selectors concretos no utilizan este procedimiento. Al igual que IPsec policy-based, utilizan los ajustes NAT de la conexión IPsec. Es un procedimiento Sophos independiente que no debe mezclarse con las reglas DNAT/SNAT de Any-to-Any.

NAT en la central

En Rules and policies > NAT rules > Add NAT rule > New NAT rule se crea una regla DNAT. Traduce los paquetes entrantes dirigidos a la red virtual de la central hacia la red local real:

• Original source: red traducida de la sucursal 203.0.113.0/24
• Translated source: Original
• Original destination: red traducida de la central 198.51.100.0/24
• Translated destination: red real de la central 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: activado
• Load balancing method: One-to-one

Para la asignación se utilizan objetos de red o IP range del mismo tamaño. Después de guardar, se abre la regla generada Reflexive_NAT#_<DNAT_rule_name>. En sentido saliente debe traducir la red real de la central a 198.51.100.0/24 y utilizar como Original destination la red traducida de la sucursal 203.0.113.0/24.

NAT en la sucursal

En la sucursal se aplica el mismo principio de forma simétrica:

• Original source: red traducida de la central 198.51.100.0/24
• Translated source: Original
• Original destination: red traducida de la sucursal 203.0.113.0/24
• Translated destination: red real de la sucursal 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: activado
• Load balancing method: One-to-one

La regla reflexiva debe traducir en sentido saliente la red real de la sucursal a 203.0.113.0/24. El valor Any para ambas interfaces es intencionado en este patrón documentado; no lo sustituya por WAN solo porque el peer IPsec se alcance por WAN. Los objetos de direcciones traducidas y las reglas de firewall proporcionan el alcance limitado. Ninguna regla SNAT o MASQ más general situada encima debe capturar antes el tráfico.

SFOS compara una regla NAT con el origen, destino y servicio originales, antes de NAT, y con las interfaces de entrada y salida. NAT solo se aplica al primer paquete de una conexión, por lo que cada prueba posterior a un cambio de NAT debe utilizar una conexión nueva, con una nueva quíntupla. El orden y la coincidencia se demuestran mediante NAT Rule ID y Packet Capture, no solo deduciéndolos de la lista. Comprender NAT en Sophos Firewall explica las reglas reflexivas y el principio first-match.

Asignar con precisión las reglas firewall de Any-to-Any

Una regla NAT no permite tráfico. En Rules and policies > Firewall rules > Add firewall rule > New firewall rule, cree reglas limitadas: en la central, la salida usa zona LAN, red real de la central, zona VPN y red traducida de la sucursal; la entrada usa zona VPN, red traducida de la sucursal, zona LAN y red real de la central. Invierta las sedes en la sucursal, limite Services y active Log firewall traffic durante la validación. La diferencia sigue el orden NAT: firewall antes de SNAT al salir y DNAT antes del firewall al entrar.

Comprobar conjuntamente routing, DNS y aplicaciones

En route-based Any-to-Any, en cada lado debe existir una ruta estática, SD-WAN o dinámica configurada manualmente hacia la red remota traducida, a través de la interfaz XFRM correcta o de su gateway supervisado. Si existen varias rutas, se revisan conjuntamente Route Precedence, Administrative Distance y la selección SD-WAN. En route-based con traffic selectors concretos, en cambio, se crea automáticamente una ruta estática al establecerse el túnel; en este caso se comprueban esa ruta y los selectors correspondientes. En IPsec policy-based, SFOS crea una ruta VPN en el backend al establecerse el túnel y asigna el tráfico según la política VPN o las Local y Remote subnets; una ruta XFRM propia no forma parte de este método. En las tres variantes, la red real idéntica debe permanecer local y no debe desviarse al túnel mediante una ruta hacia la red remota.

La aplicación también debe utilizar el destino traducido. Las configuraciones estáticas, ACL, respuestas DNS, monitoring y logs del servidor no pueden seguir esperando la dirección remota real. Por eso, una prueba NAT únicamente con ping no demuestra que el proceso de negocio funcione.

Validar el flujo en ambas direcciones

La validación comienza con un host conocido y un servicio TCP o UDP real en cada lado. Revise Current activities > IPsec connections y Reports > VPN. En Diagnostics > Packet capture > Configure, un filtro BPF como host 203.0.113.10 limita la captura a la prueba. Desde la central se accede a la dirección traducida de la sucursal y después desde la sucursal a la dirección traducida de la central. Para el mismo timestamp se comprueba:

1. La conexión IPsec y la Child SA están activas.
2. La Firewall Rule ID esperada permite el flujo.
3. En Any-to-Any, los Rule IDs esperados de las reglas DNAT y SNAT reflexivas demuestran la traducción de origen y destino planificada. En IPsec policy-based y route-based con traffic selectors concretos, se comparan, en cambio, los valores guardados de Original subnet, Local subnet y Remote subnet en ambos lados, los selectors negociados y las direcciones originales y traducidas observadas en el flujo de prueba. Este NAT integrado en la conexión no requiere una NAT Rule ID independiente.
4. Packet Capture muestra la entrada, el reenvío y el retorno mediante In interface, Out interface, Rule ID, Status y Reason. Se comparan las direcciones de origen y destino antes y después de la traducción con el plan de direcciones; el filtro debe incluir las direcciones originales o traducidas que se estén comprobando. En route-based, se comprueba la interfaz XFRM correspondiente; en policy-based, el trayecto IPsec a través de la interfaz IPsec compartida, no de una interfaz XFRM propia. En Any-to-Any, NAT ID permite además identificar la regla NAT independiente y no es una prueba obligatoria para el NAT integrado en la conexión.
5. El servidor de destino ve la dirección de origen planificada y responde por la misma ruta.

Como control negativo, se accede a continuación a la dirección real idéntica 192.0.2.10: debe permanecer local y no debe atravesar la VPN en ninguna de las tres variantes. Añada más hosts, servicios y nombres DNS solo tras obtener el resultado previsto en las pruebas positiva y negativa en ambas direcciones. Packet Capture en Sophos Firewall ayuda a comparar antes y después de NAT; Troubleshooting IPsec en Sophos Firewall describe la comprobación completa del túnel.

Acotar errores según el síntoma

El túnel está verde, pero el destino responde localmente

Probablemente el cliente utiliza la dirección real, que también existe localmente, en lugar de la red remota traducida. Comprobar la respuesta DNS, el archivo hosts, la configuración de la aplicación y la ruta de destino. El problema se produce entonces antes del túnel.

Funciona la ida, pero falta el retorno

Las traducciones deben ser simétricas en ambos firewalls. En Any-to-Any, se comparan Original source y Translated source, así como la dirección de destino remota que permanece sin cambios en la regla SNAT reflexiva; en IPsec policy-based y route-based con traffic selectors concretos, se comparan las asignaciones de Original subnet, Local subnet y Remote subnet, así como los selectors negociados de la conexión. También se comprueban el gateway del servidor y las reglas de firewall en sentido inverso. Una traducción unilateral no puede producir un flujo bidireccional estable.

Coincide la regla NAT equivocada

En Any-to-Any, se comprueban NAT Rule ID y el orden de las reglas DNAT/SNAT independientes. Una regla MASQ amplia, una regla Default-SNAT o una regla DNAT anterior puede coincidir antes que la regla VPN específica. No se desactivan todas las reglas NAT por sospecha; primero se correlaciona temporalmente el flujo de prueba y después se corrige solo la regla conflictiva. En IPsec policy-based y route-based con traffic selectors concretos, una traducción incorrecta se acota, en cambio, mediante los campos NAT de la conexión IPsec, los selectors negociados y las direcciones reales observadas antes y después de NAT; la ausencia de una NAT Rule ID independiente no constituye un error en estos casos.

Algunos hosts funcionan y otros no

Con n:n, los rangos original y traducido deben tener el mismo tamaño y posición. Comprobar objetos IP range, máscaras, direcciones excluidas, firewall del host y el offset realmente utilizado. El éxito para .10 no demuestra la asignación del rango completo.

Rollback y operación

Antes del cambio se preparan un backup de configuración, capturas o exportaciones de las configuraciones de túnel, NAT, firewall y routing y un acceso de administración independiente. Anote también los nombres, IDs, el orden y el estado de activación de todas las reglas y rutas afectadas, junto con los valores anteriores de DNS y aplicaciones. Durante la migración solo se desactivan reglas antiguas una vez documentado su estado anterior exacto.

Si la validación falla, restaure primero los valores DNS y de aplicación anotados. Para Any-to-Any, desactive solo las nuevas reglas firewall, el par DNAT/SNAT reflexivo y la ruta de la red traducida; para policy-based, restaure los campos Local, Remote y Original subnet guardados. Reponga después el orden y estado de activación anteriores de reglas y rutas y pruebe conexiones nuevas en ambos sentidos. Las sesiones existentes conservan la asignación NAT establecida con el primer paquete y no demuestran el rollback: deje continuar las sesiones no relacionadas y, si necesita una prueba inmediata, finalice solo las sesiones de prueba afectadas antes de repetirla. No vacíe todas las conexiones. Elimine direcciones XFRM y objetos solo cuando Object usage no muestre dependencias. Las redes traducidas solo se eliminan de DNS, monitoring y documentación cuando ya no queda ninguna dependencia.

En producción, las redes traducidas deben mantenerse en el plan central de direcciones IP. Las nuevas sedes, redes cloud, pools de Remote Access y redes domésticas se comparan con las redes originales y traducidas. De lo contrario, el solapamiento solo se desplaza a otro lugar.

Preguntas frecuentes