Sécurité : Cisco FlexVPN

IKEv2 avec l'étiquetage d'en ligne de TrustSec SGT et l'exemple basé sur zone SGT-averti de configuration de Pare-feu

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment employer la version 2 (IKEv2) d'échange de clés Internet (IKE) et une balise de groupe de sécurité (SGT) afin d'étiqueter des paquets envoyés à un tunnel VPN. La description inclut un déploiement et un cas d'utilisation typiques. Ce document explique également un Pare-feu basé sur zone SGT-averti (ZBF) et des présents deux scénarios :

  • Un ZBF qui est basé sur des balises SGT a reçu du tunnel IKEv2
  • Un ZBF qui est basé sur le mappage du protocole d'échange SGT (SXP)

Tous les exemples incluent le niveau de paquet met au point afin de vérifier comment la balise SGT est transmise.

Contribué par Michal Garcarz, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Connaissance de base des composants de TrustSec
  • Connaissance de base de la configuration de l'interface de ligne de commande (CLI) des commutateurs Cisco Catalyst
  • Expérience de configuration d'un Logiciel Cisco Identity Services Engine (ISE)
  • Connaissance de base de Pare-feu basé sur zone
  • Connaissance de base d'IKEv2

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Microsoft Windows 7 et Microsoft Windows XP
  • Version de logiciel 15.0 et ultérieures de Cisco Catalyst 3750-X
  • Version 1.1.4 et ultérieures de Cisco Identity Services Engine Software
  • Routeur à services intégrés Cisco 2901 (ISR) avec la version de logiciel 15.3(2)T ou ultérieures

Remarque: IKEv2 est seulement pris en charge sur des Plateformes de la génération 2 ISR (G2).

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Balise de groupe de sécurité (SGT)

Le SGT fait partie de l'architecture de solution de Cisco TrustSec, qui est conçue pour utiliser les stratégies de sécurité flexibles qui ne sont pas basées sur l'adresse IP.

Le trafic dans le nuage de TrustSec est classifié et identifié par une balise SGT. Vous pouvez établir les stratégies de sécurité qui filtrent le trafic basé sur cette balise. Toutes les stratégies centralement manged de l'ISE et sont déployées vers tous les périphériques dans le nuage de TrustSec.

Afin de passer les informations sur la balise SGT, Cisco a modifié la trame Ethernet semblable à la manière que des modifications ont été apportées pour des balises de 802.1Q. La trame Ethernet modifiée peut être comprise seulement par les périphériques sélectionnés de Cisco. C'est le format modifié :

116499-configure-ikev2-trustsec-01.png

Le champ des méta-données de Cisco (CMD) est inséré directement après que le champ de MAC address de source (SMAC) ou le champ de 802.1Q s'il est utilisé (comme indiqué dans cet exemple).

Pour connecter des nuages de TrustSec par l'intermédiaire du VPN, une extension pour l'IKE et des protocoles IPsecs a été créée. L'extension, appelée IPsec étiquetage intégré, permet des balises SGT à introduire les paquets de Protocole ESP (Encapsulating Security Payload). La charge utile de l'ESP est modifiée pour porter un champ 8-byte CMD juste avant la charge utile du paquet lui-même. Par exemple, le paquet chiffré de Protocole ICMP (Internet Control Message Protocol) envoyé au-dessus de l'Internet contient [IP] [ESP] [CMD] [IP] [ICMP] [DONNÉES].

Les informations détaillées sont présentées dans la deuxième partie de l'article.

Configurez

Notes :

Utilisez l'Outil de recherche de commande (clients enregistrés seulement) pour obtenir plus d'informations sur les commandes utilisées dans cette section.

L'Output Interpreter Tool (clients enregistrés seulement) prend en charge certaines commandes show. Utilisez l'Output Interpreter Tool afin de visualiser une analyse de sortie de commande show.

