Configurar NAT64 en Sophos Firewall con Direct Web Proxy

Un cliente solo IPv6 puede acceder mediante Direct Web Proxy de Sophos Firewall a un sitio web que solo tiene una dirección IPv4. SFOS resuelve el nombre de destino en el proxy y establece la conexión posterior mediante IPv4. Para ello se necesitan dos reglas de firewall: una regla IPv6 del cliente al proxy y una regla IPv4 del proxy al destino.

No se trata de un NAT64 general de capa 3 para cualquier protocolo. Solo funciona para conexiones HTTP y HTTPS que los navegadores o las aplicaciones envían expresamente al proxy web. En este procedimiento no se crea una regla NAT64 normal en Rules and policies > NAT rules.

La clasificación completa se encuentra en Compatibilidad y límites de IPv6 en Sophos Firewall con SFOS 22. SFOS admite esta ruta NAT64 basada en proxy, pero indica que DNS64 no es compatible; esto no crea una transición general para otros protocolos.

⚠️ Las dos reglas tienen funciones distintas. Para endpoints solo IPv6, la Web Policy y la asociación de usuarios pertenecen a la regla IPv6. Application Control, IPS y las demás funciones de protección de la conexión IPv4 saliente pertenecen a la regla IPv4. Una única regla amplia no permite ver esta separación de forma fiable.

NAT64 mediante el proxy en ocho pasos

1. Seleccionar un cliente piloto solo IPv6 administrado y un destino web A-only controlado.
2. Comprobar la dirección IPv6, el DNS, el FQDN del proxy y el listener TCP de Direct Web Proxy.
3. Preparar la configuración básica de Direct Web Proxy, Device Access y el archivo PAC o la directiva del navegador.
4. En la vista IPv6, crear una regla con registro desde la red piloto hasta el puerto del proxy con la zona de destino WAN.
5. Definir la Web Policy y, si es necesario, Match known users en esta regla IPv6.
6. En la vista IPv4, crear una segunda regla con registro desde el proxy hasta el destino IPv4 con HTTP/HTTPS.
7. Probar con un destino sin registro AAAA y comprobar ambos Firewall Rule IDs y la decisión del filtro web.
8. Incorporar más clientes solo después de pruebas positivas y negativas; validar por separado el rollback, HA y SD-WAN.

Por qué se necesitan dos reglas de firewall

La ruta de datos cambia de versión IP en el proxy:

1. El cliente se conecta mediante IPv6 al listener del proxy del firewall.
2. La regla IPv6 evalúa el cliente, el usuario, el nombre de destino, el puerto del proxy y la Web Policy.
3. El proxy resuelve el nombre de host solicitado.
4. Si el destino solo tiene un registro A, el proxy crea una nueva conexión IPv4.
5. La regla IPv4 evalúa este segundo tramo y aplica, por ejemplo, Application Control o IPS.

La segunda conexión ya no es el paquete IPv6 original del cliente. Por tanto, la regla IPv4 no debe diseñarse como si la dirección IPv6 del cliente tuviera que aparecer como origen. Al mismo tiempo, una regla IPv6 correcta por sí sola todavía no demuestra que el proxy alcance realmente el destino IPv4.

Sophos denomina a este diseño un escenario NAT64. Sin embargo, a diferencia de un gateway NAT64 clásico, no se enruta un prefijo IPv6 para destinos IPv4 arbitrarios. Este procedimiento no traduce aplicaciones sin compatibilidad con proxy explícito, UDP, ICMP ni otro tráfico que no pase por el proxy.

Configurar Direct Web Proxy con un archivo PAC explica la configuración general del listener, PAC, Device Access y rollback. Este artículo presupone que la ruta básica del proxy funciona y solo añade la transición de IPv6 a IPv4.

Ejemplo y valores sustituibles

El procedimiento utiliza un pequeño piloto:

