Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Topologia

Configuração

R1 (Servidor-chave no site central)

R3 (Membro do Grupo na Filial1)

Configuração de R5, R6

Verificação

Testando GETVPN com reconhecimento de SGT

Testando ZBF sensível a SGT

Referências

Discussões relacionadas da comunidade de suporte da Cisco

Introduction

Este artigo mostrará como configurar o GETVPN para enviar e receber políticas que permitam enviar e receber a Security Group Tag (SGT) inserida em pacotes criptografados. O exemplo envolverá duas filiais que marcaram todo o tráfego com marcas SGT específicas e aplicam políticas de firewall baseado em zona (ZBF - Zone Based Firewall) com base em marcas SGT recebidas.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Conhecimento básico da configuração da interface de linha de comando (CLI) do IOS e da configuração de GETVPN

- Conhecimento básico dos serviços Trustsec.

- Conhecimento básico do firewall baseado em zona

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

- Roteador Cisco 2921 com software 15.3(2)T e mais recente

Topologia

R3 - roteador de borda em Branch1, membro do grupo GETVPN

R4 - roteador de borda na Filial2, membro do grupo GETVPN

R1,R2 - Servidores de Chave GETVPN no Site Central

OSPF em execução em todos os roteadores

ACL enviada do KS forçando a criptografia para o tráfego entre 10.0.0.0/16 <-> 10.0.0.0/16

O roteador R3 está marcando todo o tráfego enviado de Branch1 com tag SGT = 3

O roteador R4 está marcando todo o tráfego enviado da Filial2 com tag SGT = 4

R3 está removendo as tags SGT ao enviar tráfego para a LAN (supondo que R5 não esteja suportando marcação em linha)

O R4 está removendo tags SGT ao enviar tráfego para a LAN (supondo que o R6 não esteja suportando marcação em linha)

R4 não tem firewall (aceitando todos os pacotes)

R3 está configurado com ZBF com as seguintes políticas:

- aceitar todo o tráfego da LAN para a WAN

- aceitar apenas ICMP marcado com SGT=4 da WAN para a LAN

Configuração

R1 (Servidor-chave no site central)

Para enviar políticas que permitam enviar e receber pacotes marcados, o comando "tac cts sgt" precisa 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

A configuração de R2 é muito semelhante.

R3 (Membro do Grupo na Filial1)

A configuração de GETVPN é a mesma do cenário sem tags SGT. A interface de LAN foi configurada com confiabilidade manual:

- "policy static sgt 3 trust" - marca todos os pacotes recebidos da LAN usando SGT=3

- "no propagate sgt" - remove todas as marcas SGT ao transmitir os pacotes para a 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

Configuração de ZBF em R3:

Todos os pacotes da LAN serão aceitos. Somente da WAN os pacotes ICMP marcados com SGT=4 serão aceitos:

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

A configuração de R4 em Branch2 é muito semelhante, exceto ZBF que não está configurado lá.

Configuração de R5, R6

R5 e R6 simulam a LAN local em ambas as filiais. Exemplo de configuração 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

Verificação

Testando GETVPN com reconhecimento de SGT

Verificando se a marcação SGT é suportada no membro do grupo em Branch1 (R3):

R3#show crypto gdoi feature cts-sgt

Version    Feature Supported

1.0.8           Yes

Verificando se as políticas TEK enviadas para o membro do grupo em Branch1 (R3) estão usando 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

Enviando tráfego ICMP de R6 para 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

Verificando se R3 está anexando a tag SGT a pacotes criptografados:

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...>

Verificando contadores de painel de dados para GETVPN no membro do grupo em Branch2 (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

Dependendo da plataforma, mais detalhes podem ser revelados usando depurações. Por exemplo em R3:

R3#debug cts platform l2-sgt rx

R3#debug cts platform l2-sgt tx

Os pacotes recebidos por R3 da LAN devem ser marcados com 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]

Além disso, os pacotes criptografados enviados pelo túnel serão marcados:

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

Testando ZBF sensível a SGT

R3 aceitará somente pacotes ICMP marcados com SGT=4 provenientes da WAN. Ao enviar pacotes ICMP de R6 para 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 receberá o pacote ESP marcado, descriptografando-o. Em seguida, o ZBF aceitará o tráfego:

*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

Além disso, o mapa de políticas apresentará aos contadores os números de pacotes aceitos:

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

Ao tentar executar telnet de R6 para R5 - isso será descartado por R3 porque telnet não foi permitido:

*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

Referências

- Guia de configuração de switches com Cisco TrustSec: Noções básicas sobre o Cisco TrustSec

- Como configurar um servidor externo para autorização de usuário de dispositivo de segurança

- Guia de configuração de CLI para VPN da Cisco ASA Series, 9.1

- Manual do usuário do Cisco Identity Services Engine, versão 1.2

- Suporte Técnico e Documentação - Cisco Systems