Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@h_toshik

【Cisco IOS XE】IPsec Crypto Mapのサポート終了とマイグレーション

Posted at

IOS-XEでのCrypto Mapサポート終了について

Cisco IOS-XEにおいてIPsecに使用されるCrypto Map機能のサポート終了がアナウンスされています。

ポリシーベースVPNのIPsecの設定でCrypto Mapを使用するため、IPsec機能を使用する機器の更改やバージョンアップでは要注意となる内容です。
IOS-XE 17.6.6までのサポートのようなので基本的には17.6以降のリリースでは使用しない方が無難のようです。

今回はマイグレーション方法として機能追加されたMulti-SA VTI機能の紹介とMulti-SA VTIをテストしてみた、という記事になります。

マイグレーション方法

理想的なマイグレーション方法は、EoSのリンクに記載されているようにルートベースVPNであるIPsec VTI(Virtual Tunnel Interface)機能へのマイグレーションです。
VTI機能はIOS 12.3Tからサポートされている機能なので、今回のCrypto Mapサポート終了とは関係なく拠点間VPNでVTIを使用している機器も非常に多いと思います。

Crypto Mapを使用したポリシーベースVPN構成は、以下のような課題/問題があり使いづらい部分があります。
・暗号化対象ACLを定義し暗号化機器同士で対称的なACL定義とする必要がある
・暗号化対象ネットワークが増減する度に暗号化対象ACLの修正がお互いの機器で必要となる
・暗号化対象ACLのミスマッチが発生しやすい
・暗号化対象ACLの大規模な設定変更により、システムリソースの大量使用が起こり、通信断やシステム障害が発生する可能性がある

経験則的にもCrypto MapでのIPsecの初回接続で起こるトラブルの場合、暗号化対象ACLの定義が誤っていることが原因として多い印象です。

一方、VTIの場合は暗号化対象ACLを定義する必要はありません。フィルタリングはトンネルインターフェースにACLを適用することで機能します。機器同士でACLの設定を合わせる必要もありません。
また、VTIではインターフェース単位で各種機能(ACL、NAT、FW、QoS、etc...)を適用できるので使い勝手が良くなっています。
上記のような背景からVTIベースの機能に絞って開発、サポートをしていく舵を切ったと推測されます。

Crypto Mapベースの設定からVTIへのマイグレーションガイドはCiscoからも公開されています。
Before(Crypto Map)、After(VTI)の設定例が記載されているので非常に参考になると思います。

VTIでの問題点

ただし、VTIへの変更で全て解決できれば良いのですが下のようなケースも出てくることが予想されます。
・IPsecの接続先が他社や別組織の管理機器でポリシーベースVPNでの接続が指定されている

つまりはこのような構成です。
Router A(VTI)　==IPsec VPN==　Router B(Crypto Map)

実際に、これまでの実装ではVTIとCrypto Mapのコンパチ接続はサポートされていませんでしたが
IOS-XE 16.12においてMulti-SA VTIというCrypto Mapとのコンパチ接続をサポートする機能が追加されました。

Multi-SA VTIはざっくり言うと、基本的には従来のVTI設定なのですが、暗号化対象ACLを紐づけReverse Route Injection(RRI)によってStatic Routeをルーティングテーブルに学習する動作になっています。
※RRIはリモートのVPNエンドポイントにスタティックルートを配布する機能

Multi-SA VTIで接続した場合、IPsec SAのProxy IDも通常のVTIは”any/any"のステータスとなるところが、Crypto Map設定時のように"source address/destination address"のペアで確立します。

今回はIOS-XE ルーターでMulti-SA VTIとCrypto Map設定機器とのコンパチ接続をやってみました。

テスト構成

2023-05-08 14_25_40-Windows シェル エクスペリエンス ホスト.png

Device OS Image VPN feature
RT_A IOS-XE 17.6.5 Multi-SA VTI
RT_B IOS 15.7M3 Policy Based VPN(Crypto Map)

