Redirección del tráfico de ISE en el switch Catalyst serie 3750

Introducción

En este artículo se describe cómo funciona la redirección del tráfico de usuario y las condiciones necesarias para redirigir el paquete mediante el switch.

Prerequisites

Requirements

Cisco recomienda tener experiencia con la configuración de Cisco Identity Services Engine (ISE) y conocimientos básicos sobre estos temas:

• Implementaciones de ISE y flujos de autenticación web central (CWA)
• Configuración CLI de los switches Cisco Catalyst

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Microsoft Windows 7
• Software de switch Catalyst de Cisco serie 3750X, versiones 15.0 y posteriores
• Software ISE, versiones 1.1.4 y posteriores

Antecedentes

La redirección del tráfico de los usuarios en el switch es un componente fundamental para la mayoría de las implementaciones con ISE. Todos estos flujos implican el uso de la redirección del tráfico por parte del switch:

• CWA
• Aprovisionamiento de clientes (CPP)
• Registro de dispositivos (DRW)
• Aprovisionamiento de suplicante nativo (NSP)
• Gestión de dispositivos móviles (MDM)

La redirección configurada incorrectamente es la causa de varios problemas con la implementación. El resultado típico es un agente de control de admisión a la red (NAC) que no aparece correctamente o la imposibilidad de mostrar el portal de invitados.

Para los escenarios en los que el switch no tiene la misma interfaz virtual del switch (SVI) que la VLAN del cliente, consulte los tres últimos ejemplos.

Troubleshoot

Escenario de prueba

Las pruebas se realizan en el cliente, que se debe redirigir a ISE for provisioning (CPP). El usuario se autentica mediante la omisión de autenticación MAC (MAB) o 802.1x. ISE devuelve el perfil de autorización con el nombre de la lista de control de acceso (ACL) de redirección (REDIRECT_POSTURE) y la URL de redirección (redirige a ISE):

bsns-3750-5#show authentication sessions interface g1/0/2
            Interface:  GigabitEthernet1/0/2
          MAC Address:  0050.5699.36ce
           IP Address:  192.168.1.201
            User-Name:  cisco
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  single-host
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  10
              ACS ACL:  xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
     URL Redirect ACL:  REDIRECT_POSTURE
         URL Redirect:  https://10.48.66.74:8443/guestportal/gateway?sessionId=
                        C0A8000100000D5D015F1B47&action=cpp
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  C0A8000100000D5D015F1B47
      Acct Session ID:  0x00011D90
               Handle:  0xBB000D5E

Runnable methods list:
       Method   State
       dot1x    Authc Success

La ACL descargable (DACL) permite todo el tráfico en esta etapa:

bsns-3750-5#show ip access-lists xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
Extended IP access list xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1 (per-user)
    10 permit ip any any

La ACL de redirección permite este tráfico sin redirección:

• Todo el tráfico a ISE (10.48.66.74)
• Tráfico del sistema de nombres de dominio (DNS) y del protocolo de mensajes de control de Internet (ICMP)

El resto del tráfico debe ser redirigido:

bsns-3750-5#show ip access-lists REDIRECT_POSTURE
Extended IP access list REDIRECT_POSTURE
    10 deny ip any host 10.48.66.74 (153 matches)
    20 deny udp any any eq domain
    30 deny icmp any any (10 matches)
    40 permit tcp any any eq www (78 matches)
    50 permit tcp any any eq 443

El switch tiene una SVI en la misma VLAN que el usuario:

interface Vlan10
 ip address 192.168.1.10 255.255.255.0

En las siguientes secciones, se modifica para presentar el impacto potencial.

El tráfico no alcanza la ACL de redirección

Cuando intenta hacer ping en cualquier host, debe recibir una respuesta porque ese tráfico no se redirige. Para confirmar, ejecute este debug:

debug epm redirect

Para cada paquete ICMP enviado por el cliente, los debugs deben presentar:

Jan 9 09:13:07.861: epm-redirect:IDB=GigabitEthernet1/0/2: In
epm_host_ingress_traffic_qualify ...
Jan 9 09:13:07.861: epm-redirect:epm_redirect_cache_gen_hash:
IP=192.168.1.201 Hash=562
Jan 9 09:13:07.861: epm-redirect:IP=192.168.1.201: CacheEntryGet Success
Jan 9 09:13:07.861: epm-redirect:IP=192.168.1.201: Ingress packet on
[idb= GigabitEthernet1/0/2] didn't match with [acl=REDIRECT_POSTURE]

