Configurar Direct Web Proxy en Sophos Firewall con un archivo PAC

Con Direct Web Proxy, los navegadores y las aplicaciones compatibles con proxy envían deliberadamente sus conexiones HTTP y HTTPS a Sophos Firewall. Esto lo diferencia del proxy web transparente y de DPI Engine: el cliente conoce el destino proxy y normalmente se conecta al puerto TCP 3128.

Direct Web Proxy resulta útil cuando el tráfico web debe controlarse de forma centralizada mediante un archivo PAC, autenticarse por usuario o procesarse con funciones que necesitan el proxy web. Sin embargo, no es una ruta general a Internet para cualquier aplicación. Solo pasa por esta ruta el tráfico que utiliza realmente la configuración proxy.

⚠️ Un cliente con acceso al proxy web puede alcanzar por esta ruta servicios HTTP y HTTPS locales del firewall, aunque WebAdmin, User Portal o VPN Portal no estén activados para su zona en Device access. Por eso, primero se abre el proxy solo para un cliente piloto y se prueban expresamente estos destinos de administración de forma negativa.

Este procedimiento se centra en un cliente piloto IPv4 administrado. Para clientes solo IPv6, configurar NAT64 con Direct Web Proxy explica la regla IPv6 separada hacia el proxy y la regla IPv4 hacia el destino A-only.

Direct Web Proxy en diez pasos

1. Definir un cliente piloto administrado, su IP fija y los destinos web necesarios.
2. Documentar el FQDN del proxy, DNS, puerto de escucha y dependencias proxy existentes.
3. En Web > General settings, comprobar Web proxy listening port y los puertos de destino permitidos.
4. En Administration > Device access, permitir el servicio Web proxy solo para el piloto y la dirección prevista del firewall.
5. Crear una regla de firewall propia y con registro, con el piloto como origen, WAN como destino, servicio TCP 3128 y la Web Policy deseada.
6. Preparar un archivo PAC con destinos internos DIRECT deliberados y sin un fallback de Internet que evite el proxy.
7. Distribuir la URL PAC solo al cliente piloto y comprobar la configuración proxy cargada realmente.
8. Probar una solicitud HTTP/HTTPS permitida y otra bloqueada y comprobar la Firewall Rule ID esperada.
9. Probar de forma negativa los portales locales del firewall, el descifrado TLS, las aplicaciones sin soporte proxy y una caída del proxy.
10. Solo entonces incorporar más clientes administrados y documentar la reversión, el responsable y la fecha de revisión.

¿Direct Web Proxy, proxy transparente o DPI?

Los tres términos describen rutas de tráfico diferentes:

• Direct Web Proxy: El cliente está configurado expresamente para usar el firewall y su puerto proxy. El navegador, sistema operativo o aplicación envía la solicitud a fw01.corp.example:3128.
• Proxy web transparente: El cliente no conoce el proxy. Si el servicio está activo para su zona, el firewall intercepta de forma transparente HTTP en el puerto 80 y HTTPS en el puerto 443.
• DPI Engine: El firewall procesa tráfico enrutado sin exigir un proxy web clásico y puede inspeccionar HTTP o TLS en otros puertos según las reglas de firewall y de SSL/TLS inspection.

La opción Use web proxy instead of DPI engine de una regla de firewall no es un requisito para que un cliente configurado expresamente utilice Direct Web Proxy. La ruta del cliente surge de la configuración proxy. La opción determina si la regla usa el proxy web en lugar de DPI Engine para filtrar el tráfico web normal en los puertos habituales.

La decisión completa sobre el modo, incluidas las funciones exclusivas del proxy, la configuración TLS y la migración controlada de reglas, se explica en Elegir correctamente DPI Engine o Web Proxy.

Sophos sigue indicando funciones concretas que requieren Proxy Mode, como SafeSearch, YouTube Restrictions, las restricciones de dominio de Google Workspace, Pharming Protection, Web Cache o un Parent Proxy. Web Protection en Sophos Firewall explica la decisión sobre políticas y protección.

Si Sophos Firewall debe enviar Web Requests a otra instancia proxy, configurar un upstream proxy en WAN o LAN/DMZ explica la ruta separada de reglas, NAT y validación.

Direct Web Proxy también cambia la forma de observar el tráfico. El cliente se conecta primero al firewall y este crea después la conexión al destino. Por ello, Sophos documenta dos límites importantes:

• Una IPS Policy se aplica entre el proxy y WAN, no entre el usuario y el proxy.
• Una Traffic Shaping Policy no se aplica al tráfico de Direct Proxy.

