安全 : Cisco FlexVPN

与TrustSec SGT轴向标记和SGT意识基于区域的防火墙配置示例的IKEv2

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

本文描述如何使用互联网密钥交换版本2 (IKEv2)和安全组标记(SGT)为了标记发送的数据包到VPN通道。说明包括一典型的部署和用例。本文也解释一SGT意识基于区域的防火墙(ZBF)和存在两个方案:

  • 根据从IKEv2通道接收的SGT标记的ZBF
  • 根据SGT交换协议的ZBF (SXP)映射

所有示例包括数据包级别调试为了验证SGT标记如何传送。

贡献用米哈拉Garcarz, Cisco TAC工程师。

先决条件

要求

Cisco 建议您了解以下主题:

  • TrustSec组件基础知识
  • Cisco Catalyst交换机的命令行界面(CLI)配置基础知识
  • 体验在思科身份服务引擎方面(ISE)的配置
  • 基于区域的防火墙基础知识
  • IKEv2基础知识

使用的组件

本文档中的信息基于以下软件和硬件版本:

  • Microsoft Windows 7和Microsoft Windows XP
  • Cisco Catalyst 3750-X软件版本15.0和以上
  • 思科身份服务引擎软件版本1.1.4和以上
  • Cisco 2901集成业务路由器(ISR)用软件版本15.3(2)T或以上

注意:ISR生成2 (G2)平台只支持IKEv2。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

安全组标记(SGT)

SGT是思科TrustSec解决方案体系结构的一部分,设计使用灵活安全策略没有根据IP地址。

在TrustSec网云的流量用SGT标记分类并且标记。您能建立过滤根据该标记的流量的安全策略。所有策略从ISE在中央manged和被实施到在TrustSec网云的所有设备。

为了通过关于SGT标记的信息,思科修改了以太网帧类似于修改为802.1q标记被做的方式。已修改以太网帧可以由选定Cisco设备仅了解。这是已修改格式:

116499-configure-ikev2-trustsec-01.png

思科元数据(CMD)字段直接地在源MAC地址地址字段(SMAC)或802.1q字段以后插入,如果使用(正如在此示例)。

通过VPN要连接TrustSec网云, IKE的一分机和IPSec协议创建。分机,呼叫IPsec轴向标记,允许在封装安全有效载荷(ESP)数据包将发送的SGT标记。修改ESP有效负载运载在数据包的有效负载的之前一个8字节CMD字段。例如,在互联网发送的已加密互联网控制消息协议(ICMP)数据包包含[IP] [ESP] [CMD] [IP] [ICMP] [DATA]。

详细信息被提交在条款的第二部分

配置

注意

使用命令查找工具仅限注册用户)可获取有关本部分所使用命令的详细信息。

命令输出解释程序工具仅限注册用户)支持某些 show 命令。请使用Output Interpreter Tool为了查看show命令输出分析。

使用 debug 命令之前,请参阅有关 Debug 命令的重要信息

网络图

116499-configure-ikev2-trustsec-02.jpg

通信流

在此网络中, 3750X-5和3750X-6是Catalyst交换机在TrustSec网云里面。两交换机使用设置自动受保护的访问的凭证(PACs)为了加入网云。3750X-5使用了作为种子和3750X-6作为非种子设备。两交换机之间的流量加密与MACsec和正确地被标记。

Windows XP使用802.1x为了访问网络。在成功认证以后, ISE返回为该会话将应用的SGT标记属性。从该PC发出的所有流量用SGT=3标记。

路由器1 (R1)和Router2 (R2)是2901 ISR。由于ISR G2当前不支持SGT标记, R1和R2是在TrustSec网云外面,并且不了解修改与CMD字段为了通过SGT标记的以太网帧。因此, SXP用于为了转发关于IP/SGT映射的信息从3750X-5到R1。

R1有配置保护流量被注定对远程位置的一个IKEv2通道(192.168.100.1),并且有启用的轴向标记。在IKEv2协商以后, R1开始标记ESP发送的数据包到R2。标记根据从3750X-5接收的SXP数据。

R2根据已接收SGT标记收到该流量,并且,可进行ZBF定义的特定操作。

同样在R1可以执行。SXP映射允许R1从根据SGT标记的LAN丢弃接收的数据包,即使不支持SGT帧。

TrustSec Cloud配置

第一步在配置方面将建立TrustSec网云。两3750交换机需要:

  • 获取PAC,使用对TrustSec网云(ISE)的验证。
  • 验证并且通过网络设备准入控制(NDAC)进程。
  • 请使用安全关联协议(SAP)在链路的MACsec协商。

此步骤为此用例是必要的,但是不是必要为了SXP协议能正确地工作。R1不需要从ISE得到PAC或环境数据为了执行SXP映射和IKEv2轴向标记。

验证

3750X-5和3750X-6之间的链路使用802.1x协商的MACsec加密。两交换机委托并且接受对等体接收的SGT标记:

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

应用一基于任务的访问控制表(RBACL)是不可能的直接地在交换机。那些策略在ISE在交换机配置和自动地下载。

客户端配置

客户端能使用802.1x、MAC验证旁路(MAB),或者Web验证。切记配置ISE,以便授权规则的正确安全组返回:

116499-configure-ikev2-trustsec-03.png

验证

验证客户端配置:

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

从这时起,从3750X-5发送的客户端的流量到在TrustSec网云内的其他交换机用SGT=3标记。

参见ASA和Catalyst 3750X系列交换机TrustSec配置示例并且排除故障授权规则示例的指南

在3750X-5和R1之间的SGT交换协议

