502 / 504 Errores GATEWAY_TIMEOUT al navegar a ciertos sitios

Si el servidor web no responde a los paquetes SYN del WSA, después de una cierta cantidad de intentos, se enviará al cliente un error 502 Gateway Timeout.

Las causas típicas de esto son:
 1. El servidor web o la red del servidor web está teniendo problemas.
 2. Un problema de red en la red WSA impide que los paquetes SYN lleguen a Internet.
 3. Un firewall o un dispositivo similar está descartando los paquetes SYN de WSA o el SYN/ACK del servidor web
 4. La suplantación de IP está habilitada en el WSA, pero no está configurada correctamente (no hay redirección de ruta de retorno)

Pasos para la resolución de problemas:

El primer paso es verificar si el WSA puede enviar un ping ICMP al servidor web. Esto se puede hacer mediante el siguiente comando de CLI:

WSA> ping www.example.com

Si el ping falla, no significa que el servidor esté inactivo. Puede significar que los paquetes ICMP se están bloqueando en algún lugar del trayecto. Si el ping se realiza correctamente, podemos estar seguros de que el WSA tiene un nivel básico de conectividad de capa 3 con el servidor web.

Una prueba telnet verificará si el WSA tiene la capacidad de establecer una conexión TCP en el puerto 80 al servidor web. Consulte las instrucciones de este artículo para realizar una prueba de Telnet.

Problemas de red o bloqueo de firewall

Si el ping es exitoso, pero el telnet falla, existe una buena posibilidad de que un dispositivo de filtrado, como un firewall, esté impidiendo que este tráfico llegue a través de la red. Se recomienda analizar los registros del firewall o las capturas de paquetes del firewall para obtener más detalles.

Suplantación de IP habilitada, pero no configurada correctamente

Si el proxy explícito a través de WSA o la prueba telnet es exitoso, esto muestra que WSA puede comunicarse directamente con el servidor web, pero cuando un cliente hace proxy a través de WSA con la suplantación de IP, hay un problema.

Sin suplantación de IP de cliente:

• El WSA envía un SYN al servidor Web utilizando su propia dirección IP como origen. Cuando el paquete regresa, va directamente al WSA.

Con la suplantación de IP de cliente:

• El WSA envía el SYN, pero en su lugar, utiliza la IP del cliente como origen. Sin una configuración de red especial, el paquete de retorno se enviará al cliente en lugar del WSA.
• Para utilizar la suplantación de IP de cliente, la red debe configurarse de una manera muy específica para facilitar que los paquetes se redireccionen correctamente. Si los paquetes de ruta de retorno del servidor web se envían al cliente en lugar del WSA, el WSA nunca verá los servidores SYN/ACK y enviará un error 502 Gateway Timeout de vuelta al cliente.

 Si el WSA recibe un paquete de restablecimiento de TCP en su conexión ascendente al servidor web, el WSA enviará un error 504 Gateway Timeout al cliente.
 

Las causas típicas de esto son:
 1. El monitor de tráfico de capa 4 (L4TM) de Cisco está bloqueando la conexión del proxy WSA al servidor web.
 2. Un firewall, IDS, IPS u otro dispositivo de inspección de paquetes está bloqueando el WSA. 
 
Pasos para la resolución de problemas:

Primero determine si el TCP RST proviene de L4TM o de otro dispositivo.

Si el L4TM está bloqueando este tráfico, el tráfico aparecerá en los informes de la GUI bajo "Monitor -> L4 Traffic Monitor". De lo contrario, el RST proviene de un dispositivo diferente.

Bloqueo L4TM:

Se recomienda que si el L4TM está bloqueando, no bloquee en los puertos en los que el proxy WSA también se está ejecutando. Hay varias razones para esto:

1. El proxy WSA proporciona un mensaje de error descriptivo en caso de problema, en lugar de solo TCP restableciendo la conexión. Esto ayudará a limitar la confusión de los usuarios finales cuando se bloquean.
2. El proxy WSA puede analizar y bloquear contenido específico, mientras que el L4TM bloquea todo el tráfico que coincida con una dirección IP de la lista negra.

Para configurar el L4TM para que no bloquee en los puertos proxy, vaya a "GUI -> Servicios de seguridad -> Monitor de tráfico L4".

Si el sitio es un sitio web malintencionado conocido, pero hay razones por las que se debe permitir el tráfico, el sitio puede aparecer en la lista blanca de:
"GUI -> Web Security Manager -> L4 Traffic Monitor -> Allow List"

Firewall / IDS / Bloqueo IPS:

Si otro dispositivo de la red está bloqueando la conexión de WSA al servidor web, se recomienda analizar lo siguiente:

1. Bloqueo de registros del firewall
2. Capturas de paquetes de ingreso/egreso durante el problema

Los registros de bloqueo pueden confirmar rápidamente si el dispositivo está bloqueando el WSA. En ocasiones, un firewall, IPS o IDS bloquearán el tráfico y NO lo registrarán de forma adecuada. Si este es el caso, la única manera de probar de dónde proviene el TCP RST es obtener capturas de ingreso y egreso del dispositivo. Si se envía un RST por la interfaz de ingreso y no se viaja ningún paquete a través del lado de egreso, el dispositivo de seguridad es definitivamente la causa.

Si el WSA envía un HTTP GET, pero nunca recibe una respuesta, enviará un error 504 Gateway Timeout al cliente.

Las causas típicas de esto son:

• Un firewall, IDS, IPS u otro dispositivo de inspección de paquetes permite la conexión TCP, pero bloquea el acceso del contenido HTTP al servidor web. En este caso, la prueba telnet puede ayudar a aislar qué tipo de datos HTTP se están bloqueando.

Los registros de bloques del firewall pueden confirmar rápidamente si el dispositivo está bloqueando el WSA o por qué. En ocasiones, un firewall, IPS o IDS bloquearán el tráfico y NO lo registrarán de forma adecuada. Si este es el caso, la única manera de probar de dónde proviene el TCP RST es obtener capturas de ingreso y egreso del dispositivo. Si se envía un RST por la interfaz de ingreso y no se viaja ningún paquete a través del lado de egreso, el dispositivo de seguridad es definitivamente la causa.

 Desde la CLI de WSA, ejecute el comando telnet:

WSA> Telnet

Seleccione la interfaz desde la que desea establecer telnet.
1. Automático
2. Gestión (192.168.15.200/24: wsa.hostname.com)
3. P1 (192.168.113.199/24: data.com)
[1]> 3

Introduzca el nombre de host remoto o la dirección IP.
[]> www.example.com

Introduzca el puerto remoto.
[25]> 80

Intentando 10.3.2.99...
Conectado a www.example.com.
El carácter de escape es '^]'.

Nota: el mensaje "Connected" (Conectado) en rojo indica que TCP se ha establecido correctamente entre el WSA y el servidor web.

Una solicitud HTTP también se puede enviar manualmente a través de esta sesión telnet. A continuación se muestra un ejemplo de solicitud que se puede escribir después del mensaje "Conectado":

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

OBTENGA http://www.example.com HTTP/1.1
HOST: www.example.com
{Escriba}
-------------------------------------------------------------------------------------

Nota: Asegúrese de agregar el retorno de carro adicional al final; de lo contrario, el servidor no responderá a la solicitud.