Le proxy explicite ne fonctionne pas avec le routage avancé. Ce problème devrait normalement être résolu depuis la version 11.1.5, mais nous le rencontrons toujours avec la version 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
• Routage avancé
• Proxy explicite
• proxy DNS
• Multivsys sans communication inter-vsys.
• La itinéraire de service DNS est configurée pour utiliser l' interface d'un autre vsys.

L'enquête a révélé que la cause principale du problème résidait dans une itinéraire de service DNS mal configurée. Cette itinéraire de service était configurée pour utiliser une interface spécifique (`ae10.xx`) sur un vsys différent de celui sur lequel l' interface du service proxy DNS était configurée, ce qui empêchait le proxy DNS de générer des requêtes DNS vers les serveurs DNS . Par conséquent, le pare-feu était incapable de résoudre les requêtes DNS générées par les interfaces hôtes et les clients, ce qui entraînait un blocage du trafic réseau vers les serveurs DNS configurés dans le proxy DNS.

**PLAN_DE_REMÉDIATION**
1. Analyse de la configuration du client et comparaison avec la configuration de laboratoire : la configuration de la itinéraire de service DNS était différente. Dans l'environnement de laboratoire, la itinéraire de service était configurée via l' interface« mgmt » ; dans l'environnement du client, elle utilisait « ae10.xx » sur un vsys différent de celui où le proxy DNS était configuré. Cette incompatibilité de configuration a été identifiée comme la cause principale.
2. Modification de la configuration de la itinéraire de service DNS pour garantir que la itinéraire de service utilise la bonne interface vsys
3. Reconfiguration de la itinéraire de service de destination personnalisée pour DNS afin d'utiliser l' interface« ae3.xx », permettant au proxy DNS de recevoir des requêtes DNS des interfaces hôtes et des clients.
4. Vérification de la résolution réussie du problème dans l’environnement de laboratoire après le changement de configuration .
5. Suite à la vérification en laboratoire, nous avons conseillé au client d'appliquer la même modification dans son environnement et de vérifier que le problème de résolution DNS est résolu. Cela implique les actions suivantes :

• Modifiez la configuration de itinéraire de service pour que DNS utilise l' interface appropriée.
• Assurez-vous que la itinéraire de service est dirigée vers la bonne interface vsys (ae3.xx).
• Vérifiez que l' interface d'écoute du proxy DNS est configurée sur le même vsys.
• Testez la fonctionnalité de résolution DNS pour vous assurer qu'elle fonctionne correctement.
• Vérifiez que les sites Web sont accessibles via l'eProxy sans autres problèmes.