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
Anyen 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.168.2.0/24. Cada lado recibe su propia red virtual para el túnel:
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
Por tanto, un cliente de la central contacta con un servidor de la sucursal mediante su dirección en 192.168.3.0/24. Un cliente de la sucursal utiliza la dirección correspondiente de 192.168.1.0/24 para un servidor de la central. La dirección real 192.168.2.x permanece local en cada sede.
Las tres redes son valores de documentación 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
IPsec policy-based requiere tres objetos IP host 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.168.2.0, HO_LAN_NAT_192.168.1.0 y BO_LAN_NAT_192.168.3.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:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): activado
- Original subnet:
HO_LAN_REAL_192.168.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
En la sucursal, la conexión Policy-based se crea con Gateway type Initiate the connection. La asignación se invierte por completo:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): activado
- Original subnet:
BO_LAN_REAL_192.168.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. Durante una prueba real se comprueban 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.
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. Si su tráfico coincide en cambio con una regla MASQ, SFOS puede descartarlo porque estas interfaces XFRM no tienen una dirección IP asignada.
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
192.168.3.0/24 - Translated source:
Original - Original destination: red traducida de la central
192.168.1.0/24 - Translated destination: red real de la central
192.168.2.0/24 - 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 192.168.1.0/24 y utilizar como Original destination la red traducida de la sucursal 192.168.3.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
192.168.1.0/24 - Translated source:
Original - Original destination: red traducida de la sucursal
192.168.3.0/24 - Translated destination: red real de la sucursal
192.168.2.0/24 - 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 192.168.3.0/24. Ninguna regla SNAT o MASQ más general situada encima debe capturar antes el tráfico. 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.
Comprobar conjuntamente routing, DNS y aplicaciones
En cada lado, la ruta hacia la red remota traducida debe utilizar la interfaz XFRM correcta o su gateway supervisado. Una ruta hacia la red real idéntica sería ambigua y podría atraer tráfico local al túnel. Si existen varias rutas, se revisan conjuntamente Route Precedence, Administrative Distance y la selección SD-WAN.
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. 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:
- La conexión IPsec y la Child SA están activas.
- La Firewall Rule ID esperada permite el flujo.
- La NAT Rule ID esperada traduce correctamente las direcciones original y de destino.
- Packet Capture muestra entrada, traducción, salida XFRM y retorno.
- El servidor de destino ve la dirección de origen planificada y responde por la misma ruta.
Solo después de que funcionen ambas direcciones se añaden más hosts, servicios y nombres DNS. 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 reflejarse en ambos firewalls. Comparar Original y Translated source de la regla reflexiva, Remote subnet de la conexión IPsec, gateway del servidor y reglas en sentido inverso. Una traducción unilateral no puede producir un flujo bidireccional estable.
Coincide la regla NAT equivocada
Comprobar NAT Rule ID y orden. Una regla MASQ amplia, Default-SNAT o DNAT anterior puede coincidir antes que la regla VPN específica. No desactivar todas las reglas NAT por sospecha; correlacionar primero el flujo de prueba por timestamp y corregir solo la regla conflictiva.
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. Durante la migración solo se desactivan reglas antiguas cuando existe una reversión inequívoca documentada.
Si la validación falla, se desactivan las nuevas reglas NAT y rutas, se restaura la configuración anterior del túnel y se vuelve a probar el tráfico local original. 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.