Erreurs 502 / 504 GATEWAY_TIMEOUT lors de la navigation vers certains sites

Si le serveur Web ne répond pas aux paquets SYN du WSA, après un certain nombre de tentatives, le client reçoit une erreur 502 Gateway Timeout.

Causes typiques de ce problème :
 1. Le serveur Web ou le réseau du serveur Web rencontre des problèmes.
 2. Un problème réseau sur le réseau WSA empêche les paquets SYN d’accéder à Internet.
 3. Un pare-feu ou un périphérique similaire abandonne les paquets SYN WSA ou le paquet SYN/ACK du serveur Web
 4. L’usurpation d’adresse IP est activée sur le WSA, mais n’est pas correctement configurée (pas de redirection du chemin de retour)

Étapes de dépannage :

La première étape consiste à vérifier si l’appareil de sécurité Web peut envoyer une requête ping ICMP au serveur Web. Pour ce faire, utilisez la commande CLI suivante :

WSA> ping www.example.com

Si la requête ping échoue, cela ne signifie pas que le serveur est hors service. Cela peut signifier que les paquets ICMP sont bloqués quelque part sur le chemin. Si la requête ping aboutit, nous pouvons être sûrs que le WSA a un niveau de connectivité de couche 3 de base au serveur Web.

Un test Telnet permet de vérifier si l’appareil de sécurité Web est en mesure d’établir une connexion TCP sur le port 80 vers le serveur Web. Reportez-vous aux instructions de cet article pour effectuer un test Telnet.

Problèmes réseau ou blocage du pare-feu

Si la requête ping aboutit, mais que la connexion Telnet échoue, il est fort possible qu’un périphérique de filtrage, tel qu’un pare-feu, empêche ce trafic de traverser le réseau. Il est recommandé d'analyser les journaux de pare-feu et/ou les captures de paquets du pare-feu pour obtenir plus de détails.

Activation de l'usurpation IP, mais configuration incorrecte

Si le proxy explicite via le WSA ou le test Telnet est réussi, cela montre que le WSA peut communiquer directement avec le serveur Web, mais quand un client effectue un proxy via le WSA avec l'usurpation d'adresse IP, il y a un problème.

Sans usurpation IP du client :

• L’appareil de sécurité Web envoie un SYN au serveur Web en utilisant sa propre adresse IP comme source. Lorsque le paquet revient, il est transmis directement à l’appareil de sécurité Web.

Avec usurpation IP client :

• L’appareil de sécurité Web envoie le SYN, mais utilise plutôt l’adresse IP du client comme source. Sans configuration réseau spéciale, le paquet de retour sera envoyé au client au lieu du WSA.
• Afin d'utiliser l'usurpation d'adresse IP du client, le réseau doit être configuré de manière très spécifique afin de faciliter la redirection correcte des paquets. Si les paquets de chemin de retour du serveur Web sont envoyés au client au lieu du WSA, le WSA ne verra jamais les serveurs SYN/ACK et enverra une erreur 502 Gateway Timeout au client.

 Si le WSA reçoit un paquet de réinitialisation TCP sur sa connexion en amont au serveur Web, le WSA enverra une erreur 504 Gateway Timeout au client.
 

Causes typiques de ce problème :
 1. Cisco Layer 4 Traffic Monitor (L4TM) empêche le proxy WSA de se connecter au serveur Web.
 2. Un pare-feu, un système IDS, un système IPS ou un autre dispositif d’inspection de paquets bloque l’appareil de sécurité Web. 
 
Étapes de dépannage :

Déterminez tout d'abord si le RST TCP provient de L4TM ou d'un autre périphérique.

Si L4TM bloque ce trafic, il s'affiche dans les rapports de l'interface utilisateur sous "Monitor -> L4 Traffic Monitor". Sinon, la TVD provient d'un autre périphérique.

Blocage L4TM :