Si una aplicación no puede trabajar con un proxy explícito, no debe esperarse que un archivo PAC capture sus conexiones. Para esa aplicación sigue siendo necesaria una ruta DPI, de firewall o proxy independiente y enrutada normalmente.

Ejemplo y valores sustituibles

El artículo utiliza un piloto pequeño:

• Cliente piloto: CLIENT-PROXY-01
• IP fija del cliente: 10.20.30.50
• zona del cliente: LAN
• FQDN del firewall y destino proxy: fw01.corp.example
• puerto de Direct Web Proxy: 3128
• URL PAC: https://config.corp.example/proxy.pac
• zona DNS interna: .corp.example
• regla de firewall: LAN_DirectProxy_Pilot
• Web Policy: Web_Standard_Pilot

Se sustituye 10.20.30.50 por la IP fija que el firewall ve realmente como origen del piloto. DHCP debería proporcionar una reserva para ella. La dirección no debe ocultar otros dispositivos detrás de NAT.

fw01.corp.example y config.corp.example son nombres de documentación. Se sustituyen por FQDN resolubles internamente y cubiertos por los certificados adecuados. El FQDN del proxy apunta a la dirección LAN o de administración prevista del firewall. La URL PAC apunta a un servidor web interno controlado o a una ruta existente de administración de endpoints, no a una ubicación pública arbitraria.

El puerto 3128 es el valor predeterminado de Direct Web Proxy. Si se utiliza otro Web proxy listening port, Device Access, la regla de firewall, el archivo PAC, el navegador, la SD-WAN Route y las pruebas deben contener el mismo puerto. El nombre de la regla o política se puede elegir libremente, pero debe indicar el propósito, origen y estado de piloto.

Preparar el acceso proxy y la regla de protección

Definir el listener y los puertos de destino permitidos

En Web > General settings > Web proxy configuration se comprueban los fundamentos del proxy:

1. Web proxy listening port: 3128 en este ejemplo.
2. Allowed destination ports: solo los puertos a los que los clientes realmente deben conectarse a través del proxy.
3. Minimum TLS version: versión mínima común para el proxy web y Captive Portal; un cambio afecta a ambas funciones.

Los puertos de destino permitidos no son el listener. El cliente se conecta al puerto 3128 del firewall, pero puede solicitar mediante HTTP CONNECT, por ejemplo, un destino externo en el puerto 443. Solo se añaden puertos de destino no estándar después de una prueba concreta de la aplicación. Una lista amplia convierte innecesariamente el proxy en un túnel genérico.

Antes de cambiar el puerto, se buscan archivos PAC, GPO, políticas de navegador, hosts RDS, SD-WAN Routes y monitorización existentes. El listener es un ajuste compartido, no un valor que se cambie solo para un piloto.

Limitar Device Access al piloto

El servicio Web proxy está activado de fábrica para LAN y Wi-Fi. Una excepción Accept adicional no limita un permiso amplio de zona que ya esté activo. Para un acceso piloto real, el permiso amplio debe permanecer desactivado o sustituirse primero de forma controlada por excepciones más limitadas.

En Administration > Device access > Local service ACL exception rule > Add:

1. Rule name: Allow_DirectProxy_Pilot
2. Rule position: por encima de una excepción Drop que coincida
3. IP version: IPv4
4. Source zone: LAN
5. Source Network / Host: CLIENT-PROXY-01 con 10.20.30.50
6. Destination host: dirección concreta del firewall a la que resuelve fw01.corp.example
7. Services: Web proxy
8. Action: Accept

Antes de desactivar un permiso amplio de zona, se comprueba si otros clientes o servicios ya utilizan el proxy directo o transparente. La guía de Device Access y Local Service ACL explica en detalle el orden de reglas, la matriz de zonas y las reglas de excepción.

Vincular la Web Policy y la regla de firewall

La Web Policy se prepara en Web > Policies. Contiene las categorías, URL Groups, reglas de usuario o grupo y acciones deseadas. Para el piloto debe definirse al menos un destino deliberadamente permitido y otro deliberadamente bloqueado.

Después se crea una regla IPv4 propia en Rules and policies > Firewall rules:

• Rule name: LAN_DirectProxy_Pilot
• Action: Accept
• Log firewall traffic: activado
• Source zones: LAN
• Source networks and devices: CLIENT-PROXY-01
• Destination zones: WAN
• Destination networks: Any o un grupo de destinos planificado de forma más limitada
• Services: servicio TCP propio para 3128
• Match known users: solo se activa si la ruta de autenticación elegida ya ha superado una prueba positiva
• Web filtering > Web policy: Web_Standard_Pilot
• Block QUIC protocol: se activa si no se debe permitir que el tráfico web evite en paralelo la inspección proxy mediante UDP 443; Controlar QUIC en Sophos Firewall explica el contexto
• Scan HTTP and decrypted HTTPS: solo con la licencia adecuada y un diseño de inspección deliberado

