502 / 504 GATEWAY_TIMEOUT-Fehler beim Surfen auf bestimmten Websites

Wenn der Webserver nicht auf die SYN-Pakete der WSA reagiert, wird dem Client nach einer bestimmten Anzahl von Versuchen ein Fehler mit einem Gateway-Timeout von 502 gesendet.

Typische Ursachen hierfür sind:
 1. Probleme mit dem Webserver oder dem Webservernetzwerk.
 2. Ein Netzwerkproblem im WSA-Netzwerk verhindert, dass die SYN-Pakete ins Internet gelangen.
 3. Eine Firewall oder ein ähnliches Gerät verwirft entweder die WSA SYN-Pakete oder die SYN/ACK des Webservers.
 4. IP-Spoofing ist auf der WSA aktiviert, aber nicht richtig konfiguriert (keine Umleitung des Rückgabepfads)

Schritte zur Fehlerbehebung:

Der erste Schritt besteht darin, zu überprüfen, ob die WSA den Webserver ICMP-Ping senden kann. Dies kann mithilfe des folgenden CLI-Befehls durchgeführt werden:

WSA> ping www.example.com

Wenn der Ping fehlschlägt, bedeutet dies nicht, dass der Server ausgefallen ist. Dies kann bedeuten, dass ICMP-Pakete irgendwo im Pfad blockiert werden. Wenn der Ping-Test erfolgreich ist, können wir sicher sein, dass die WSA über eine grundlegende Layer-3-Verbindungsebene mit dem Webserver verfügt.

Bei einem Telnet-Test wird überprüft, ob die WSA in der Lage ist, eine TCP-Verbindung mit Port 80 zum Webserver herzustellen. Anweisungen zur Durchführung eines Telnet-Tests finden Sie weiter unten in diesem Artikel.

Netzwerkprobleme oder Firewall-Block

Wenn der Ping-Test erfolgreich ist, das Telnet jedoch fehlschlägt, ist es gut möglich, dass ein Filtergerät, z. B. eine Firewall, verhindert, dass dieser Datenverkehr durch das Netzwerk geleitet wird. Es wird empfohlen, die Firewall-Protokolle und/oder Paketerfassungen von der Firewall auf weitere Details zu analysieren.

IP-Spoofing aktiviert, aber nicht richtig konfiguriert

Wenn das explizite Proxying über die WSA oder den Telnet-Test erfolgreich ist, zeigt dies, dass die WSA direkt mit dem Webserver kommunizieren kann. Wenn jedoch ein Client über die WSA mit IP-Spoofing einen Proxy sendet, liegt ein Problem vor.

Ohne Client-IP-Spoofing:

• Die WSA sendet ein SYN an den Webserver, wobei sie ihre eigene IP-Adresse als Quelle verwendet. Wenn das Paket zurückkommt, wird es direkt an die WSA weitergeleitet.

Mit Client-IP-Spoofing:

• Die WSA sendet das SYN, verwendet jedoch stattdessen die IP-Adresse des Clients als Quelle. Ohne spezielle Netzwerkkonfiguration wird das Rückgabepaket an den Client anstatt an die WSA gesendet.
• Um Client-IP-Spoofing verwenden zu können, muss das Netzwerk sehr spezifisch konfiguriert werden, damit die Pakete ordnungsgemäß umgeleitet werden können. Wenn die Rückgabepfad-Pakete des Webservers an den Client anstatt an die WSA gesendet werden, sieht die WSA die Server SYN/ACK nie und sendet einen 502 Gateway Timeout-Fehler an den Client zurück.

 Wenn die WSA bei ihrer Upstream-Verbindung zum Webserver ein TCP-Reset-Paket empfängt, sendet die WSA dem Client einen 504-Gateway-Timeout-Fehler.
 

Typische Ursachen hierfür sind:
 1. Die Cisco Layer-4-Datenverkehrsüberwachung (L4TM) blockiert die Verbindung des Webservers mit dem WSA-Proxy.
 2. Eine Firewall, IDS, IPS oder ein anderes Paketprüfgerät blockiert die WSA. 
 
Schritte zur Fehlerbehebung:

Bestimmen Sie zunächst, ob die TCP-RST von L4TM oder einem anderen Gerät stammt.

Wenn L4TM diesen Datenverkehr blockiert, wird der Datenverkehr in den GUI-Berichten unter "Monitor -> L4 Traffic Monitor" (Überwachung -> L4-Datenverkehrsüberwachung) angezeigt. Andernfalls stammt die RST von einem anderen Gerät.

L4TM-Blockierung:

Wenn L4TM blockiert, sollten Ports, auf denen der WSA-Proxy ebenfalls ausgeführt wird, nicht blockiert werden. Hierfür gibt es mehrere Gründe:

1. Der WSA-Proxy liefert im Problemfall eine Fehlermeldung, statt nur die TCP-Verbindung zurückzusetzen. Dies trägt dazu bei, die Verwirrung bei den Endbenutzern zu verringern, wenn sie blockiert werden.
2. Der WSA-Proxy kann spezifische Inhalte scannen und blockieren, während L4TM den gesamten Datenverkehr blockiert, der mit einer IP-Adresse auf der Blacklist übereinstimmt.

Wenn Sie L4TM so konfigurieren möchten, dass keine Proxyports blockiert werden, gehen Sie zu "GUI -> Security Services -> L4 Traffic Monitor".

Wenn es sich bei der Website um eine bekannte schädliche Website handelt, es aber Gründe gibt, warum der Datenverkehr zugelassen werden sollte, kann die Website in folgender Liste als "weiß" gekennzeichnet werden:
"GUI -> Web Security Manager -> L4-Datenverkehrsüberwachung -> Zulassungsliste"

Firewall/IDS/IPS-Blockierung:

Wenn die WSA durch ein anderes Gerät im Netzwerk daran gehindert wird, eine Verbindung zum Webserver herzustellen, wird empfohlen, Folgendes zu analysieren:

1. Firewall-Blockprotokolle
2. Eingangs-/Ausgangspaket wird während des Problems erfasst

Die Blockierungsprotokolle können schnell bestätigen, ob das Gerät die WSA blockiert. Manchmal blockieren Firewalls, IPS oder IDS den Datenverkehr und protokollieren ihn NICHT ordnungsgemäß. In diesem Fall kann nur nachgewiesen werden, woher die TCP-RST stammt, indem Eingangs- und Ausgangserfassungen vom Gerät abgerufen werden. Wenn ein RST über die Eingangsschnittstelle gesendet wird und keine Pakete die Ausgangsseite durchlaufen, ist das Sicherheitsgerät definitiv die Ursache.

Wenn die WSA eine HTTP GET-Anforderung sendet, jedoch keine Antwort erhält, wird dem Client ein Fehler wegen Gateway-Zeitüberschreitung (504 Gateway Timeout) gesendet.

Typische Ursachen hierfür sind:

• Eine Firewall, IDS, IPS oder ein anderes Gerät zur Paketprüfung lässt die TCP-Verbindung zu, blockiert jedoch, dass der HTTP-Inhalt den Webserver erreicht. In diesem Fall kann der Telnet-Test dabei helfen zu isolieren, welche Art von HTTP-Daten blockiert werden.

Die Firewall-Blockierungsprotokolle können schnell bestätigen, ob/warum das Gerät die WSA blockiert. Manchmal blockieren Firewalls, IPS oder IDS den Datenverkehr und protokollieren ihn NICHT ordnungsgemäß. In diesem Fall kann nur nachgewiesen werden, woher die TCP-RST stammt, indem Eingangs- und Ausgangserfassungen vom Gerät abgerufen werden. Wenn ein RST über die Eingangsschnittstelle gesendet wird und keine Pakete die Ausgangsseite durchlaufen, ist das Sicherheitsgerät definitiv die Ursache.

 Führen Sie in der WSA-CLI den Befehl telnet aus:

WSA > Telnet

Wählen Sie die Schnittstelle aus, von der Sie Telnet empfangen möchten.
1. Automatisch
2. Verwaltung (192.168.15.200/24: wsa.hostname.com)
3. P1 (192.168.113.199/24: data.com)
[1]> 3

Geben Sie den Namen oder die IP-Adresse des Remote-Hosts ein.
[]> www.example.com

Geben Sie den Remote-Port ein.
[25]> 80

10.3.2.99 wird versucht...
Verbunden mit www.example.com.
Das Escapezeichen ist '^]'.

Hinweis: Die Meldung "Connected" (Verbunden) in rot zeigt an, dass TCP erfolgreich zwischen der WSA und dem Webserver eingerichtet wurde.

Eine HTTP-Anfrage kann auch manuell über diese Telnet-Sitzung gesendet werden. Nachfolgend finden Sie eine Beispielanforderung, die nach der Meldung "Connected" (Verbunden) eingegeben werden kann:

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

WEITERE INFORMATIONEN UNTER http://www.example.com HTTP/1.1
HOST: www.example.com
{Eingabe}
-------------------------------------------------------------------------------------

Hinweis: Stellen Sie sicher, dass Sie den zusätzlichen Wagenrücklauf am Ende hinzufügen, andernfalls antwortet der Server nicht auf die Anfrage.