Référez-vous aux informations importantes sur les commandes de débogage avant d'utiliser les commandes de débogage.

Diagramme du réseau

116499-configure-ikev2-trustsec-02.jpg

La circulation

Dans ce réseau, 3750X-5 et 3750X-6 sont des Commutateurs de Catalyst à l'intérieur du nuage de TrustSec. Les deux Commutateurs emploient le ravitaillement automatique des qualifications de Protected Access (PACs) afin de joindre le nuage. 3750X-5 a été utilisé en tant qu'une graine, et 3750X-6 comme périphérique de non-graine. Le trafic entre les deux Commutateurs est chiffré avec MACsec et est correctement étiqueté.

802.1x d'utilisations de WindowsXP afin d'accéder au réseau. Après l'authentification réussie, l'ISE renvoie l'attribut de balise SGT qui sera appliqué pour cette session. Tous trafiquent originaire de ce PC sont étiquetés avec SGT=3.

Le routeur 1 (R1) et le Router2 (R2) sont 2901 ISR. Puisque l'ISR G2 ne prend en charge pas actuellement SGT étiquetant, R1 et R2 sont en dehors de du nuage de TrustSec et ne comprennent pas les trames Ethernet qui ont été modifiées avec des champs CMD afin de passer les balises SGT. Ainsi, SXP est utilisé afin d'expédier des informations sur le mappage IP/SGT de 3750X-5 à R1.

R1 a un tunnel IKEv2 qui est configuré pour protéger le trafic destiné à un site distant (192.168.100.1) et qui a l'étiquetage d'en ligne activé. Après la négociation IKEv2, les débuts R1 pour étiqueter des paquets de l'ESP ont envoyé à R2. L'étiquetage est basé sur les données SXP reçues de 3750X-5.

R2 peut recevoir ce trafic et, basé sur la balise reçue SGT, peut exécuter des actions spécifiques définies par le ZBF.

Les mêmes peuvent être faits sur R1. Le mappage SXP permet à R1 pour relâcher un paquet reçu du RÉSEAU LOCAL basé sur une balise SGT, même si des trames SGT ne sont pas prises en charge.

Configuration de nuage de TrustSec

La première étape dans la configuration est d'établir un nuage de TrustSec. Le besoin de les deux 3750 Commutateurs :

  • Obtenez un PAC, qui est utilisé pour l'authentification au nuage de TrustSec (ISE).
  • Authentifiez et passez le procédé du contrôle d'admission de périphérique de réseau (NDAC).
  • Utilisez l'association de sécurité Protocol (SAP) pour la négociation de MACsec sur un lien.

Cette étape est nécessaire pour ce cas d'utilisation, mais n'est pas nécessaire pour que le protocole SXP fonctionne correctement. R1 n'a pas besoin d'obtenir un PAC ou des données d'environnement d'ISE afin d'exécuter le mappage SXP et l'étiquetage IKEv2 intégré.

Vérification

Le lien entre 3750X-5 et 3750X-6 utilise le cryptage de MACsec négocié par 802.1x. Les deux Commutateurs font confiance et reçoivent aux balises SGT reçues par le pair :

bsns-3750-5#show cts interface
Global Dot1x feature is Enabled
Interface GigabitEthernet1/0/20:
    CTS is enabled, mode:    DOT1X
    IFC state:               OPEN
    Authentication Status:   SUCCEEDED
        Peer identity:       "3750X6"
        Peer's advertised capabilities: "sap"
        802.1X role:         Supplicant
        Reauth period applied to link:  Not applicable to Supplicant role
    Authorization Status:    SUCCEEDED
        Peer SGT:            0:Unknown
        Peer SGT assignment: Trusted
    SAP Status:              SUCCEEDED
        Version:             2
        Configured pairwise ciphers:
            gcm-encrypt

        Replay protection:      enabled
        Replay protection mode: STRICT

        Selected cipher:        gcm-encrypt

    Propagate SGT:           Enabled
    Cache Info:
        Cache applied to link : NONE

    Statistics:
        authc success:              32
        authc reject:               1543
        authc failure:              0
        authc no response:          0
        authc logoff:               2
        sap success:                32
        sap fail:                   0
        authz success:              50
        authz fail:                 0
        port auth fail:             0

