Ejemplo de Configuración de GETVPN con Etiquetado en Línea TrustSec SGT y Firewall Basado en Zona SGT

Introducción

En este artículo se explica cómo configurar GETVPN para aplicar políticas que permitan enviar y recibir la etiqueta de grupo de seguridad (SGT) insertada en los paquetes cifrados. El ejemplo implicará que dos sucursales etiqueten todo el tráfico con etiquetas SGT específicas y apliquen políticas de firewall basado en zonas (ZBF) basadas en etiquetas SGT recibidas.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico de la configuración de la interfaz de línea de comandos (CLI) de IOS y de la configuración de GETVPN
• Conocimiento básico de los servicios Trustsec.
• Conocimiento básico del firewall basado en zonas

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• Router Cisco 2921 con software 15.3(2)T y posterior

Topología

R3: router de borde en Branch1, miembro del grupo GETVPN

R4: router de borde en la sucursal 2, miembro del grupo GETVPN

R1,R2: servidores GETVPN Key en el sitio central

OSPF en ejecución en todos los routers

ACL impulsada desde el KS obligando al cifrado para el tráfico entre 10.0.0.0/16 <-> 10.0.0.0/16

El router R3 está etiquetando todo el tráfico enviado desde la sucursal1 con la etiqueta SGT = 3

El router R4 está etiquetando todo el tráfico enviado desde la sucursal2 con la etiqueta SGT = 4

R3 está eliminando las etiquetas SGT al enviar tráfico hacia LAN (suponiendo que R5 no soporta el etiquetado en línea)

R4 está eliminando las etiquetas SGT al enviar tráfico hacia LAN (suponiendo que R6 no soporta el etiquetado en línea)

R4 no tiene firewall (acepta todos los paquetes)

R3 se configura con ZBF con las siguientes políticas:

- aceptación de todo el tráfico de LAN hacia WAN

- aceptación sólo de ICMP etiquetado con SGT=4 de WAN hacia LAN

Configuración

R1 (Servidor de claves en el sitio central)

Para enviar políticas que permitan enviar y recibir paquetes etiquetados, el comando "tac cts sgt" debe estar presente:

interface Loopback0
 ip address 10.0.1.1 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

crypto ipsec transform-set TS esp-aes esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS 
!
crypto gdoi group group1
 identity number 1
 server local
  rekey authentication mypubkey rsa GETKEY
  rekey transport unicast
  sa ipsec 1
   profile prof1
   match address ipv4 GET-IPV4
   replay counter window-size 64
   tag cts sgt
  address ipv4 192.168.0.1
  redundancy
   local priority 100
   peer address ipv4 192.168.0.2

router ospf 1
 network 10.0.0.0 0.0.255.255 area 0
 network 192.168.0.0 0.0.0.255 area 0

ip access-list extended GET-IPV4
 permit icmp 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

La configuración para R2 es muy similar.

R3 (Miembro del grupo en la sucursal1)

La configuración de GETVPN es la misma que para el escenario sin etiquetas SGT. La interfaz LAN se ha configurado con trustsec manual:

• "policy static sgt 3 trust" - etiqueta todos los paquetes recibidos de la LAN usando SGT=3
• "no propagate sgt": elimina todas las etiquetas SGT al transmitir los paquetes hacia la LAN

crypto gdoi group group1
 identity number 1
 server address ipv4 192.168.0.1
 server address ipv4 192.168.0.2
!
!
crypto map cmap 10 gdoi 
 set group group1

interface Ethernet0/0
 ip address 192.168.0.3 255.255.255.0
 crypto map cmap
!
interface Ethernet0/1
 ip address 10.0.3.1 255.255.255.0
cts manual 
   no propagate sgt
   policy static sgt 3 trusted

router ospf 1
 network 10.0.0.0 0.0.255.255 area 0
 network 192.168.0.0 0.0.0.255 area 0

Configuración de ZBF en R3:

Se aceptarán todos los paquetes de LAN. Desde la WAN sólo se aceptarán los paquetes ICMP etiquetados con SGT=4:

class-map type inspect match-all TAG_4_ICMP
match security-group source tag 4
 match protocol icmp
!
policy-map type inspect FROM_LAN
 class class-default
  pass log
policy-map type inspect FROM_WAN
 class type inspect TAG_4_ICMP
  pass log
 class class-default
  drop log
!
zone security lan
zone security wan
zone-pair security WAN-LAN source wan destination lan
 service-policy type inspect FROM_WAN
zone-pair security LAN-WAN source lan destination wan
 service-policy type inspect FROM_LAN

interface Ethernet0/0
 zone-member security wan
!
interface Ethernet0/1
 zone-member security lan

R4 en la configuración de la sucursal 2 es muy similar excepto ZBF que no está configurado ahí.

Configuración R5, R6

R5 y R6 simula la LAN local en ambas sucursales. Ejemplo de configuración para R5:

interface Ethernet0/0
 ip address 10.0.3.10 255.255.255.0
router ospf 1
 network 10.0.0.0 0.0.255.255 area 0

Verificación

Prueba de GETVPN con detección de SGT

Comprobación de si el etiquetado SGT es compatible con el miembro del grupo en la sucursal1 (R3):

R3#show crypto gdoi feature cts-sgt 
       Version    Feature Supported
        1.0.8           Yes

Comprobando si las políticas TEK enviadas a miembro del grupo en la sucursal1 (R3) utilizan SGT:

R3#show crypto gdoi          
GROUP INFORMATION

