セキュリティ : Cisco FlexVPN

TrustSec SGT インライン タギングおよび SGT わかっているゾーン ベースのファイアウォール構成例の IKEv2

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料にインターネット鍵交換 バージョン 2 (IKEv2)を使用する方法を記述され、セキュリティグループ タグ(SGT)は VPN に送信されるパケットをタグ付けするためにトンネル伝送します。 説明は典型的な配備および使用例が含まれています。 この資料はまた SGT わかっているゾーン ベースのファイアウォール(ZBF)および提供を 2 つのシナリオ説明したものです:

  • IKEv2 トンネルから届く SGT タグに基づいている ZBF
  • SGT 交換 プロトコル(SXP)マッピングに基づいている ZBF

すべての例はパケットが水平にします SGT タグがどのように送信されるか確認するためにデバッグを含まれています。

著者:Cisco TAC エンジニア、Michal Garcarz

前提条件

要件

次の項目に関する知識があることが推奨されます。

  • TrustSec コンポーネントの基本的な知識
  • Cisco Catalyst スイッチの Command Line Interface (CLI) 設定の基本的な知識
  • Cisco Identity Services Engine (ISE)の設定のエクスペリエンス
  • ゾーン ベースのファイアウォールの基本的な知識
  • IKEv2 に関する基礎知識

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Microsoft Windows 7 および Microsoft Windows XP
  • Cisco Catalyst 3750-X ソフトウェアリリース 15.0 およびそれ以降
  • Cisco Identity Services Engine ソフトウェアリリース 1.1.4 およびそれ以降
  • ソフトウェア リリース 15.3(2)T または それ 以降が付いている Cisco 2901 統合サービス ルータ(ISR)

: IKEv2 は ISR 世代別 2 (G2)プラットフォームだけでサポートされます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

セキュリティグループ タグ(SGT)

SGT は IP アドレスに基づいていない適用範囲が広いセキュリティポリシーを使用するように設計されている Cisco TrustSec ソリューション アーキテクチャの一部です。

TrustSec クラウドのトラフィックは SGT タグで分類され、マークされます。 そのタグに基づいてトラフィックをフィルタリングするセキュリティポリシーを構築できます。 すべてのポリシーは ISE から中央に manged、TrustSec クラウドのすべてのデバイスに展開されます。

SGT タグについての情報を渡すために、Cisco は修正が 802.1q タグのために行われた方法と同じようなイーサネットフレームを修正しました。 修正されたイーサネットフレームは『Cisco』 を選択 された デバイスによってだけ理解される場合があります。 これは修正された形式です:

116499-configure-ikev2-trustsec-01.png

Cisco メタデータ(CMD)フィールドは送信元MACアドレス フィールド(SMAC)または 802.1q フィールドの後で使用される場合直接挿入されます(次この例)。

TrustSec クラウドを VPN によって接続するために、IKE のための拡張および IPSecプロトコルは作成されました。 IPsec をインライン タギングと呼ばれる拡張は SGT タグが Encapsulating Security Payload (ESP)パケットで送信 されるようにします。 ESP ペイロードはパケットのペイロードの直前の 8 バイト CMD フィールド自体を運ぶために修正されます。 たとえば、インターネットに[IP] [ESP] [CMD] [IP] [ICMP] [DATA]含んでいます送信 される暗号化されたインターネット制御メッセージ プロトコル (ICMP) パケットは。

詳細な情報は技術情報の第 2 一部で提供されます。

設定



このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool登録ユーザ専用)を使用してください。

アウトプット インタープリタ ツール登録ユーザ専用)は、特定の show コマンドをサポートしています。 show コマンド出力の分析を表示するには、アウトプット インタープリタ ツールを使用してください。

debug コマンドを使用する前に、『debug コマンドの重要な情報』を参照してください。

ネットワーク図

116499-configure-ikev2-trustsec-02.jpg