Il n'est pas possible d'appliquer une liste de contrôle d'accès basée sur rôle (RBACL) directement sur des Commutateurs. Ces stratégies sont configurées sur ISE et sont automatiquement téléchargées sur les Commutateurs.

Configuration du client

Le client peut utiliser le 802.1x, le contournement d'authentification MAC (MAB), ou l'authentification Web. Souvenez-vous pour configurer ISE de sorte que le groupe de sécurité correct pour la règle d'autorisation soit retourné :

116499-configure-ikev2-trustsec-03.png

Vérification

Vérifiez la configuration de client :

bsns-3750-5#show authentication sessions interface g1/0/2
            Interface:  GigabitEthernet1/0/2
          MAC Address:  0050.5699.4ea1
           IP Address:  192.168.2.200
            User-Name:  cisco
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  multi-auth
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  20
                  SGT:  0003-0
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  C0A80001000006367BE96D54
      Acct Session ID:  0x00000998
               Handle:  0x8B000637

Runnable methods list:
       Method   State
       dot1x    Authc Success
       mab      Not run

À partir de là, le trafic de client envoyé de 3750X-5 à d'autres Commutateurs dans le nuage de TrustSec est étiqueté avec SGT=3.

Voir l'ASA et l'exemple de configuration de TrustSec de commutateur de gamme du Catalyst 3750X et dépannez le guide pour un exemple des règles d'autorisation.

Protocole d'échange SGT entre 3750X-5 et R1

R1 ne peut pas joindre le nuage de TrustSec parce que c'est un routeur de l'ISR G2 2901 qui ne comprend pas des trames Ethernet avec des champs CMD. Ainsi, SXP est configuré sur le 3750X-5 :

bsns-3750-5#show run | i sxp
cts sxp enable
cts sxp default source-ip 192.168.1.10
cts sxp default password cisco
cts sxp connection peer 192.168.1.20 password default mode local

SXP est également configuré sur R1 :

BSNS-2901-1#show run | i sxp
cts sxp enable
cts sxp default source-ip 192.168.1.20
cts sxp default password cisco
cts sxp connection peer 192.168.1.10 password default mode local listener
hold-time 0 0

Vérification

Assurez-vous que R1 reçoit les informations de mappage IP/SGT :

BSNS-2901-1#show cts sxp sgt-map
SXP Node ID(generated):0xC0A80214(192.168.2.20)
IP-SGT Mappings as follows:
IPv4,SGT: <192.168.2.200 , 3>
source  : SXP;
Peer IP : 192.168.1.10;
Ins Num : 1;
Status  : Active;
Seq Num : 1
Peer Seq: 0

R1 sait maintenant que tout le trafic reçu de 192.168.2.200 devrait être traité comme si il est étiqueté comme SGT=3.

Configuration IKEv2 entre R1 et R2

C'est un scénario basé sur virtuel statique simple des interfaces de tunnel (SVTI) avec les par défaut IKEv2 intelligents. Des clés pré-partagées sont utilisées pour l'authentification, et le cryptage de null est utilisé pour la facilité de l'analyse de paquet de l'ESP. Tout le trafic à 192.168.100.0/24 est envoyé par l'interface Tunnel1.

C'est la configuration sur R1 :

crypto ikev2 keyring ikev2-keyring
 peer 192.168.1.21
  address 192.168.1.21
  pre-shared-key cisco
 !
crypto ikev2 profile ikev2-profile
 match identity remote address 192.168.1.21 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local ikev2-keyring

crypto ipsec transform-set tset esp-null esp-sha-hmac
 mode tunnel