• Cliente solo IPv6: CLIENT6-PROXY-01
• Red piloto: 2001:db8:20:30::/64
• Dirección IPv6 del firewall en la red del cliente: 2001:db8:20:30::1
• FQDN del proxy: fw01.corp.example
• Puerto del proxy: TCP 3128
• Destino A-only controlado: v4-test.corp.example
• Dirección de destino de documentación: 192.0.2.80
• Regla IPv6: LAN6_DirectProxy_to_IPv4
• Regla IPv4: Proxy_IPv4_Egress_Pilot
• Web Policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 y .example son rangos de documentación. No funcionan como direcciones productivas y deben sustituirse por el prefijo IPv6 de la organización, la dirección real del firewall y un nombre DNS controlado. El cliente piloto debe utilizar realmente solo IPv6; una ruta IPv4 activa en paralelo invalidaría la prueba.

El destino de prueba necesita un registro A, pero ningún registro AAAA. Para ello conviene utilizar un pequeño servidor web propio o un host virtual de prueba controlado. Un sitio web público elegido al azar no es adecuado porque su operador puede activar IPv6 o cambiar las respuestas DNS en cualquier momento.

Configurar IPv6 Prefix Delegation explica cómo funcionan conjuntamente el prefijo WAN, Router Advertisement y DHCPv6. NAT64 no corrige la ausencia de direccionamiento IPv6 en la red del cliente.

Comprobar los requisitos

Antes de crear las reglas deben funcionar cuatro fundamentos por separado:

• El cliente tiene una dirección IPv6 válida, una ruta predeterminada y DNS operativo.
• fw01.corp.example devuelve en la red del cliente la respuesta AAAA prevista para el firewall.
• Direct Web Proxy escucha en el puerto documentado en Web > General settings > Web proxy configuration, 3128 en este ejemplo.
• El firewall dispone de una ruta WAN IPv4 operativa hasta el destino.

En Administration > Device access, Web proxy debe ser accesible para el origen concreto del cliente y la dirección prevista del firewall. No es necesario permitir toda la zona LAN o Wi-Fi para un piloto. El límite del proxy sigue siendo importante: un cliente autorizado puede alcanzar por esta ruta servicios HTTP/HTTPS locales del firewall. Por eso los destinos de administración se prueban expresamente como casos negativos, tal como se describe en el artículo básico.

El cliente recibe el FQDN y el puerto del proxy mediante una directiva administrada del navegador, una configuración del sistema operativo o un archivo PAC. El FQDN debe ser accesible por IPv6 desde el cliente solo IPv6. Un cliente solo IPv6 no puede utilizar como primer salto una dirección de proxy que solo tenga un registro A.

Documentar las reglas de firewall, Web Policies, autenticación, TLS Inspection y SD-WAN Routes existentes. Colocar las dos reglas piloto lo bastante arriba para que se evalúen antes que una regla general coincidente, sin sobrepasar de forma incontrolada reglas de protección existentes.

Crear la regla IPv6 hacia el proxy

En Rules and policies > Firewall rules, seleccionar primero IPv6 y crear una regla mediante Add firewall rule > New firewall rule:

• Rule name: LAN6_DirectProxy_to_IPv4
• Action: Accept
• Log firewall traffic: activado
• Source zones: LAN
• Source networks and devices: red piloto IPv6 o cliente piloto individual
• Destination zones: WAN
• Destination networks: destino FQDN controlado o, para el despliegue posterior, el conjunto de destinos planificado expresamente
• Services: servicio TCP propio para 3128
• Match known users: solo con una autenticación ya funcional y los usuarios o grupos previstos
• Web filtering > Web policy: Web_Standard_IPv6_Pilot

La zona de destino WAN parece inusual al principio porque técnicamente el cliente se conecta a una dirección del firewall. Sin embargo, Sophos exige WAN o Any para entregar el tráfico al componente proxy. Según el fabricante, esto también se aplica cuando el servidor web final está en LAN o DMZ. Por tanto, la zona de destino no debe cambiarse por intuición a la zona física del servidor.

Sophos también permite Any en Services. El puerto concreto del listener resulta más comprensible para un piloto y evita una autorización innecesariamente amplia. Si cambia Web proxy listening port, el servicio, la configuración PAC/del navegador, Device Access y las pruebas deben utilizar el mismo valor.