トラフィック フロー

このネットワークでは、3750X-5 および 3750X-6 は TrustSec クラウドの中の Catalyst スイッチです。 クラウドに加入するために提供する両方のスイッチ 使用自動保護されたアクセス 資格情報(PAC)。 3750X-5 はシードするおよび non-seed デバイスとして 3750X-6 として使用されました。 両方のスイッチ間のトラフィックは MACsec と暗号化され、正しくタグ付けされます。

Windows XP はネットワークにアクセスするために 802.1X を使用します。 認証の成功の後で、ISE はそのセッションに適用する SGT タグ アトリビュートを戻します。 その PC から送信されるすべてのトラフィックは SGT=3 とタグ付けされます。

ルータ 1 (R1)およびルータ 2 (R2)は 2901 ISR です。 ISR G2 が現在 SGT タギングをサポートしないので、R1 および R2 は TrustSec クラウドの外にあり、SGT タグを渡すために CMD フィールドと修正されたイーサネットフレームを理解しません。 従って 3750X-5 からの R1 に IP/SGT マッピングについての情報を転送するために、SXP は使用されます。

遠隔地に向かうトラフィックを保護するために設定される有効に なるインライン タギングがあり、R1 に IKEv2 トンネルがあります(192.168.100.1)。 IKEv2 ネゴシエーションの後で、R1 は R2 に送信される ESP パケットをタグ付けし始めます。 タギングは 3750X-5 から届く SXP データに基づいています。

R2 は、受け取った SGT タグに基づいて受信、そのトラフィックを ZBF によって定義される特定の操作を行うことができます。

同じは R1 ですることができます。 SGT 帯がサポートされなくても SGT タグに基づく LAN から受信されるパケットを廃棄する SXP マッピング割り当て R1。

TrustSec Cloud 設定

設定の第一歩は TrustSec クラウドを構築することです。 3750 のスイッチは両方とも必要とします:

  • TrustSec クラウド(ISE)への認証のために使用される PAC を得て下さい。
  • ネットワークデバイス アドミッション制御(NDAC)プロセスを認証し、渡して下さい。
  • リンクの MACsec ネゴシエーションのためにセキュリティ結合 プロトコル(SAP)を使用して下さい。

このステップは SXP プロトコルが正しくはたらくことができるようにこの使用例に必要でが、必要ではないです。 R1 は ISE から PAC か SXP マッピングおよび IKEv2 インライン タギングを行うために環境 データを入手する必要はありません。

確認

3750X-5 および 3750X-6 使用 MACsec 暗号化間のリンクは 802.1X によってネゴシエートしました。 スイッチは両方ともピアによって受け取った 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 は CMD フィールドが付いているイーサネットフレームを理解しないのは 2901 ISR G2 ルータであるので TrustSec クラウドに加入できません。 このように、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 は今 SGT=3 としてタグ付けされるように 192.168.2.200 から受信されるすべてのトラフィックが処理する必要があることがわかっています。

R1 と R2 間の IKEv2 設定

これは IKEv2 スマートなデフォルトの簡単で静的で仮想 な トンネルインターフェイス(SVTI)ベースのシナリオです。 事前共有キーは認証のために使用され、ヌル 暗号化は 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

両方のルータで 1 コマンドだけインライン タギングを有効に するために必要となります: 暗号 ikev2 cts sgt コマンド。

確認

インライン タギングはネゴシエートされる必要があります。 第 1 及び第 2 IKEv2 パケットでは、特定の Vendor ID は送信 されて います:

116499-configure-ikev2-trustsec-04.png

Wireshark によって不明である 3 ベンダー ID (VID)があります。 それらはと関連しています:

  • Cisco によってサポートされる DELETE-REASON
  • Cisco によってサポートされる FlexVPN
  • SGT インラインに taggging