!
crypto ipsec profile ipsec-profile
 set transform-set tset
 set ikev2-profile ikev2-profile

interface Tunnel1
 ip address 172.16.1.1 255.255.255.0
 tunnel source GigabitEthernet0/1.10
 tunnel mode ipsec ipv4
 tunnel destination 192.168.1.21
 tunnel protection ipsec profile ipsec-profile

interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
 ip address 192.168.1.20 255.255.255.0

ip route 192.168.100.0 255.255.255.0 172.16.1.2

Sur R2, tout le trafic de retour au réseau 192.168.2.0/24 est envoyé par l'interface Tunnel1 :

crypto ikev2 keyring ikev2-keyring
 peer 192.168.1.20
  address 192.168.1.20
  pre-shared-key cisco

crypto ikev2 profile ikev2-profile
 match identity remote address 192.168.1.20 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local ikev2-keyring

crypto ipsec transform-set tset esp-null esp-sha-hmac
 mode tunnel

crypto ipsec profile ipsec-profile
 set transform-set tset
 set ikev2-profile ikev2-profile

interface Loopback0
description Protected Network
 ip address 192.168.100.1 255.255.255.0

interface Tunnel1
 ip address 172.16.1.2 255.255.255.0
 tunnel source GigabitEthernet0/1.10
 tunnel mode ipsec ipv4
 tunnel destination 192.168.1.20
 tunnel protection ipsec profile ipsec-profile

interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
 ip address 192.168.1.21 255.255.255.0

ip route 192.168.2.0 255.255.255.0 172.16.1.1

Seulement une commande est exigée sur les deux Routeurs afin d'activer l'étiquetage d'en ligne : la crypto commande du cts sgt ikev2.

Vérification

En ligne étiquetant les besoins d'être négocié. En le premier et deuxième paquet IKEv2, un ID spécifique de constructeur est envoyé :

116499-configure-ikev2-trustsec-04.png

Il y a trois id de constructeur (VIDs) qui sont inconnus par Wireshark. Ils sont liés à :

  • DELETE-REASON, pris en charge par Cisco
  • FlexVPN, pris en charge par Cisco
  • En ligne SGT taggging

Met au point vérifient ceci. R1, qui est un demandeur IKEv2, envoie :

debug crypto ikev2 internal

*Jul 25 07:58:10.633: IKEv2:Construct Vendor Specific Payload: DELETE-REASON
*Jul 25 07:58:10.633: IKEv2:(1): Sending custom vendor id : CISCO-CTS-SGT

*Jul 25 07:58:10.633: IKEv2:Construct Vendor Specific Payload: (CUSTOM)
*Jul 25 07:58:10.633: IKEv2:Construct Vendor Specific Payload: (CUSTOM)

R1 reçoit un deuxième paquet IKEv2 et le même VID :

*Jul 25 07:58:10.721: IKEv2:Parse Vendor Specific Payload: CISCO-DELETE-REASON VID
*Jul 25 07:58:10.721: IKEv2:Parse Vendor Specific Payload: (CUSTOM) VID
*Jul 25 07:58:10.721: IKEv2:Parse Vendor Specific Payload: (CUSTOM) VID
*Jul 25 07:58:10.721: IKEv2:Parse Notify Payload: NAT_DETECTION_SOURCE_IP
NOTIFY(NAT_DETECTION_SOURCE_IP)
*Jul 25 07:58:10.725: IKEv2:Parse Notify Payload: NAT_DETECTION_DESTINATION_IP
NOTIFY(NAT_DETECTION_DESTINATION_IP)

*Jul 25 07:58:10.725: IKEv2:(1): Received custom vendor id : CISCO-CTS-SGT

Ainsi, les deux côtés acceptent de mettre des données CMD au début de la charge utile de l'ESP.

Vérifiez l'association de sécurité IKEv2 (SA) afin de vérifier cet accord :