[RT_A]がMulti-SA VTI、[RT_B] がCrypto MapによるポリシーベースVPN設定の構成になっています。
[RT_B] がVTIへの設定変更が出来ない機器をイメージしています。

設定(RT_A)

・暗号化パラメータ設定

crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key cisco12345 address 192.168.2.2    
crypto isakmp keepalive 30 10
!
crypto ipsec security-association replay disable
!
crypto ipsec transform-set IPSEC esp-aes 256 esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile VTI
 set transform-set IPSEC 
 reverse-route

IKEv1でのフェーズ1とフェーズ2設定です。(IKEv2も可)
標準的なVTIとほぼ設定は一緒です。
Multi-SA VTIで特徴的なのはcrypto ipsec profile配下に設定したreverse-route です。

・暗号化対象ACL設定

ip access-list extended CRYPTO_ACL
 10 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255

[RT_A]のLANから[RT_B]のLAN宛てのACLを定義しています。
このACLは暗号化パラメータ設定の構文では紐づけを行いません。

・インターフェース設定

interface Tunnel1
 ip unnumbered GigabitEthernet0/0/0
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 192.168.2.2
 tunnel protection ipsec policy ipv4 CRYPTO_ACL
 tunnel protection ipsec profile VTI
!
interface GigabitEthernet0/0/0
 ip address 192.168.2.1 255.255.255.0
 negotiation auto
!
interface GigabitEthernet0/0/1
 ip address 10.0.1.254 255.255.255.0
 negotiation auto

トンネルインターフェースのIPアドレスはip unnumberedでtunnel sourceのGi0/0/0を指定しています。
新規にアドレス採番しても良いですが対向機器にトンネルインターフェースは無いのでip unnumberedの方がアドレスを節約できます。
また、tunnel protection ipsec policy ipv4で暗号化対象ACLであるCRYPTO_ACLをトンネルインターフェースに紐づけています。

・ルーティング設定
VPN経由でのルーティング設定は必要ありません。IPsec SAが確立するとCRYPTO_ACLに定義した宛先アドレスへのStatic Routeがインストールされる動作になります。

設定(RT_B)

[RT_B]は通常のCrypto MapでのIPsec設定です。特に変わった設定はしていません。

・暗号化パラメータ設定

crypto isakmp policy 1
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key cisco12345 address 192.168.2.1    
crypto isakmp keepalive 30 10
!
crypto ipsec security-association replay disable
!
crypto ipsec transform-set IPSEC esp-aes 256 esp-sha256-hmac 
 mode tunnel
!
crypto map IPSEC 1 ipsec-isakmp 
 set peer 192.168.2.1
 set transform-set IPSEC 
 match address CRYPTO_ACL

・暗号化対象ACL設定

ip access-list extended CRYPTO_ACL
 10 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255

・インターフェース設定

interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
 duplex auto
 speed auto
 crypto map IPSEC
!
interface GigabitEthernet0/2
 ip address 10.0.2.254 255.255.255.0
 duplex auto
 speed auto

・ルーティング設定

ip route 10.0.1.0 255.255.255.0 192.168.2.1

インフォメーション
お互いの機器の設定が正しく、リーチャビリティがある場合、[RT_A]のトンネルインターフェースはUpし、IPsec SAが確立します。
Crypto Map同士の場合は暗号化対象ACLの通信をトリガーとしてIPsec SAが確立しますが、Multi-SA VTIはVTIベースの実装となるので暗号化対象ACLの通信がない時点でもIPsec SAを確立する動作になっていました。

ログ(RT_A)

[RT_A]のLANから[RT_B]のLAN宛てへのPing成功後に取得したログです。

RT_A#show crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.2.2     192.168.2.1     QM_IDLE           1049 ACTIVE

IPv6 Crypto ISAKMP SA

