Извините .. Я новичок в Cisco IOS, поэтому, если мне нужно предоставить дополнительную информацию, дайте мне знать.
Использование IOS 9.1 (6), ASDM 7.10 (1) на Cisco 5510, подключение к виртуальной сети Azure. (Да, UsePolicyBasedTrafficSelectors имеет значение true)
Я создаю VPN от нас (с одним диапазоном сети) на другой сайт, который имеет несколько диапазонов сети. Но кажется, что VPN подходит только для одного диапазона. Остальные получают ошибку «Политика криптокарты не найдена».
Вот список доступа, который я определил (ну .. он был автоматически определен, когда я создавал запись VPN в ASDM):
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.
Кроме того, когда устройство Cisco попыталось инициировать дочернюю 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), похоже, решило эту проблему.