BSNS-2901-1#show crypto ikev2 sa detailed
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         192.168.1.20/500      192.168.1.21/500      none/none            READY
      Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth
verify: PSK
      Life/Active Time: 86400/225 sec
      CE id: 1019, Session-id: 13
      Status Description: Negotiation done
      Local spi: 1A4E0F7D5093D2B8       Remote spi: 08756042603C42F9
      Local id: 192.168.1.20
      Remote id: 192.168.1.21
      Local req msg id:  2              Remote req msg id:  0
      Local next msg id: 2              Remote next msg id: 0
      Local req queued:  2              Remote req queued:  0
      Local window:      5              Remote window:      5
      DPD configured for 0 seconds, retry 0
      Fragmentation not configured.
      Extended Authentication not configured.
      NAT-T is not detected
      Cisco Trust Security SGT is enabled
      Initiator of SA : Yes

 IPv6 Crypto IKEv2 SA

Après qu'il envoie le trafic du client Windows vers 192.168.100.1, R1 affiche :

BSNS-2901-1#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel1
Uptime: 00:01:17
Session status: UP-ACTIVE
Peer: 192.168.1.21 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 192.168.1.21
      Desc: (none)
  IKEv2 SA: local 192.168.1.20/500 remote 192.168.1.21/500 Active
          Capabilities:(none) connid:1 lifetime:23:58:43
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 4 drop 0 life (KB/Sec) 4227036/3522
        Outbound: #pkts enc'ed 9 drop 0 life (KB/Sec) 4227035/3522


BSNS-2901-1#show crypto ipsec sa detail

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 192.168.1.20

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 192.168.1.21 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #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): 9, #pkts untagged (rcv): 4
    #pkts not tagged (send): 0, #pkts not untagged (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
    #send dummy packets 9, #recv dummy packets 0

     local crypto endpt.: 192.168.1.20, remote crypto endpt.: 192.168.1.21
     plaintext mtu 1454, path mtu 1500, ip mtu 1500, ip mtu idb
GigabitEthernet0/1.10
     current outbound spi: 0x9D788FE1(2641924065)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xDE3D2D21(3728551201)
        transform: esp-null esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2020, flow_id: Onboard VPN:20, sibling_flags 80000040,
crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4227036/3515)
        IV size: 0 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x9D788FE1(2641924065)
        transform: esp-null esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2019, flow_id: Onboard VPN:19, sibling_flags 80000040,
crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4227035/3515)
        IV size: 0 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:
BSNS-2901-1#

Notez que des paquets balisés ont été envoyés.

Pour le trafic de transit, quand R1 doit étiqueter le trafic envoyé du client Windows à R2, confirmez que le paquet de l'ESP a été étiqueté correctement avec SGT=3 :

debug crypto ipsc metadata sgt
*Jul 23 19:01:08.590: IPsec SGT:: inserted SGT = 3 for src ip 192.168.2.200

Autre trafiquent du même VLAN, qui est originaire du commutateur, des par défaut à SGT=0 :

*Jul 23 19:43:08.590: IPsec SGT:: inserted SGT = 0 for src ip 192.168.2.10

Vérification de niveau de paquet de l'ESP

Utilisez la capture incluse de paquet (CPE) afin de passer en revue le trafic de l'ESP de R1 à R2, en tant que le montre la cette figure :

116499-configure-ikev2-trustsec-05.png

Wireshark a été utilisé pour décoder le cryptage nul pour l'index de paramètre de Sécurité (SPI). Dans l'en-tête d'ipv4, l'IP de source et de destination sont les adresses IP d'Internet des Routeurs (utilisés comme source du tunnel et destination).