Para confirmar, examine la ACL:

bsns-3750-5#show ip access-lists REDIRECT_POSTURE
Extended IP access list REDIRECT_POSTURE
    10 deny ip any host 10.48.66.74 (153 matches)
    20 deny udp any any eq domain
    30 deny icmp any any (4 matches)
    40 permit tcp any any eq www (78 matches)
    50 permit tcp any any eq 443

El tráfico alcanza la ACL de redirección

Situación 1: el host de destino está en la misma VLAN, existe y es SVI 10 UP

Cuando inicia el tráfico a la dirección IP que es directamente de Capa 3 (L3) accesible por el switch (la red para el switch tiene una interfaz SVI), esto es lo que sucede:

1. El cliente inicia una solicitud de resolución del Protocolo de resolución de direcciones (ARP) para el host de destino (192.168.1.20) en la misma VLAN y recibe una respuesta (el tráfico ARP nunca se redirige).
   
   
2. El switch intercepta esa sesión, incluso cuando la dirección IP de destino no está configurada en ese switch. El protocolo de enlace TCP entre el cliente y el switch ha finalizado. En esta etapa, no se envían otros paquetes fuera del switch. En este escenario, el cliente (192.168.1.201) ha iniciado una sesión TCP con el otro host que existe en esa VLAN (192.168.1.20) y para el cual el switch tiene una interfaz SVI UP (con la dirección IP 192.168.1.10):
   
   

   

   
   
   
3. Una vez establecida la sesión TCP y enviada la solicitud HTTP, el switch devuelve la respuesta HTTP con la redirección a ISE (encabezado Location).
   
   Estos pasos son confirmados por los debugs. Hay varios aciertos de ACL:
   
   

   epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2]
   matched with [acl=REDIRECT_POSTURE]
   epm-redirect:Fill in URL=https://10.48.66.74:8443/guestportal/gateway?sessionId=
   C0A8000100000D5D015F1B47&action=cpp for redirection
   epm-redirect:IP=192.168.1.201: Redirect http request to https:
   //10.48.66.74:8443/guestportal/gateway?sessionId=C0A8000100000D5D015F1B47&action=cpp
   epm-redirect:EPM HTTP Redirect Daemon successfully created

   
   
   Esto también se puede confirmar con depuraciones más detalladas:
   
   

   debug ip http all
   
   http_epm_http_redirect_daemon: got redirect request
   HTTP: token len 3: 'GET'
   http_proxy_send_page: Sending http proxy page
   http_epm_send_redirect_page: Sending the Redirect page to ...

   
   
   
4. El cliente se conecta directamente a ISE (sesión de Secure Sockets Layer (SSL) a 10.48.66.74:8443). Este paquete no activa la redirección:
   
   

   epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2] didn't
   match with [acl=REDIRECT_POSTURE]

   
   
   

   Nota: el switch intercepta la sesión y, por tanto, el tráfico se puede capturar en el switch con la captura de paquetes integrada (EPC). La captura anterior se realizó con EPC en el switch.

Situación 2: el host de destino está en la misma VLAN, no existe y es SVI 10 UP

Si el host de destino 192.168.1.20 está inactivo (no responde), el cliente no recibe una respuesta ARP (el switch no intercepta ARP) y el cliente no envía un TCP SYN. La redirección nunca se produce.

Esta es la razón por la que el agente NAC utiliza un gateway predeterminado para una detección. Un gateway predeterminado siempre debe responder y activar las redirecciones.

Situación 3: el host de destino se encuentra en una VLAN diferente, existe y es SVI 10 UP

Esto es lo que sucede en este escenario:

1. El cliente intenta acceder a HTTP://8.8.8.8.
   
   
2. Esa red no está en ninguna SVI del switch.
3. El cliente envía un TCP SYN para esa sesión al gateway predeterminado 192.168.1.10 (dirección MAC de destino conocida).
   
   
4. La redirección se activa exactamente de la misma manera que en el primer ejemplo.
   
   
5. El switch intercepta esa sesión y devuelve una respuesta HTTP que redirige al servidor ISE.
   
   
6. El cliente accede al servidor ISE sin problemas (ese tráfico no se redirige).

