Explicit Proxy funktioniert nicht in Kombination mit erweitertem Routing. Dieses Problem sollte normalerweise seit 11.1.5 behoben sein, tritt aber auch in 11.1.6 weiterhin auf.

? 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
• Erweitertes Routing
• Expliziter Proxy
• DNS -Proxy
• Multivsys ohne übergreifende VSYS-Kommunikation.
• Die DNS Dienstroute ist so konfiguriert, dass sie die Schnittstelle eines anderen vsys verwendet.

Untersuchungen ergaben, dass die Ursache des Problems in einer falsch konfigurierten DNS Dienstroute lag. Die Dienstroute war so konfiguriert, dass sie eine bestimmte Schnittstelle (ae10.xx) auf einem anderen vsys als der DNS -Proxy- Schnittstelle verwendete. Dies führte dazu, dass der DNS Proxy keine DNS Abfragen an die DNS Server generieren konnte. Infolgedessen konnte die Firewall die von den Hostschnittstellen und Clients generierten DNS Abfragen nicht auflösen, wodurch der Netzwerkverkehr zu den im DNS-Proxy konfigurierten DNS-Servern umgeleitet wurde.

**SANIERUNGSPLAN**
1. Analyse der Konfiguration und Vergleich mit der Konfiguration . Dabei wurde festgestellt, dass die Dienstroute für DNS unterschiedlich war. In der Laborumgebung wurde die Dienstroute über die Schnittstelle„mgmt“ konfiguriert; in der Kundenumgebung wurde „ae10.xx“ auf einem anderen vsys verwendet als der DNS Proxy. Diese Konfiguration wurde als Grundursache identifiziert.
2. Ändern der DNS Dienstroute , um sicherzustellen, dass die Dienstroute die richtige vsys Schnittstelle verwendet
3. Neukonfigurieren der benutzerdefinierten Destination für DNS zur Verwendung der Schnittstelle „ae3.xx “ , sodass der DNS -Proxy DNS Anfragen von Hostschnittstellen und Clients empfangen kann.
4. Überprüfen der erfolgreichen Lösung des Problems in der Laborumgebung nach der Konfiguration .
5. Nach der erfolgreichen Laborüberprüfung wurde dem Kunden empfohlen, die gleiche Änderung in seiner Umgebung vorzunehmen und zu überprüfen, ob das Problem mit der DNS Auflösung behoben ist. Dies sollte die folgenden Schritte umfassen:

• Ändern Sie die Dienstroute für DNS , um die entsprechende Schnittstelle zu verwenden.
• Stellen Sie sicher, dass die Dienstroute auf die richtige vsys Schnittstelle (ae3.xx) gerichtet ist.
• Überprüfen Sie, ob die DNS Proxy- Schnittstelle auf demselben vsys konfiguriert ist.
• Testen Sie die DNS Auflösungsfunktion, um sicherzustellen, dass sie ordnungsgemäß funktioniert.
• Überprüfen Sie, ob über den eProxy ohne weitere Probleme auf Websites zugegriffen werden kann.