La charge utile de l'ESP inclut le champ 8-byte CMD, qui est mis en valeur en rouge :

  • 0x04 - Prochaine en-tête, qui est IP
  • 0x01 - Longueur (4 octets après l'en-tête, 8 octets avec l'en-tête)
  • 0x01 - Version 01
  • 0x00 - Réservé
  • 0x00 - Longueur SGT (4 octets se montent)
  • 0x01 - Type SGT
  • 0x0003 - Balise SGT (les deux derniers octets, qui ont 00 03 ans ; SGT est utilisé pour le client Windows)

Puisque le mode d'ipv4 d'IPsec a été utilisé pour l'interface de tunnel, la prochaine en-tête est l'IP, qui est mis en valeur en vert. Le source ip est c0 a8 02 c8 (192.168.2.200), et l'IP de destination est c0 a8 64 01 (192.168.100.1). Le nombre de protocole est 1, qui est ICMP.

La dernière en-tête est ICMP, mis en valeur dans le bleu, avec le type 08 et le code 8 (requête d'écho).

La charge utile d'ICMP est prochaine et est de 32 octets de long (c'est-à-dire, des lettres d'a à i). La charge utile dans la figure est typique pour un client Windows.

Le reste d'en-têtes de l'ESP suivent la charge utile d'ICMP :

  • 0x01 0x02 - Compléter.
  • 0x02 - Compléter la longueur.
  • 0x63 - Prochaine en-tête qui indique le protocole 0x63, qui est « n'importe quelle structure de chiffrement privée. » Ceci indique que le prochain champ (le premier champ dans les données de l'ESP) est la balise SGT.
  • 12 octets de valeur de contrôle d'intégrité.

Le champ CMD est à l'intérieur de la charge utile de l'ESP, qui est généralement chiffrée.

Pièges IKEv2 : Mode GRE ou d'IPsec

Jusqu'ici, ces exemples ont utilisé l'ipv4 d'IPsec de tunnel mode. Que se produisent si le mode d'Encapsulation de routage générique (GRE) est utilisé ?

Quand le routeur encapsule un paquet IP de transit dans GRE, TrustSec visualise le paquet pendant que localement d'origine - c.-à-d., la source du paquet GRE est le routeur, pas le client Windows. Quand le champ CMD est ajouté, la balise par défaut (SGT=0) est toujours utilisée au lieu d'une balise spécifique.

Quand le trafic est envoyé du client Windows (192.168.2.200) dans l'ipv4 d'IPsec de mode, vous voyez SGT=3 :

debug crypto ipsc metadata sgt
*Jul 23 19:01:08.590: IPsec SGT:: inserted SGT = 3 for src ip 192.168.2.200

Mais, après que le tunnel mode soit changé à GRE pour le même trafic, vous voyez que SGT=0. Dans cet exemple, 192.168.1.20 est l'IP de source du tunnel :

*Jul 25 20:34:08.577: IPsec SGT:: inserted SGT = 0 for src ip 192.168.1.20

Remarque: Ainsi, il est très important de ne pas utiliser GRE.

Voir l'ID de bogue Cisco CSCuj25890, en ligne IOS IPSec étiquetant pour le mode GRE : insertion du sergent de routeur. Cette bogue a été créée afin de permettre la propagation appropriée SGT quand vous utilisez GRE.

ZBF basé sur des balises SGT d'IKEv2

C'est un exemple de configuration de ZBF sur R2. Le trafic VPN avec SGT=3 peut être identifié parce que tous les paquets reçus du tunnel IKEv2 sont étiquetés (c'est-à-dire, ils contiennent le champ CMD). Ainsi, le trafic VPN peut être abandonné et connecté :

class-map type inspect match-all TAG_3
 match security-group source tag 3
class-map type inspect match-all TAG_ANY
 match security-group source tag 0
!
policy-map type inspect FROM_VPN
 class type inspect TAG_3
  drop log
 class type inspect TAG_ANY
  pass log
 class class-default
  drop
!
zone security vpn
zone security inside
zone-pair security ZP source vpn destination self
 service-policy type inspect FROM_VPN

