El proxy explícito no funciona con el enrutamiento avanzado. Esto debería haberse solucionado desde la versión 11.1.5, pero aún persiste en la versión 11.1.6.
Symptom
? The customer noticed that pinging the configured DNS server failed, but pinging other hosts worked as expected
? The customer noticed issues with the Secure Web Gateway Proxy when combined with advanced routing, particularly when attempting to access websites
? The customer observed that the issue was similar to a prior support case that was opened on an older software version, where the Advanced Routing support feature for Hybrid SWG was not implemented. Although the issue was reportedly resolved in version 11.1.5, the customer continued to experience it after upgrading to version 11.1.6.
? The customer confirmed that the issue was not related to the proxy's functionality but connected to the DNS resolving process
? The customer identified that the issue originated from the DNS configuration and the firewall's inability to reach the DNS servers
? The customer confirmed that the issue was not related to an incorrect listening interface for the DNS proxy, as the configured interface was deemed appropriate
? The Engineer observed that the firewall exhibited correct behavior when pinging other hosts but experienced a failure when attempting to ping the configured DNS servers.
? The Engineer observed that the firewall could not reach the DNS servers configured in the DNS proxy, including Google's DNS servers
? The Engineer confirmed the issue was independent of the explicit proxy configuration, authentication, decryption, and source NAT rules and their related settings, as these were configured correctly. This issue was related to a different vsys interface used in the service route for DNS. This difference in vsys and interface usage prevented the firewall from reaching the configured DNS proxy server.
? The Engineer observed that the issue was not replicable in the lab environment, indicating the issue was specific to their configuration and possibly tied to a service route mismatch. Upon analysis, it was confirmed that the issue was indeed related to a mismatch in the service route configuration between the customer's environment and the lab.
? The engineer observed that the issue was resolved after changing the service route configuration to utilize the `ae3.461` interface. After this change, the lab environment showed successful ping functionality.
**ERROR_LOGS**
> HTTP/1.1 503 Service Unavailable> no healthy upstream2025/03/23 00:06:38 listen udp v4 socket fd 22 on port 1053.
2025/03/23 00:06:38 listen udp v6 socket fd 23 on port 1053.
2025/04/04 17:20:03 2025-04-04 17:20:03.543 +0200 Error: pan_dnsproxyd_recv_dp_udp_cb(pan_dnsproxy_udp.c:308): [udp]: fd 22 from $ip to $ip process client failed! <<<<<<< fd 22 is the UDP v4 socket to 1053
Environment
- Panorámicas 11.1.6-hx
- PA-3410
- Enrutamiento avanzado
- Proxy explícito
- Proxy DNS
- Multivsys sin comunicación entre los sistemas virtuales.
- La ruta de servicio DNS está configurada para utilizar la interfaz de otro vsys.
Cause
La investigación reveló que la causa del problema residía en una ruta de servicio DNS mal configurada. Esta ruta de servicio estaba configurada para usar una interfaz específica (`ae10.xx`) en un vsys) diferente al de la interfaz del servicio DNS Proxy, lo que provocaba que el proxy DNS no generara consultas DNS hacia los servidores DNS . Como resultado, el cortafuegos no pudo resolver las consultas DNS generadas desde las interfaces del host y los clientes, lo que provocó que el tráfico de red se bloqueara hacia los servidores DNS configurados en el proxy DNS.
Resolution
**PLAN DE REMEDIACIÓN**
1. Se analizó la configuración del cliente y se comparó con la del laboratorio, lo que permitió identificar que la configuración de la ruta de servicio para DNS era diferente. En el entorno de laboratorio, la ruta de servicio se configuró mediante la interfaz`mgmt`; en el entorno del cliente, se utilizaba `ae10.xx` en un vsys diferente al del proxy DNS . Esta discrepancia de configuración se identificó como la causa principal.
2. Modificar la configuración de la ruta de servicio DNS para garantizar que la ruta de servicio utilice la interfaz vsys correcta
3. Reconfigurar la ruta de servicio de destino personalizado para DNS para utilizar la interfaz`ae3.xx`, lo que permite que el proxy DNS reciba solicitudes DNS de las interfaces del host y los clientes.
4. Verificar la resolución exitosa del problema en el entorno de laboratorio después del cambio de configuración .
5. Tras la verificación de laboratorio exitosa, se recomendó al cliente implementar el mismo cambio en su entorno y verificar que el problema de resolución de DNS se haya resuelto. Esto debería implicar las siguientes acciones:
- Modifique la configuración de la ruta de servicio para que DNS utilice la interfaz adecuada.
- Asegúrese de que la ruta de servicio esté dirigida hacia la interfaz vsys correcta (ae3.xx).
- Verifique que la interfaz de escucha del proxy DNS esté configurada en el mismo vsys.
- Pruebe la funcionalidad de resolución de DNS para asegurarse de que funciona correctamente.
- Verifique que se pueda acceder a los sitios web a través del eProxy sin más problemas.