Según Sophos, Any también es posible como servicio para Direct Proxy, pero es más amplio de lo necesario. Un servicio TCP propio para el listener real hace que el piloto resulte más comprensible. Después de seleccionar una Web Policy y otras funciones de protección, se vuelve a comprobar la regla completa. Los fundamentos de reglas de firewall explican el orden, registro, relación con usuarios y campos de protección.

Para este piloto no se necesita automáticamente un Linked NAT. Sin embargo, la ruta a Internet que genera el firewall necesita un gateway WAN adecuado y la traducción de origen válida para el entorno. El enrutamiento y NAT se comprueban por separado.

Crear y distribuir el archivo PAC

Un ejemplo PAC deliberadamente limitado

Un archivo PAC es JavaScript con la función FindProxyForURL. Este ejemplo deja pasar directamente solo nombres internos cortos, la zona DNS interna y las redes privadas indicadas. Todos los demás destinos deben utilizar el proxy:

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }

  var isIPv4Literal = /^\d{1,3}(\.\d{1,3}){3}$/.test(host);
  if (isIPv4Literal && (
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))) {
    return "DIRECT";
  }

  return "PROXY fw01.corp.example:3128";
}

Se adaptan .corp.example, las redes privadas y el FQDN del proxy al entorno propio. No todas las redes RFC1918 tienen que ser accesibles internamente. Es más limpio mantener una lista de los dominios y redes internos realmente necesarios.

El ejemplo no llama deliberadamente a dnsResolve() para nombres de host públicos. Estas funciones PAC provocan resoluciones DNS adicionales en el cliente y pueden retrasar el procesamiento; aquí el proxy resuelve los nombres externos. Los nombres internos se clasifican mediante las reglas de dominio o, si la solicitud contiene una dirección IPv4 directa, mediante isInNet(). Si un entorno requiere excepciones más complejas dependientes de DNS, se planifican individualmente y se prueban con los navegadores utilizados.

El ejemplo no contiene deliberadamente DIRECT después de la instrucción proxy. Un valor de retorno como PROXY fw01.corp.example:3128; DIRECT permite que el tráfico de Internet continúe directamente si falla el proxy. Esto aumenta la disponibilidad, pero evita la Web Policy, la autenticación proxy y el registro proxy. No recomendamos este fallback fail-open para una ruta de seguridad obligatoria.

Las excepciones internas DIRECT también son bypasses. Solo se añaden cuando el destino debe alcanzarse realmente de forma directa y existe otra ruta de control. Los dominios SaaS sensibles, proveedores de identidad o comodines generales no deben añadirse por precaución a la lista de bypass.

Distribuir el archivo PAC de forma controlada

1. Alojar el archivo PAC en un endpoint HTTPS interno con un certificado de confianza.
2. Asegurar que https://config.corp.example/proxy.pac pueda descargarse sin un proxy que ya funcione.
3. Asignar la URL PAC solo al piloto mediante GPO, MDM o una política de navegador administrada.
4. Documentar previamente una configuración proxy manual existente y otras opciones PAC o WPAD.
5. Reiniciar por completo el navegador y las aplicaciones afectadas.
6. Comprobar qué URL PAC se ha cargado realmente en la política del navegador o sistema operativo.
7. Bloquear de forma controlada el acceso directo a Internet fuera de la ruta proxy para el piloto o, al menos, probarlo como bypass.

No se necesita la autodetección WPAD para este procedimiento. Una URL PAC administrada explícita es más fácil de identificar y revertir. SFOS proporciona el listener en este diseño; la distribución, alojamiento y gestión de versiones del archivo PAC siguen siendo tareas de la administración de clientes y servidores web.

Probar Direct Web Proxy

Comprobar el listener y la aplicación de PAC

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

Resolve-DnsName fw01.corp.example
Test-NetConnection fw01.corp.example -Port 3128

DNS debe devolver la dirección prevista del firewall y la prueba TCP debe alcanzar el listener. Una prueba de puerto satisfactoria todavía no demuestra la Web Policy, autenticación, descifrado TLS ni conexión a Internet.

Después se comprueba en el navegador la política proxy o PAC aplicada realmente. Un ajuste local antiguo, un segundo perfil de administración o contenido PAC en caché puede sustituir la configuración esperada.