RT_A#show crypto ipsec sa           

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

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.0.2.0/255.255.255.0/0/0)
   current_peer 192.168.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
    #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.2.1, remote crypto endpt.: 192.168.2.2
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
     current outbound spi: 0x37F51E78(938811000)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xD887D234(3632779828)
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 4605, flow_id: ESG:2605, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0
         sa timing: remaining key lifetime (k/sec): (4607997/3071)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x37F51E78(938811000)
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 4606, flow_id: ESG:2606, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0
         sa timing: remaining key lifetime (k/sec): (4607997/3071)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

local identとremote identには暗号化対象ACLのSource Address(10.0.1.0/255.255.255.0)とDestination Address(10.0.2.0/255.255.255.0)が表示されています。
※標準のVTIの場合は、(0.0.0.0/0.0.0.0)となります

RT_A#show ip route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.0.1.0/24 is directly connected, GigabitEthernet0/0/1
L        10.0.1.254/32 is directly connected, GigabitEthernet0/0/1
S        10.0.2.0/24 is directly connected, Tunnel1
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, GigabitEthernet0/0/0
L        192.168.2.1/32 is directly connected, GigabitEthernet0/0/0

ルーティングテーブルには 10.0.2.0/24 is directly connected, Tunnel1というStatic Routeが追加されています。
これはConfigにip routeコマンドで設定したものではなく、RRIによってインストールされたルートとなっています。

ログ(RT_B)

RT_B#show crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.2.2     192.168.2.1     QM_IDLE          29054 ACTIVE

IPv6 Crypto ISAKMP SA

RT_B#show crypto ipsec sa     

interface: GigabitEthernet0/1
    Crypto map tag: IPSEC, local addr 192.168.2.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.2.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)
   current_peer 192.168.2.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
    #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.2.2, remote crypto endpt.: 192.168.2.1
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
     current outbound spi: 0xD887D234(3632779828)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x37F51E78(938811000)
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 19421, flow_id: ISM VPN:1421, sibling_flags 80000040, crypto map: IPSEC
        sa timing: remaining key lifetime (k/sec): (4354737/3065)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xD887D234(3632779828)
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 19422, flow_id: ISM VPN:1422, sibling_flags 80000040, crypto map: IPSEC
        sa timing: remaining key lifetime (k/sec): (4354738/3065)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

RT_B#show ip route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S        10.0.1.0/24 [1/0] via 192.168.2.1
C        10.0.2.0/24 is directly connected, GigabitEthernet0/2
L        10.0.2.254/32 is directly connected, GigabitEthernet0/2
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, GigabitEthernet0/1
L        192.168.2.2/32 is directly connected, GigabitEthernet0/1

[RT_B]側も特に問題なく、対向機器がポリシーベースVPN設定になっている構成と同様のログになっていると思います。

このようにMulti-SA VTIとCrypto Map設定機器同士の構成でも暗号化通信ができることが確認できました。

Multi-SA VTIでの暗号化対象ACLにおける注意点

Multi-SA VTIでの暗号化対象ACLにおける注意点として以下の内容をCiscoのドキュメントから見つけました。

・Any/Any定義を含む暗号化対象ACLをMulti-SA VTIに紐づけてはいけない。Any/Anyの場合は標準のVTIのデフォルト動作となるのでこちらを使用する。
・暗号化対象ACLはpermit定義のみがサポートされる。deny定義を含んではいけない。
・運用中の機器で暗号化対象ACLを修正する場合は、一度トンネルインターフェースをshutdownする必要がある。そのままの状態での修正はサポートされない。
・暗号化対象ACLとVTIの関連付けを解除すると、既存のIPsec SAが削除され、新規にAny/Any用のIPsec SAが形成される。
・1つのトンネルインターフェースあたり、最大でACE 100までが推奨。さらに機器1台あたりACL、トンネルインターフェース全てで関連付けられた合計のACEは最大2000まで。

特に「暗号化対象ACLを修正する場合はトンネルインターフェースのshutdownが必要」という項目は重要と思います。

最後に

最後まで読んで頂いて有難うございました。　
現状、ポリシーベースVPNが必要になるシーンもそれなりにあるのでCisco IOS-XE機器を使う場合は記事を参考にしていただけると幸いです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?