R1不能加入TrustSec网云,因为它是不了解有CMD字段的以太网帧的一个2901个ISR G2路由器。因此, SXP在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在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

验证

保证R1接收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当前知道应该处理从192.168.2.200接收的所有流量,好象被标记作为SGT=3。

IKEv2在R1和R2之间的配置

这是简单静态虚拟隧道接口(SVTI) -基于方案以IKEv2聪明的默认。预先共享密钥使用验证,并且空加密使用ESP数据包分析方便。所有流量到192.168.100.0/24通过Tunnel1接口发送。

这是在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

在R2,对网络192.168.2.0/24的所有回程数据流通过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

仅一命令在两路由器要求为了启用轴向标记:crypto ikev2 cts sgt命令。

验证

轴向标记需要协商。在第一和第二IKEv2数据包中,特定厂商ID发送:

116499-configure-ikev2-trustsec-04.png

有三供应商ID (VIDs)由Wireshark是未知。他们涉及对:

  • DELETE-REASON,支持用思科
  • FlexVPN,支持用思科
  • SGT轴向taggging

调试验证此。R1,是IKEv2发起者,发送:

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接收第二IKEv2数据包和同样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

因此,两边同意在ESP有效负载的开始放置CMD数据。

检查IKEv2安全关联(SA)为了验证此协议:

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

在它发送从Windows客户端的流量往192.168.100.1后, R1显示:

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#

注意标记信息包被发送了。

对于中转流量,当R1需要标记从Windows客户端发送的流量到R2时,请确认ESP数据包用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

从同样VLAN的其他流量,从交换机来源,默认为SGT=0 :

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

ESP数据包级别验证

请使用嵌入式数据包捕获(EPC)为了查看ESP流量从R1到R2,和显示在此图:

116499-configure-ikev2-trustsec-05.png

Wireshark用于解码安全参数索引的(SPI)空加密。在IPv4报头,源和目的IP是路由器的互联网IP地址(使用作为隧道源及目的地)。

ESP有效负载包括8字节CMD字段,用红色突出显示:

  • 0x04 -下个报头,是IP
  • 0x01 -长度(在报头以后的4个字节,与报头的8个字节)
  • 0x01 -版本01
  • 0x00 -保留
  • 0x00 - SGT长度(4字节总数)
  • 0x01 - SGT类型
  • 0x0003 - SGT标记(最后两个八位位组,是00 03;SGT使用Windows客户端)

因为IPsec IPv4模式使用了隧道接口,下个报头是IP,突出显示以绿色。来源IP是c0 a8 02 c8 (192.168.2.200),并且目的地IP是c0 a8 64 01 (192.168.100.1)。协议号是1,是ICMP。

最后报头是ICMP,用蓝色突出显示,与类型08和代码8 (ECHO请求)。

ICMP有效载荷是下的并且是长32个的字节(即字母从a到i)。在图的有效负载为Windows客户端是典型的。

其余ESP报头跟随ICMP有效载荷:

  • 0x01 0x02 -填充。
  • 0x02 -填充长度。
  • 0x63 -指向协议0x63,是‘所有私有加密机制的下个报头’。这表明下一个字段(ESP数据的第一个字段)是SGT标记。
  • 12字节的总校验值。

CMD字段是在ESP有效负载里面,通常加密。

IKEv2缺陷:GRE或IPSec模式

直到现在,这些示例使用了隧道模式IPsec IPv4。如果使用,什么发生通用路由封装(GRE)模式?

当路由器封装传输IP数据包到GRE时, TrustSec显示数据包,当本地产生-即, GRE数据包的来源是路由器,不是Windows客户端。当CMD字段被添加时,默认标记(SGT=0)总是使用而不是一特定标记。

当流量从Windows客户端(192.168.2.200)时发送模式IPsec IPv4的,您看到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

但是,在隧道模式更改对同样流量的后GRE,您看到SGT=0。在本例中, 192.168.1.20是隧道源IP:

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

注意:因此,不使用GRE是非常重要的。

请参阅Cisco Bug ID CSCuj25890, IOS IPSec轴向标记关于GRE模式:插入路由器军士。当您使用GRE时,此bug创建为了允许适当的SGT传播。

根据从IKEv2的SGT标记的ZBF

这是ZBF配置示例在R2的。与SGT=3的VPN流量可以识别,因为从IKEv2通道接收的所有信息包是标记为的(即他们包含CMD字段)。因此, 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_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

验证

当对192.168.100.1的一ping从Windows客户端(SGT=3)来源,调试显示此:

*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

对于从交换机的ping (SGT=0)来源,调试显示此:

*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

从R2的防火墙统计信息是:

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

有四丢包(Windows发送的ICMP回音默认号码),并且五接受(交换机的默认号码)。

根据SGT映射的ZBF通过SXP

从LAN运行SGT意识ZBF在R1和对接收的过滤数据流是可能的。虽然不是SGT被标记的该流量, R1有SXP映射信息,并且能处理该流量如被标记。

在本例中,策略使用在LAN和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

验证

当ICMP回音从Windows客户端时发送,您能看到丢包:

*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

由于SXP会话根据TCP,您能通过在3750X-5和R2之间的一个IKEv2通道也建立SXP会话和运用根据在R2的标记的ZBF策略,不用轴向标记。

规划图

轴向标记ISR G2和Cisco ASR 1000系列汇聚服务路由器也支持GET VPN。ESP数据包有一其他CMD字段的8个字节。

动态多点VPN (DMVPN)的支持也计划。

欲知更多信息,请参阅思科TrustSec启用的基础设施模式。

验证

验证程序在配置示例内包括。

故障排除

目前没有针对此配置的故障排除信息。

相关信息


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 116499