Validar tráfico permitido y bloqueado

1. Abrir una ventana privada nueva del navegador.
2. Abrir un destino HTTP o HTTPS deliberadamente permitido.
3. Abrir un destino bloqueado deliberadamente por Web_Standard_Pilot.
4. En Log viewer, comprobar la hora, origen, usuario, Web Policy, acción y Firewall Rule ID.
5. Para HTTPS, registrar si la conexión se descifró o se dejó deliberadamente sin descifrar.
6. En Diagnostics > Packet capture, limitar la captura al origen 10.20.30.50, puerto proxy y destino si es necesario.
7. Probar una aplicación sin soporte proxy y confirmar que no se evalúa erróneamente como tráfico proxy.
8. Asignar temporalmente al cliente piloto una copia PAC de prueba con un puerto proxy deliberadamente sin usar y comprobar que el tráfico de Internet falla según lo previsto en lugar de evitar el proxy. Después se restaura la versión PAC de producción.

El éxito no significa solo que se cargue un sitio web. La solicitud debe utilizar la Rule ID y Web Policy esperadas, la prueba de bloqueo debe bloquear realmente y un fallo del proxy debe corresponder al diseño fail-closed elegido.

Comprobar que los servicios de administración no quedan expuestos

Desde el cliente piloto, se prueban las direcciones HTTP y HTTPS conocidas del firewall, en especial:

• WebAdmin
• User Portal
• VPN Portal
• Captive Portal
• otros servicios HTTP/HTTPS locales en la dirección del firewall utilizada

No se pretende forzar un inicio de sesión correcto. La prueba determina si el servicio llega a ser accesible a través del proxy. Si aparece un servicio local no permitido por el diseño de seguridad, se detiene el despliegue. Device Access no puede bloquear posteriormente por portal de destino estas solicitudes HTTP/HTTPS generadas internamente por el proxy.

Separar autenticación, TLS, SD-WAN y HA

La identidad de usuario es un componente independiente

Direct Web Proxy puede utilizarse con o sin identidad de usuario. Según el entorno, los clientes normales pueden usar AD SSO, STAS, Captive Portal u otro método compatible. La configuración proxy por sí sola no autentica a nadie.

Para RDS u otros hosts multiusuario en los que varias personas comparten la misma IP de origen, Per-Connection AD SSO es el procedimiento específico adecuado. Autentica por separado cada conexión proxy HTTP/HTTPS; el tráfico que no pasa por el proxy no recibe esta identidad de usuario.

El descifrado HTTPS requiere una CA de confianza

Scan HTTP and decrypted HTTPS no activa el descifrado. En modo proxy web también se utiliza Decrypt HTTPS during web proxy filtering. La CA distribuida a los clientes debe coincidir exactamente con la CA seleccionada en Web > General settings > HTTPS decryption and scanning.

El despliegue seguro se explica en Introducir correctamente TLS Inspection. Distribuir el certificado CA de Sophos Firewall explica la distribución y comprobación de la CA de nueva firma. Certificate Pinning, almacenes de confianza propios y aplicaciones con un comportamiento TLS inusual requieren pruebas específicas en lugar de una excepción amplia.

Probar SD-WAN y HA por separado

Una SD-WAN Route con los servicios HTTP y HTTPS no coincide con tráfico Direct Proxy en 3128. Se utiliza el puerto proxy real o deliberadamente Any. Source Network e Incoming Interface no coinciden con los reply packets en este caso especial. La ruta de retorno del proxy también necesita al menos un gateway WAN o una ruta estática adecuada. La explicación completa se encuentra en Configurar y probar SD-WAN Routes.

En HA no se debe prometer la continuación sin interrupciones de las sesiones proxy o de autenticación existentes. Después de un failover controlado se crea una conexión nueva del navegador y se vuelven a comprobar el archivo PAC, Rule ID, política y descifrado. Cada nodo almacena los registros del tráfico que ha procesado, por lo que durante el análisis importa el nodo que procesaba el tráfico en el momento del evento.

Diagnóstico sistemático

No se puede acceder al puerto proxy

Se comprueban la respuesta DNS, dirección del firewall, listener, zona del cliente y Web proxy en Device Access. Para una excepción ACL deben coincidir origen, Destination host, servicio, acción y posición. Un ping correcto no demuestra el listener TCP; Test-NetConnection es la comprobación preliminar más precisa.

El navegador accede directamente a Internet