Il est recommandé que si L4TM bloque, ne bloquez pas les ports sur lesquels le proxy WSA est également en cours d'exécution. Il y a plusieurs raisons à cela :

1. Le proxy WSA fournit un message d’erreur convivial en cas de problème, au lieu de simplement réinitialiser la connexion via TCP. Cela permettra de limiter la confusion des utilisateurs finaux lorsqu'ils sont bloqués.
2. Le proxy WSA peut analyser et bloquer du contenu spécifique, tandis que L4TM bloque tout le trafic correspondant à une adresse IP sur liste noire.

Afin de configurer L4TM pour ne pas bloquer sur les ports proxy, allez à "GUI -> Security Services -> L4 Traffic Monitor".

Si le site est un site Web inapproprié connu, mais qu'il existe des raisons pour lesquelles le trafic doit être autorisé, le site peut être répertorié en blanc dans :
"GUI -> Web Security Manager -> Moniteur de trafic de couche 4 -> Liste d'autorisation"

Pare-feu / IDS / Blocage IPS :

Si un autre périphérique du réseau empêche le WSA de se connecter au serveur Web, il est recommandé d'analyser les éléments suivants :

1. Journaux de blocage du pare-feu
2. Captures de paquets en entrée/sortie pendant le problème

Les journaux de blocage peuvent rapidement confirmer si le périphérique bloque le WSA. Parfois, un pare-feu, IPS ou IDS bloque le trafic et NE le consigne PAS correctement. Si c'est le cas, la seule façon de prouver d'où vient la RST TCP est d'obtenir des captures d'entrée et de sortie du périphérique. Si un RST est envoyé par l'interface d'entrée et qu'aucun paquet n'est passé par le côté de sortie, le périphérique de sécurité est certainement la cause.

Si le WSA envoie une requête HTTP GET, mais ne reçoit jamais de réponse, il envoie une erreur 504 Gateway Timeout au client.

Causes typiques de ce problème :

• Un pare-feu, un système IDS, un système IPS ou tout autre dispositif d’inspection de paquets autorise la connexion TCP, mais empêche le contenu HTTP d’atteindre le serveur Web. Dans ce cas, le test telnet peut aider à isoler le type de données HTTP bloquées.

Les journaux de blocage du pare-feu peuvent rapidement confirmer si / pourquoi le périphérique bloque le WSA. Parfois, un pare-feu, IPS ou IDS bloque le trafic et NE le consigne PAS correctement. Si c'est le cas, la seule façon de prouver d'où vient la RST TCP est d'obtenir des captures d'entrée et de sortie du périphérique. Si un RST est envoyé par l'interface d'entrée et qu'aucun paquet n'est passé par le côté de sortie, le périphérique de sécurité est certainement la cause.

 À partir de l'interface de ligne de commande WSA, exécutez la commande telnet :

WSA> telnet

Sélectionnez l'interface à partir de laquelle vous souhaitez établir une connexion Telnet.
1. Auto
2. Gestion (192.168.15.200/24 : wsa.hostname.com)
3. P1 (192.168.113.199/24: data.com)
[1]> 3

Saisissez le nom d'hôte distant ou l'adresse IP.
[]> www.example.com

Saisissez le port distant.
[25]> 80

Essai de 10.3.2.99...
Connecté à www.example.com.
Le caractère d'échappement est '^]'.

Remarque: le message « Connected » (Connecté) en rouge indique que le protocole TCP a été correctement établi entre le WSA et le serveur Web.

Une requête HTTP peut également être envoyée manuellement via cette session Telnet. Voici un exemple de requête qui peut être tapé après le message « Connected » :

-------------------------------------------------------------------------------------

OBTENEZ http://www.example.com HTTP/1.1
HÔTE : www.example.com
{Saisissez }
-------------------------------------------------------------------------------------

Remarque : veillez à ajouter le retour chariot supplémentaire à la fin, sinon le serveur ne répondra pas à la demande.