Cisco

未找到加密地圖政策(但它在那裡……承諾!)

  • March 14, 2019

抱歉.. 我是 Cisco IOS 的新手,所以如果我需要提供更多資訊,請告訴我。

在 Cisco 5510 上使用 IOS 9.1(6)、ASDM 7.10(1),連接到 Azure VNET。(是的,UsePolicyBasedTrafficSelectors 設置為 true)

我正在創建一個從我們(具有單個網路範圍)到另一個具有多個網路範圍的站點的 VPN。但是,VPN 似乎只出現在一個範圍內。其餘的會出現“找不到加密映射策略”錯誤。

這是我定義的訪問列表(嗯..它是我在 ASDM 中創建 VPN 條目時自動定義的):

ciscoasa(config)# show access-list AT&T_cryptomap
access-list AT&T_cryptomap; 5 elements; name hash: 0x395898
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 object-group DM_INLINE_NETWORK_2 (hitcnt=2) 0xaeb5bef0 
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 10.3.0.0 255.255.255.0 (hitcnt=2) 0x41216cae 
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 10.3.1.0 255.255.255.224 (hitcnt=4) 0xee40b1de 
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 10.3.2.0 255.255.255.0 (hitcnt=4) 0xbdd4449d 
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 10.3.224.0 255.255.255.0 (hitcnt=4) 0xa8646d01 
access-list AT&T_cryptomap line 1 extended permit ip 172.16.1.0 255.255.255.240 10.3.254.0 255.255.254.0 (hitcnt=4) 0xbf2c68a9

隧道出現在列表中的最後一個 (10.3.254.0) 上,但其餘的都出錯。範例是:

Crypto Map Policy not found for remote traffic selector 10.3.2.0/10.3.2.0/0/65535/0 local traffic selector 172.16.1.0/172.16.1.15/0/65535/0!

我還應該注意,如果我將 ACL 修改為僅包含任何一個(但只是一個)路由,VPN 就會出現在該路由上。因此,所有路線看起來都不錯,但我一次只能獲得其中一條。

**更新:**似乎當我使用第一個導致隧道建構的設置範圍時。從那時起,所有子 SA 都會失敗,無論是誰嘗試啟動它。

我確實注意到了一件事……當子 SA 請求從 Azure 進來時,IP 範圍不是范圍。它們只是該範圍的第一個 IP。

(27):      3c 6f b0 28 6d 24 1d 3e 5d f1 4b eb 94 ad 2f f7
(27):      15 b5 0c a8 d6 eb fe 0c 2a 31 f2 10 43 58 50 66
(27):      ea 54 73 8e 20 0f bd e3 8f 5d 41 e1 63 a3 c5 ec
(27):  TSi(27):   Next payload: TSr, reserved: 0x0, length: 24
(27):     Num of TSs: 1, reserved 0x0, reserved 0x0
(27):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(27):     start port: 0, end port: 65535
(27):     start addr: 10.3.0.0, end addr: 10.3.0.0
(27):  TSr(27):   Next payload: NONE, reserved: 0x0, length: 24
(27):     Num of TSs: 1, reserved 0x0, reserved 0x0
(27):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(27):     start port: 0, end port: 65535
(27):     start addr: 172.16.1.0, end addr: 172.16.1.15

10.3.0.0 是 10.3.0.0/24 範圍的一部分。

此外,當思科單元由於我端的連接請求而嘗試啟動子 SA 時,子 SA 包含 2 個 TS(不知道這意味著什麼,順便說一句),一個用於我試圖訪問的單個 IP,而其他用於正確的 IP 範圍。

(22):      a9 0d f0 fd 71 a5 a9 02 b8 67 9e 91 b5 45 c6 b4
(22):      56 19 a5 0a c1 65 13 8e 3c 2c fb 75 9d 7a f3 9b
(22):      3e 7a 8b 16 58 18 6c 08 e3 7d 27 01 0d 2a f5 a6
(22):      a0 f5 d9 52 f5 8a 60 d4 1b ad f3 bf 85 cb a4 a8
(22):      20 5b eb 81 83 eb 95 28 4d b9 6f 7a 04 f4 e5 67
(22):      ba 23 a3 21 e2 3e 44 2f 62 b8 93 4d 39 93 4f e2
(22):      a3 f8 02 38 58 04 d4 3b ec 7e fb 4a d0 af 61 3c
(22):      c3 97 c8 82 fb 04 7e 4f 0c 8e 2a bb 20 1e 9e 9e
(22):      ab 52 2c 17 84 23 08 cf 06 44 54 39 65 02 cc 2d
(22):      80 71 9b 16 d4 51 4c 0e d2 d3 82 9a de 9b 81 46
(22):      c2 2b 49 54 fb 4d b5 be 9d c1 f6 46 39 e1 3a 0b
(22):      90 d0 fe e9 0d e7 39 a6 1c b9 d0 97 24 20 c2 87
(22):  TSi(22):   Next payload: TSr, reserved: 0x0, length: 40
(22):     Num of TSs: 2, reserved 0x0, reserved 0x0
(22):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(22):     start port: 0, end port: 65535
(22):     start addr: 172.16.1.1, end addr: 172.16.1.1
(22):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(22):     start port: 0, end port: 65535
(22):     start addr: 172.16.1.0, end addr: 172.16.1.15
(22):  TSr(22):   Next payload: NONE, reserved: 0x0, length: 40
(22):     Num of TSs: 2, reserved 0x0, reserved 0x0
(22):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(22):     start port: 0, end port: 65535
(22):     start addr: 10.3.2.20, end addr: 10.3.2.20
(22):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(22):     start port: 0, end port: 65535
(22):     start addr: 10.3.2.0, end addr: 10.3.2.255

10.3.2.20 是我試圖命中的 IP,它導致 Cisco 嘗試建立子隧道。

我是否誤解了這一切應該如何運作?

我錯過了什麼?

似乎是 IOS 9.1(6) 的某種問題。升級到 9.8(2) 似乎已經解決了它。

引用自:https://serverfault.com/questions/957081