Cisco Cisco Web Security Appliance S670 Troubleshooting Guide
If the web server does not respond to the WSA's SYN packets, after a certain amount of attempts, the client
will be sent a 502 Gateway Timeout error.
will be sent a 502 Gateway Timeout error.
Typical causes for this are:
1. The web server or web server network is having issues.
2. A network issue on the WSA network is preventing the SYN packets from getting to the Internet.
3. A firewall or similar device is dropping either the WSA SYN packets or the web server's SYN/ACK
4. IP spoofing is enabled on the WSA, but is not properly configured (no return path redirection)
2. A network issue on the WSA network is preventing the SYN packets from getting to the Internet.
3. A firewall or similar device is dropping either the WSA SYN packets or the web server's SYN/ACK
4. IP spoofing is enabled on the WSA, but is not properly configured (no return path redirection)
Troubleshooting steps:
The first step is to verify if the WSA can ICMP ping the web server. This can be done by using the following
CLI command:
CLI command:
WSA> ping www.example.com
If the ping fails, it does not mean that the server is down. It may mean that ICMP packets are getting blocked
somewhere in the path. If the ping succeeds, then we can know for sure that the WSA has a basic layer3 level
of connectivity to the web server.
somewhere in the path. If the ping succeeds, then we can know for sure that the WSA has a basic layer3 level
of connectivity to the web server.
A telnet test will verify if the WSA has the ability to establish a TCP connection on port 80 to the web server.
See the instructions further in this article for performing a telnet test.
See the instructions further in this article for performing a telnet test.
Network issues or Firewall block
If the ping is successful, but the telnet fails, there is a good possibility that a filtering device, such as a
firewall, is preventing this traffic from getting through the network. It is recommended that the firewall logs
and/or packet captures from the firewall are analyzed for further details.
firewall, is preventing this traffic from getting through the network. It is recommended that the firewall logs
and/or packet captures from the firewall are analyzed for further details.
IP Spoofing enable, but not properly configured
If explicitly proxying through the WSA or the telnet test is successful, this shows that the WSA can
communicate directly to the web server, but when a client proxies through the WSA with IP spoofing, there is
a problem.
communicate directly to the web server, but when a client proxies through the WSA with IP spoofing, there is
a problem.
Without client IP spoofing:
The WSA sends a SYN to the web server using its own IP address as the source. When the packet
comes back, it goes directly to the WSA.
comes back, it goes directly to the WSA.
•
With client IP spoofing:
The WSA sends the SYN, but instead, uses the client's IP as the source. Without a special network
setup, the return packet will be sent to the client instead of the WSA.
setup, the return packet will be sent to the client instead of the WSA.
•
In order to use client IP spoofing, the network must be configured in a very specific way in order to
facilitate that the packets are redirected properly. If the web server return path packets are being sent
to the client instead of the WSA, the WSA will never see the servers SYN/ACK and will send a 502
Gateway Timeout error back to the client.
facilitate that the packets are redirected properly. If the web server return path packets are being sent
to the client instead of the WSA, the WSA will never see the servers SYN/ACK and will send a 502
Gateway Timeout error back to the client.
•