Explicit Proxy does not work in combination with advanced routing. This should normally have been resolved since 11.1.5, but we still encounter the issue on 11.1.6.

• 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 upstream
2025/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

• PANOS 11.1.6-hx
• PA-3410
• Advanced Routing
• Explicit proxy
• DNS proxy
• Multivsys with no inter-vsys communication.
• The DNS service route is configured to use the interface from another vsys.

Investigation revealed that the root cause of the issue resided in a misconfigured service route for DNS. The service route was configured to use a specific interface (`ae10.xx`) on a different vsys than where the DNS Proxy service interface was configured, leading to the DNS proxy failing to generate DNS queries toward DNS servers. As a result, the firewall was unable to resolve DNS queries generated from the host interfaces and clients, causing network traffic to get blackholed toward the configured dns servers in the dns proxy.

**REMEDIATION_PLAN**
1. Analyzing the customer's configuration and comparing it to the lab configuration, identifying that the service route configuration for DNS was different. In the lab environment, the service route was configured using the `mgmt` interface; in the customer's environment, it was using `ae10.xx` on a different vsys from where the DNS proxy was configured. This configuration mismatch was identified as the root cause.
2. Modifying the DNS service route configuration to ensure that the service route uses the correct vsys interface
3. Reconfiguring the custom destination service route for DNS to use the `ae3.xx` interface, allowing the DNS proxy to receive DNS requests from host interfaces and clients.
4. Verifying the successful resolution of the issue in the lab environment after the configuration change.
5. Following the successful lab verification, advised the customer to implement the same change in their environment and verify that the DNS resolution issue is resolved. This should involve the following actions:

• Modify the service route configuration for DNS to utilize the appropriate interface.
• Ensure that the service route is directed towards the correct vsys interface (ae3.xx).
• Verify that the DNS proxy listening interface is configured on the same vsys.
• Test the DNS resolution functionality to ensure that it is working correctly. 
• Verify that websites can be accessed through the eProxy without further issues.