<...some output ommited for clarity...>

TEK POLICY for the current KS-Policy ACEs Downloaded:
  Ethernet0/0:
    IPsec SA:
        spi: 0xD100D58E(3506492814)
        transform: esp-aes esp-sha256-hmac 
        sa timing:remaining key lifetime (sec): expired
        Anti-Replay(Counter Based) : 64
        tag method : cts sgt
        alg key size: 16 (bytes)
        sig key size: 32 (bytes)
        encaps: ENCAPS_TUNNEL

    IPsec SA:
        spi: 0x52B3CA86(1387514502)
        transform: esp-aes esp-sha256-hmac 
        sa timing:remaining key lifetime (sec): (1537)
        Anti-Replay(Counter Based) : 64
        tag method : cts sgt
        alg key size: 16 (bytes)
        sig key size: 32 (bytes)
        encaps: ENCAPS_TUNNEL

Envío de tráfico ICMP de R6 a R5:

R6#ping 10.0.3.10 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.0.3.10, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/1/6 ms

Comprobando si R3 está conectando la etiqueta SGT a los paquetes cifrados:

R3#show crypto ipsec sa detail 

interface: Ethernet0/0
    Crypto map tag: cmap, local addr 192.168.0.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/1/0)
   remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/1/0)
   Group: group1
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 39, #pkts encrypt: 39, #pkts digest: 39
    #pkts decaps: 39, #pkts decrypt: 39, #pkts verify: 39
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts tagged (send): 39, #pkts untagged (rcv): 39

    <...some output ommited for clarity...>

Verificación de los contadores de plano de datos para GETVPN en miembro del grupo en la sucursal2 (R3):

R3#show crypto gdoi gm dataplane counters 

Data-plane statistics for group group1:
    #pkts encrypt            : 53       #pkts decrypt            : 53   
    #pkts tagged (send)      : 53       #pkts untagged (rcv)     : 53   
    #pkts no sa (send)       : 0        #pkts invalid sa (rcv)   : 0    
    #pkts encaps fail (send) : 0        #pkts decap fail (rcv)   : 0    
    #pkts invalid prot (rcv) : 0        #pkts verify fail (rcv)  : 0    
    #pkts not tagged (send)  : 0        #pkts not untagged (rcv) : 0    
    #pkts internal err (send): 0        #pkts internal err (rcv) : 0    

Dependiendo de la plataforma, se pueden revelar más detalles mediante depuraciones. Por ejemplo en R3:

R3#debug cts platform l2-sgt rx 
R3#debug cts platform l2-sgt tx 

Los paquetes recibidos por R3 de LAN deben etiquetarse con SGT:

01:48:08: cts-l2sgt_rx:l2cts-policysgt:[in=Ethernet0/1 src=0100.5e00.0005 dst=aabb.cc00.6800] Policy SGT Assign [pak=F1B00E00:flag=0x1:psgt=3]

También se etiquetarán los paquetes cifrados enviados a través del túnel:

01:49:28: cts_ether_cmd_handle_post_encap_feature:pak[36BF868]:size=106 in=Ethernet0/1 out=Ethernet0/0 enctype=1 encsize=0 sgt_offset=18 [adj]:idb=Ethernet0/0 is_dot1q=0 linktype=7 mac_length=22 SGT=3

Prueba de ZBF que reconoce SGT

R3 aceptará solamente los paquetes ICMP etiquetados con SGT=4 que vienen de la WAN. Al enviar paquetes ICMP de R6 a R5:

R6#ping 10.0.3.10 repeat 11
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.3.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/6 ms

R3 recibirá el paquete ESP etiquetado y lo descifrará. A continuación, ZBF aceptará el tráfico:

*Mar 17 12:45:28.039: %FW-6-PASS_PKT: (target:class)-(WAN-LAN:TAG_4_ICMP) Passing icmp pkt 10.0.4.10:0 => 10.0.3.10:0 with ip ident 57

También policy-map presentará los contadores con los números de paquete aceptado:

R3#show policy-firewall stats all
Global Stats:
        Session creations since subsystem startup or last reset 0
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:0:0]
        Last session created never
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 0
        Last half-open session total 0

policy exists on zp WAN-LAN
  Zone-pair: WAN-LAN 

  Service-policy inspect : FROM_WAN

    Class-map: TAG_4_ICMP (match-all)  
      Match: security-group source tag 4
      Match: protocol icmp
      Pass
        18 packets, 1440 bytes

    Class-map: class-default (match-any)  
      Match: any 
      Drop
        3 packets, 72 bytes

policy exists on zp LAN-WAN
  Zone-pair: LAN-WAN 

  Service-policy inspect : FROM_LAN

    Class-map: class-default (match-any)  
      Match: any 
      Pass
        18 packets, 1440 bytes

Al intentar telnet de R6 a R5 - esto será descartado por R3 porque no se permitió telnet:

*Mar 17 12:49:30.475: %FW-6-DROP_PKT: Dropping tcp session 10.0.4.10:37500 10.0.3.10:23 on zone-pair WAN-LAN class class-default due to  DROP action found in policy-map with ip ident 36123 

Referencias

• Guía de configuraicón del Switch Cisco TrustSec Comprensión Cisco TrustSec
• Configuración de un servidor externo para la autorización de usuario de dispositivo de seguridad
• Guía de configuración CLI VPN Cisco Serie ASA, 9.1
• Guía de usuario de Cisco Identity Services Engine, versión 1.2
• Soporte Técnico y Documentación - Cisco Systems