Para endpoints solo IPv6, configurar los usuarios y grupos en esta regla IPv6. La Web Policy también se aplica aquí. La guía sobre reglas de firewall explica el orden, el registro y la asociación de usuarios; las categorías y acciones se planifican en Web Protection Policies.

Crear la regla IPv4 del proxy al destino

A continuación, cambiar a IPv4 en Rules and policies > Firewall rules y crear la segunda regla:

• Rule name: Proxy_IPv4_Egress_Pilot
• Action: Accept
• Log firewall traffic: activado
• Source zones: Any
• Source networks and devices: Any
• Destination zones: WAN
• Destination networks: primero el destino A-only controlado, después solo el conjunto de destinos realmente necesario
• Services: HTTP y HTTPS, o los puertos de destino realmente necesarios
• Match known users: no utilizarlo como sustituto de la asociación de usuarios en la regla IPv6 para este procedimiento solo IPv6
• Other security features: políticas previstas de Application Control, IPS y, si es necesario, Traffic Shaping

El ejemplo oficial de Sophos utiliza Any para la zona y la red de origen porque el proxy crea la conexión IPv4. Estos valores no deben sustituirse erróneamente por la red IPv6 del cliente. En su lugar, mantener limitada la regla piloto mediante el destino y los servicios y verificarla por su Rule ID.

La Web Policy no se traslada a esta regla IPv4. Pertenece al primer tramo del proxy, relacionado con el usuario. Application Control e IPS protegen, en cambio, el tramo entre el proxy y el destino IPv4. Una política de Traffic Shaping en la regla IPv4 se aplica a este egreso; Sophos también documenta que Traffic Shaping no se aplica a la conexión directa entre el cliente y el proxy.

No crear una regla NAT64 adicional. La ruta WAN IPv4 normal del firewall debe seguir funcionando. Si una regla IPv4 existente ya cubre de forma controlada este egreso del proxy, puede seguir utilizándose después de comprobar su Rule ID y sus políticas; una segunda regla Any paralela sería peor que una regla existente documentada conscientemente.

Probar la ruta IPv6 a IPv4 real

Comprobación previa de DNS y listener

Estas comprobaciones de solo lectura son útiles en un cliente piloto Windows:

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

El FQDN del proxy debe devolver la dirección IPv6 esperada. El destino de prueba debe tener un registro A; no se espera una dirección de destino en la prueba AAAA. Test-NetConnection solo confirma el listener TCP, no la Web Policy, la resolución DNS en el proxy ni el egreso IPv4.

Validar ambas reglas y capas de protección

1. Abrir una nueva sesión privada del navegador en el piloto solo IPv6.
2. Comprobar el proxy efectivo o el archivo PAC cargado.
3. Abrir el destino A-only permitido.
4. Abrir un destino bloqueado expresamente por Web_Standard_IPv6_Pilot.
5. En Log viewer, comprobar la regla IPv6, el origen, el usuario, la Web Policy, la acción y el Firewall Rule ID.
6. Para la conexión posterior, comprobar la regla IPv4, el destino IPv4, el servicio, Application Control/IPS y el segundo Firewall Rule ID.
7. Repetir la solicitud al destino sin proxy como prueba negativa; el cliente solo IPv6 no debe poder alcanzar directamente por IPv4 el destino A-only.
8. Probar una aplicación sin compatibilidad con proxy y confirmar que no se considera erróneamente compatible con NAT64.

El éxito solo queda demostrado si el nombre de destino es realmente A-only, el cliente alcanza el proxy por IPv6, coinciden las dos reglas esperadas y las pruebas web permitida y bloqueada muestran las acciones previstas. Probar reglas de firewall de forma sistemática explica cómo correlacionar Rule ID, Log Viewer, Policy Tester y Packet Capture.

Delimitar los errores sistemáticamente

No se puede acceder al puerto del proxy por IPv6

Comprobar la respuesta AAAA del FQDN del proxy, la dirección del cliente, la ruta predeterminada, Neighbor Discovery, la interfaz del firewall y Web proxy en Device Access. Una prueba IPv4 correcta desde otro cliente no dice nada sobre la ruta del listener IPv6.

La regla IPv6 coincide, pero el destino no carga

Confirmar primero que el proxy resuelve el nombre de destino como registro A y que el propio firewall tiene una ruta WAN IPv4 operativa. Después comprobar la regla IPv4, el destino, el servicio, el orden y la Rule ID. La regla IPv6 solo es la primera mitad.

Solo funcionan los sitios web dual-stack

La ruta NAT64 aún no está demostrada. Comprobar si el destino de prueba tiene un registro AAAA. Utilizar un destino A-only propio para la validación y descartar una ruta IPv4 activa en el cliente.

La Web Policy o el usuario no son correctos

Comprobar la asignación en la regla IPv6. SFOS evalúa Match known users en ambas reglas para endpoints solo IPv6, pero Sophos asigna expresamente estos ajustes a la regla IPv6. Una asociación de usuarios en la regla IPv4 no debe sustituir el contexto de usuario ausente en el primer tramo.

Application Control o IPS no se aplica

Comprobar estas funciones en la regla IPv4 y no solo en la regla IPv6. Después confirmar mediante la Rule ID IPv4 que esta regla procesa realmente el egreso del proxy. Una decisión correcta del filtro web no demuestra Application Control ni IPS.

Los destinos internos o locales se comportan de forma inesperada

Aunque el destino final esté en LAN o DMZ, la regla IPv6 exige WAN o Any para entregar el tráfico al proxy. La zona de destino real se representa en la regla IPv4. Comprobar también la exposición de servicios de administración locales causada por el acceso al proxy y las respuestas DNS internas.

SD-WAN, HA y rollback

Una SD-WAN Route con los servicios HTTP y HTTPS no coincide con la conexión del cliente al puerto de proxy 3128. Para el primer tramo debe utilizarse el puerto real del listener o, de forma consciente, Any. El egreso del proxy también necesita un gateway WAN o una ruta estática de retorno operativos. Configurar y probar SD-WAN Routes explica estos casos especiales.

En HA no se debe prometer la continuación sin interrupciones de una conexión de proxy existente. Después de un failover controlado, abrir una nueva sesión del navegador y volver a comprobar el registro AAAA del proxy, la Rule ID IPv6, la Web Policy, la Rule ID IPv4 y el acceso al destino. Para buscar registros cuenta el nodo que procesó el tráfico correspondiente.

Para el rollback:

1. Desactivar las reglas piloto o devolverlas al estado anterior documentado.
2. Eliminar la excepción dedicada de Device Access para el piloto si solo se creó para esta prueba.
3. Retirar del piloto la configuración PAC, GPO o del proxy del navegador.
4. Restaurar el orden anterior de las reglas IPv4/IPv6 y la configuración SD-WAN.
5. Volver a comprobar el acceso IPv6 directo, el tráfico de proxy existente y los servicios de administración locales.

No eliminar las dos reglas antes de documentar la ruta anterior y disponer de una sesión de administración abierta o de un acceso de administración alternativo.

Lista de comprobación para la aprobación

• El cliente es demostrablemente solo IPv6.
• El FQDN del proxy devuelve la dirección AAAA esperada.
• El destino de prueba tiene un registro A, pero ningún registro AAAA.
• Direct Web Proxy y Device Access están limitados al piloto.
• La regla IPv6 utiliza la zona de destino WAN, el puerto real del listener, registro y Web Policy.
• La asociación de usuarios, si se necesita, ha superado pruebas positivas y negativas en la regla IPv6.
• La regla IPv4 procesa el egreso del proxy con los puertos de destino y las funciones de protección planificados.
• Ambos Firewall Rule IDs y ambas versiones IP están demostrados en la prueba.
• La exposición de servicios de administración, el tráfico que no pasa por el proxy, SD-WAN y HA están delimitados conscientemente.
• El rollback, el responsable y la fecha de revisión están documentados.

Preguntas frecuentes