Se comprueban la URL PAC efectiva, contenido del archivo cargado, excepciones locales del navegador y perfiles GPO o MDM adicionales. Un fallback DIRECT después de PROXY crea deliberadamente un bypass cuando no se puede acceder al proxy. Las aplicaciones con una pila de red propia también pueden ignorar la configuración proxy del sistema.

El proxy devuelve el error 407 o solicita credenciales

Es un problema de autenticación, no un fallo del listener. Se comprueban el método de autenticación, detección de usuarios, importación de grupos, compatibilidad del navegador y, cuando corresponda, FQDN/SPN. La regla no debe ampliarse preventivamente a Any solo para evitar la solicitud de credenciales.

El sitio web carga, pero no se aplica la Web Policy

Se comprueban conjuntamente la regla de firewall, orden, origen, servicio 3128, Web Policy seleccionada y Rule ID. Una solicitud proxy correcta puede haber coincidido con otra regla o una más amplia. La prueba controlada de reglas combina Policy Test, Log Viewer y Packet Capture.

HTTPS muestra errores de certificado

Se comprueba si el descifrado está activo, qué CA utiliza el proxy web y si esa CA exacta se encuentra en el almacén de confianza del cliente. Si solo fallan aplicaciones concretas, se investigan Certificate Pinning, un almacén de confianza propio, la versión TLS y una excepción lo más limitada posible.

No funciona una aplicación o puerto de destino concreto

Primero se aclara si la aplicación admite un proxy explícito. Después se comprueban Allowed destination ports, bypasses PAC, DNS y comportamiento TLS. Solo se añade un puerto de destino no estándar para la aplicación concreta y se valida con una solicitud real.

La SD-WAN Route o ruta WAN es inesperada

Se comprueban la coincidencia del servicio con el puerto proxy, Rule ID, gateway WAN, ruta estática y Route Precedence. Source Network e Incoming Interface no son criterios de coincidencia fiables para reply packets del proxy. No se cambia globalmente Route Precedence como primera medida.

Faltan registros o muestran muy poco

Se comprueban Log firewall traffic en la regla y los destinos locales, Central o Syslog en System services > Log settings. awarrenhttp.log es relevante para el proxy web y access_server.log para la autenticación. Servicios y archivos de registro de Sophos Firewall explica la clasificación y recopilación segura.

Reversión y operación

La reversión se prepara antes del piloto:

1. Documentar la configuración proxy, PAC, GPO o MDM anterior.
2. Dar nombres inequívocos a la regla piloto y a la excepción Local Service ACL.
3. Probar la ruta DPI o de firewall directa anterior como vía de retorno.
4. Eliminar la asignación PAC del cliente piloto o restaurar la versión anterior.
5. Reiniciar por completo el navegador y las aplicaciones.
6. Desactivar la regla piloto y probar un flujo web directo real por la ruta de retorno.
7. Eliminar la excepción ACL del piloto y restablecer los permisos temporales amplios de zona para Web proxy a su estado anterior.
8. Comprobar datos en vivo y registros y documentar desde qué momento ya no se espera tráfico proxy.

Durante la operación, el archivo PAC tiene un historial de versiones, un responsable y una fecha de revisión. Cada excepción DIRECT nueva es una excepción de política y debe justificarse, probarse y revisarse posteriormente como una excepción web o de firewall. El listener, puertos de destino permitidos y permisos amplios de zona también forman parte de la revisión periódica.

Lista de comprobación

• Direct Proxy es el modelo adecuado para los navegadores y aplicaciones afectados.
• El cliente piloto IPv4 y la IP de origen fija están documentados.
• El FQDN del proxy, URL PAC y certificados resuelven correctamente.
• El listener y los puertos de destino permitidos son lo más limitados posible.
• Se ha comprobado el permiso amplio de zona del proxy web y se ha sustituido cuando era necesario.
• La excepción Local Service ACL limita el origen y la dirección de destino del firewall.
• La regla de firewall utiliza el puerto proxy, registro y la Web Policy esperada.
• El archivo PAC solo contiene excepciones internas DIRECT justificadas.
• No hay un fallback a Internet que evite el proxy activo sin advertirlo.
• El tráfico real permitido y bloqueado coincide con la Rule ID esperada.
• Se han probado negativamente los servicios HTTP/HTTPS locales del firewall.
• Se han evaluado por separado autenticación, descifrado TLS, QUIC y aplicaciones sin proxy.
• Se ha probado el comportamiento de SD-WAN y HA cuando se utilizan estas funciones.
• Se han documentado reversión, responsable, gestión de versiones y fecha de revisión.

Preguntas frecuentes