GETVPN mit TrustSec-SGT-Inline-Tagging und SGT-basierter zonenbasierter Firewall - Konfigurationsbeispiel

Einführung

In diesem Artikel wird erläutert, wie Sie GETVPN so konfigurieren, dass Richtlinien durchgestellt werden, die das Senden und Empfangen von SGT (Security Group Tag) in verschlüsselte Pakete ermöglichen. Beispiel: Zwei Zweigstellen kennzeichnen den gesamten Datenverkehr mit spezifischen SGT-Tags und wenden ZBF-Richtlinien (Zone Based Firewall) auf Basis empfangener SGT-Tags an.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Grundkenntnisse der IOS CLI-Konfiguration (Command Line Interface) und GETVPN-Konfiguration
• Grundkenntnisse der TrustSec-Dienste.
• Grundkenntnisse zonenbasierter Firewall

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

• Cisco 2921 Router mit Software 15.3(2)T und neueren Versionen

Topologie

R3 - Grenzrouter in Branch1, GETVPN-Gruppenmitglied

R4 - Border Router in Branch2, GETVPN-Gruppenmitglied

R1,R2 - GETVPN-Schlüsselserver in der Zentrale

OSPF wird auf allen Routern ausgeführt

Von KS gesendete ACL erzwingt Verschlüsselung für Datenverkehr zwischen 10.0.0.0/16 <-> 10.0.0.0/16

Der R3-Router markiert den gesamten von Zweigstelle1 gesendeten Datenverkehr mit dem SGT-Tag = 3.

Der R4-Router markiert den gesamten von Zweigstelle2 gesendeten Datenverkehr mit dem SGT-Tag = 4.

R3 entfernt SGT-Tags, wenn Datenverkehr an LAN gesendet wird (Annahme, dass R5 Inline-Tagging nicht unterstützt)

R4 entfernt SGT-Tags, wenn Datenverkehr an das LAN gesendet wird (Annahme, dass R6 Inline-Tagging nicht unterstützt)

R4 hat keine Firewall (akzeptiert alle Pakete)

R3 ist mit ZBF konfiguriert und umfasst die folgenden Richtlinien:

- Annahme des gesamten Datenverkehrs vom LAN zum WAN

- Nur ICMP-markiert mit SGT=4 vom WAN zum LAN

Konfiguration

R1 (Schlüsselserver in Zentrale)

Um Richtlinien zum Senden und Empfangen getaggter Pakete zu senden, muss der Befehl "tac cts sgt" vorhanden sein:

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

Die Konfiguration für R2 ist sehr ähnlich.

R3 (Gruppenmitglied in Zweigstelle1)

Die GETVPN-Konfiguration entspricht der Konfiguration für Szenarien ohne SGT-Tags. Die LAN-Schnittstelle wurde mit manueller TrustSec konfiguriert:

• "policy static sgt 3 Trusted" - kennzeichnet alle vom LAN empfangenen Pakete mit SGT=3
• "no propagate sgt" - Entfernt alle SGT-Tags, wenn die Pakete an das LAN übertragen werden

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

ZBF-Konfiguration auf R3:

Alle Pakete aus dem LAN werden akzeptiert. Aus dem WAN werden nur ICMP-Pakete akzeptiert, die mit SGT=4 gekennzeichnet sind:

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 in Branch2-Konfiguration ist sehr ähnlich, mit Ausnahme von ZBF, das dort nicht konfiguriert ist.

Konfiguration R5, R6

R5 und R6 simulieren lokales LAN in beiden Zweigstellen. Beispielkonfiguration für 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

Überprüfung

Tesing SGT-fähiges GETVPN

Überprüfen, ob SGT-Tagging für Gruppenmitglieder in Zweigstelle1 (R3) unterstützt wird:

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

Überprüfen, ob TEK-Richtlinien an Gruppenmitglieder in Zweigstelle1 (R3) weitergeleitet werden und SGT verwenden:

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

Senden von ICMP-Datenverkehr von R6 an 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

Überprüfen, ob R3 verschlüsselte Pakete mit dem SGT-Tag verbindet:

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

Überprüfen von Datenaplane-Zählern für GETVPN auf Gruppenmitglied in Zweigstelle2 (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    

Je nach Plattform können mithilfe von Debuggen weitere Details angezeigt werden. Beispiel für R3:

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

Pakete, die von R3 aus dem LAN empfangen werden, müssen mit einem SGT-Tag versehen sein:

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]

Außerdem werden verschlüsselte Pakete, die über den Tunnel gesendet werden, mit einem Tag versehen:

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

Testen der SGT-fähigen ZBF

R3 akzeptiert nur ICMP-Pakete, die mit SGT=4 markiert sind und vom WAN kommen. Beim Senden von ICMP-Paketen von R6 an 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 empfängt getaggte ESP-Pakete und entschlüsselt sie. Anschließend nimmt die ZBF den Datenverkehr an:

*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

Außerdem zeigt die Richtlinienzuordnung die Zähler mit der Anzahl der akzeptierten Pakete an:

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

Beim Telnet-Versuch von R6 zu R5 wird das durch R3 verworfen, da Telnet nicht zulässig ist:

*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 

Referenzen

• Konfigurationsanleitung für Cisco TrustSec-Switches: Cisco TrustSec im Überblick
• Konfigurieren eines externen Servers für die Benutzerautorisierung der Sicherheitsappliance
• Konfigurationsleitfaden für die CLI der Cisco ASA-Serie 9.1
• Cisco Identity Services Engine-Benutzerhandbuch, Version 1.2
• Technischer Support und Dokumentation - Cisco Systems