デバッグはこれを確認します。 IKEv2 発信側である R1 は送信 します:

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 は第 2 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 Security Association (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

それが 192.168.100.1 の方の Windows クライアントからのトラフィックを送信 した後、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 パケット水平な確認

R1 から R2 に ESP トラフィックを検討するために組み込みパケットキャプチャ(EPC)をようにこの図で示します使用して下さい:

116499-configure-ikev2-trustsec-05.png

Wireshark が Security Parameter Index (SPI)のためのヌル暗号化をデコードするのに使用されていました。 IPv4 ヘッダでは、送信元および宛先 IP はルータのインターネット IP アドレスです(トンネル ソース と 宛先として使用される)。

赤で強調表示されている ESP ペイロードは 8 バイト CMD フィールドが含まれています、:

  • 0x04 - IP である次のヘッダ、
  • 0x01 -長さ(4 バイト、ヘッダとのヘッダの後の 8 バイト)
  • 0x01 -バージョン 01
  • 0x00 -予約済み
  • 0x00 - SGT 長さ(4 バイトは合計します)
  • 0x01 - SGT 型
  • 0x0003 - SGT タグ(00 03 である最後の 2 オクテット、; SGT は Windows クライアントのために使用されます)

IPsec IPv4 モードがトンネルインターフェイスのために使用されたので、次のヘッダはグリーンで強調表示される IP です。 ソース IP は c0 a8 02 c8 です(192.168.2.200)、宛先IP は c0 a8 64 01 であり(192.168.100.1)。 プロトコル 番号は ICMP の 1 です。

最後のヘッダは型 08 およびコード 8 (エコー要求)のブルーで、強調表示される ICMP です。

ICMPペイロードは次で、長く 32 バイトです(すなわち、a からの i)への文字。 図のペイロードは Windows クライアントのために典型的です。

ESP ヘッダの他は ICMPペイロードに続きます:

  • 0x01 0x02 -パッディング。
  • 0x02 -長さのパッディング。
  • 0x63 - 「私用 暗号化方式」。である、プロトコル 0x63 を指す次のヘッダ これは Next フィールド(ESP データの最初のフィールド)が SGT タグであることを示します。
  • 12 バイトの Integrity Check Value。

CMD フィールドは一般に暗号化される ESP ペイロードの中にあります。

IKEv2 落とし穴: GRE か IPSecモード

今まで、これらの例はトンネルモード IPsec IPv4 を使用しました。 総称ルーティング カプセル化(GRE) モードが使用される場合何が起こりますか。

ルータが GRE に中継 IPパケットをカプセル化するとき、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 を使用しないことは非常に重要です。

GRE モードについては Cisco バグ ID CSCuj25890 を、IOS IPSec インライン タギング参照して下さい: ルータ下士官の挿入。 この不具合は GRE を使用するとき適切な SGT 伝搬を可能にするために作成されました。

IKEv2 からの SGT タグに基づく ZBF

これは R2 の ZBF の設定例です。 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 による 4 つのドロップ(送信 される ICMPエコーのデフォルト 番号)があり、5 つは受け入れます(スイッチのためのデフォルト 番号)。

SXP によって SGT マッピングに基づく ZBF

R1 のおよび LAN から受信されるフィルタ トラフィックへの SGT わかっている ZBF を実行することは可能性のあるです。 そのトラフィックがタグ付けされる 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 ポリシーを適用できます。

道路地図

GET VPN インライン タギングはまた ISR G2 および Cisco ASR 1000 シリーズ アグリゲーション サービス ルータでサポートされます。 ESP パケットに CMD フィールドのための追加 8 バイトがあります。

Dynamic Multipoint VPN (DMVPN)のためのサポートはまた計画されます。

詳細については Cisco によって TrustSec 有効に される インフラストラクチャ道路地図を参照して下さい。

確認

確認 手順は設定例の内で含まれています。

トラブルシューティング

現在のところ、この設定に関する特定のトラブルシューティング情報はありません。

関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116499