interface Tunnel1
 ip address 172.16.1.2 255.255.255.0
 zone-member security vpn

Vérification

Quand un ping à 192.168.100.1 est originaire du client Windows (SGT=3), met au point l'exposition ceci :

*Jul 23 20:05:18.822: %FW-6-DROP_PKT: Dropping icmp session
192.168.2.200:0 192.168.100.1:0 on zone-pair ZP class TAG_3 due to
DROP action
found in policy-map with ip ident 0

Pour un ping qui est originaire d'un commutateur (SGT=0), met au point l'exposition ceci :

*Jul 23 20:05:39.486: %FW-6-PASS_PKT: (target:class)-(ZP:TAG_ANY)
Passing icmp pkt 192.168.2.10:0 => 192.168.100.1:0
with ip ident 0

Les statistiques de Pare-feu de R2 sont :

BSNS-2901-2#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 ZP
  Zone-pair: ZP

  Service-policy inspect : FROM_VPN

    Class-map: TAG_3 (match-all)
      Match: security-group source tag 3
      Drop
        4 packets, 160 bytes

    Class-map: TAG_ANY (match-all)
      Match: security-group source tag 0
      Pass
        5 packets, 400 bytes

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

Il y a quatre gouttes (nombre par défaut d'écho d'ICMP envoyé par Windows) et cinq reçoit (nombre par défaut pour le commutateur).

ZBF basé sur le mappage SGT par l'intermédiaire de SXP

Il est possible d'exécuter ZBF SGT-averti sur R1 et de filtrer le trafic reçu du RÉSEAU LOCAL. Bien que ce trafic ne soit pas SGT étiqueté, R1 a les informations de mappage SXP et peut traiter ce trafic comme étiqueté.

Dans cet exemple, une stratégie est utilisée entre le RÉSEAU LOCAL et les zones VPN :

class-map type inspect match-all TAG_3
 match security-group source tag 3
class-map type inspect match-all TAG_ANY
 match security-group source tag 0
!
policy-map type inspect FROM_LAN
 class type inspect TAG_3
  drop log
 class type inspect TAG_ANY
  pass log
 class class-default
  drop
!
zone security lan
zone security vpn
zone-pair security ZP source lan destination vpn
 service-policy type inspect FROM_LAN

interface Tunnel1
 zone-member security vpn

interface GigabitEthernet0/1.20
 zone-member security lan

Vérification

Quand l'écho d'ICMP est envoyé du client Windows, vous pouvez voir les baisses :

*Jul 25 09:22:07.380: %FW-6-DROP_PKT: Dropping icmp session 192.168.2.200:0
192.168.100.1:0 on zone-pair ZP class TAG_3 due to  DROP action found in
policy-map with ip ident 0

BSNS-2901-1#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 ZP
  Zone-pair: ZP

  Service-policy inspect : FROM_LAN

    Class-map: TAG_3 (match-all)
      Match: security-group source tag 3
      Drop
        4 packets, 160 bytes

    Class-map: TAG_ANY (match-all)
      Match: security-group source tag 0
      Pass
        5 packets, 400 bytes

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

Puisque la session SXP est basée sur le TCP, vous pouvez également établir une session SXP par l'intermédiaire d'un tunnel IKEv2 entre 3750X-5 et R2 et appliquer des stratégies ZBF basées sur les balises sur R2 sans étiquetage intégré.

Feuille de route

OBTENEZ l'étiquetage d'en ligne VPN est également pris en charge sur l'ISR G2 et le Routeurs à services d'agrégation de la gamme Cisco ASR 1000. Le paquet de l'ESP a les 8 octets supplémentaires pour le champ CMD.

Le soutien du VPN multipoint dynamique (DMVPN) est également prévu.

Voyez le pour en savoir plus de feuille de route d'infrastructure TrustSec-activé par Cisco.

Vérifiez

Des procédures de vérification sont incluses dans les exemples de configuration.

Dépannez

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116499