Sesión WCCP al router/switch activo, pero no se está navegando debido a problemas de ruta

Pregunta:

Sesión WCCP al router/switch activo, pero no se está navegando debido a problemas de ruta

Entorno:

Dispositivo de seguridad web de Cisco
Switch Catalyst, router, ASA

Síntomas:

La sesión WCCP está activa y funcionando pero la navegación no funciona.

En determinadas circunstancias, el dispositivo de seguridad Cisco Web Security Appliance puede comunicarse con el router, pero es posible que el tráfico del cliente no pase. Veríamos que la sesión WCCP está activa pero todavía no se está realizando ninguna exploración.

La configuración de WCCP en el switch Catalyst es mínima (la lista de redirección no es relevante para esta discusión, pero se reproduce aquí para lograr la integridad):

ip wccp 91 redirect-list 130 group-list 30

interface Vlan20
description client vlan 20
IP address 192.168.20.1 255.255.255.0
ip wccp 91 redirect in

access-list 30 permit 10.66.71.17
access-list 130 permit ip any host 192.168.20.103 log
access-list 130 permit ip host 192.168.20.103 any log

Veríamos que WCCP está funcionando:

Switch#sh ip wccp 91 d
Información del cliente WCCP:

        ID de cliente WCCP: 10.66.71.17
        Versión del protocolo: 2.0
        Estado: utilizable       
        Redirección: L2
        Devolución de paquetes: L2
        Paquetes redirigidos: 0
        Hora de conexión: 00:12:49
        Asignación: MÁSCARA

Pero la navegación podría no ocurrir.

El problema radica en la configuración de la ruta en el dispositivo de seguridad Cisco Web Security Appliance. Por ejemplo, es posible que Cisco Web Security Appliance no tenga una ruta para volver a VLAN 20. La configuración de la ruta sin funcionamiento es la siguiente:

El problema suele verse si sólo se utiliza una interfaz (M1) para el dispositivo de seguridad Cisco Web Security Appliance tanto para el tráfico de datos como para la gestión. En el ejemplo anterior, tenemos una ruta a VLAN 30 a través de la segunda entrada y una ruta al dispositivo WCCP a través de la tercera entrada y una ruta predeterminada a 10.66.71.1 para todas las demás redes. Sin embargo, si 10.66.71.1 es el gateway a Internet pero no sabe cómo rutear a 192.168.20.0/24, el ruteo fallaría y los exploradores del cliente no podrán navegar.

Una simple prueba de ping mostraría si tenemos una ruta de regreso al cliente.

s650a.lab (SERVICE)> ping 192.168.20.103

Pulse Ctrl-C para detener.
PING 192.168.20.103 (192.168.20.103): 56 bytes de datos
^C— estadísticas ping 192.168.20.103 —
17 paquetes transmitidos, 0 paquetes recibidos, 100% de pérdida de paquetes

La solución a este problema es agregar una ruta en Cisco Web Security Appliance de nuevo a las VLAN del cliente.  Esto se puede lograr mediante:

WebUI > Red > Ruta > Agregar ruta 

Después de agregar esto, los pings deben fluir desde el dispositivo de seguridad Cisco Web Security Appliance al cliente y debemos ver que se está navegando en los clientes en la VLAN 20 (host 192.168.20.103 en este ejemplo).

s650a.lab (SERVICE)> ping 192.168.20.103

Pulse Ctrl-C para detener.PING 192.168.20.103 (192.168.20.103): 56 bytes de datos
64 bytes de 192.168.20.103: icmp_seq=0 ttl=127 tiempo=0,835 ms
64 bytes de 192.168.20.103: icmp_seq=1 ttl=127 tiempo=0,343 ms

^C— estadísticas ping 192.168.20.103 —
2 paquetes transmitidos, 2 paquetes recibidos, pérdida de paquetes al 0%
ida y vuelta mín./media/máx./stddev = 0,343/0,589/0,835/0,246 ms

Tenga en cuenta que se muestra repitiendo que esta es una de las razones por las que podría fallar la exploración. Podría haber otras razones por las que WCCP estaría activo pero la navegación no funcionaría, pero este es uno de los problemas más comunes.