Nota: no importa si la puerta de enlace predeterminada está en el mismo switch o en un dispositivo ascendente. Solo es necesario recibir una respuesta ARP de ese gateway para activar el proceso de redirección. Además, es necesario que se permita la accesibilidad de ISE a través del gateway predeterminado. Preste especial atención si hay un firewall en el parche, especialmente si se trata de un firewall de capa 2 (L2) y los paquetes de capa 2 atraviesan diferentes enlaces (puede que sea necesario omitir el estado TCP en el firewall).

Situación 4: el host de destino se encuentra en una VLAN diferente, no existe y es SVI 10 UP

Este escenario es exactamente el mismo que el escenario 3. No importa si el host de destino en una VLAN remota existe o no.

Situación 5: el host de destino se encuentra en una VLAN diferente, existe y es SVI 10 DOWN

Si el switch no tiene SVI UP en la misma VLAN que el cliente, todavía puede realizar la redirección pero solo cuando se cumplan condiciones específicas.

El problema para el switch es cómo devolver la respuesta al cliente desde una SVI diferente. Es difícil determinar qué dirección MAC de origen debe utilizarse.

El flujo es diferente de cuando SVI está ACTIVO:

1. El cliente envía un TCP SYN al host en una VLAN diferente (192.168.2.20) con una dirección MAC de destino configurada en una gateway predeterminada que se define en el switch ascendente. Ese paquete alcanza la ACL de redirección, que se muestra mediante depuraciones.
2. El switch verifica si tiene un ruteo de regreso al cliente. Recuerde que el SVI 10 está INACTIVO.
3. Si el switch no tiene otra SVI que tenga un enrutamiento de vuelta al cliente, ese paquete no se intercepta ni se redirige, incluso cuando los registros de Enterprise Policy Manager (EPM) indican que se ha alcanzado la ACL. El host remoto puede devolver un SYN ACK, pero el switch no tiene un ruteo de regreso al cliente (VLAN10) y descarta el paquete. El paquete no puede ser conmutado nuevamente (L2), porque alcanzó la ACL de redirección.
4. Si el switch tiene un ruteo a la VLAN del cliente a través de una SVI diferente, intercepta ese paquete y realiza la redirección de la manera habitual. La respuesta con redirección URL no va directamente al cliente, sino a través de un switch/router diferente basado en la decisión de ruteo.

Observe la asimetría aquí:

• El tráfico recibido del cliente es interceptado localmente por el switch.
  
  
• La respuesta para eso, que incluye la redirección HTTP, se envía a través del switch ascendente basado en el ruteo.
  
  
• Esto ocurre cuando se pueden producir problemas típicos con el firewall y se requiere un desvío de TCP.
  
  
• El tráfico a ISE, que no se redirige, es simétrico. Sólo la redirección en sí es asimétrica.

Situación 6: el host de destino se encuentra en una VLAN diferente, no existe y es SVI 10 DOWN

Este escenario es exactamente el mismo que el escenario 5. No importa que exista el host remoto. El ruteo correcto es lo importante.

Situación 7: el servicio HTTP no funciona

Como se presenta en la situación 6, el proceso HTTP en el switch desempeña un papel importante. Si el servicio HTTP está inhabilitado, EPM muestra que el paquete alcanza la ACL de redirección:

epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2] matched
with [acl=REDIRECT_POSTURE]

Sin embargo, la redirección nunca se produce.

El servicio HTTPS del switch no es necesario para una redirección HTTP, pero sí lo es para la redirección HTTPS. El agente de NAC puede utilizar ambos para la detección de ISE. Por lo tanto, se recomienda habilitar ambos.

Redirección de ACL: Protocolos y puerto incorrectos, sin redirección

Observe que el switch sólo puede interceptar tráfico HTTP o HTTPS que funcione en los puertos estándar (TCP/80 y TCP/443). Si HTTP/HTTPS funciona en un puerto no estándar, se puede configurar con el comando ip port-map http. Además, el switch debe tener su servidor HTTP de escucha en ese puerto (ip http port).

Información Relacionada

• Ejemplo de Configuración de Autenticación Web Central con un Switch y Identity Services Engine
• Guía de usuario de Cisco Identity Services Engine, versión 1.2
  
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones