туннель IKEv2 не инкапсулирует трафик

[the-lebowski]

Да, я ответил ранее, что удалил это с конца концентратора, но при этом туннель так и не устанавливается. Он просто висит над портом 500, а удаленный идентификатор показывает
публичный IP-
адрес удаленного конца, а не частный. interface: Tunnel6 Crypto map tag: Tunnel6-head-0, local addr yy.yy.yy.yy protected vrf: (none) local ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/47/0) current_peer xx.xx.xx.xx port 500 PERMIT, flags={origin_is_acl,} Sep 16 07:40:27.661 pst: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel6, changed state to down
Sep 16 07:40:56.899 pst: %SYS-5-CONFIG_I: Configured from console by lebowski-admin on vty0 (10.10.20.20)
(config-if)#do show ip int brief | i Tunnel6
Tunnel6 172.21.8.14 YES manual up down
Building configuration... Current configuration : 333 bytes
!
interface Tunnel6 ip address 172.21.8.14 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel destination xx.xx.xx.xx tunnel protection ipsec profile ikev2
end

[MHM Cisco World]

tunnel protection ipsec policy ipv4 CACL Добавьте это в раздел «Туннель» Примечание: вам необходимо добавить ACL, как и в случае с VPN на основе политик. После добавления команды под туннелем необходимо сбросить криптографию MHM

[the-lebowski]

Это должен быть маршрутный VPN, так зачем мне нужен ACL? У меня есть другие туннели, настроенные почти идентично (тоже за NAT), которые работают без применения ACL. Я добавил ANY ANY acl к интерфейсу туннеля, shut/no shut, но безрезультатно. Поведение осталось точно таким же. interface Tunnel6 ip address 172.21.8.14 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel mode ipsec ipv4 tunnel destination xx.xx.xx.xx tunnel protection ipsec policy ipv4 CACL tunnel protection ipsec profile ikev2
end #show ip access-lists CACL
Extended IP access list CACL 10 permit ip any any (8 matches) #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2

[MHM Cisco World]

Потому что ваш селектор не равен 0.0.0.0 Проблема заключается в том, что другая сторона использует политику, а ваша сторона использует маршрутизацию на основе VPN MHM

[Rob Ingram]

Если бы сосед использовал VPN на основе политики, то селекторы все равно не были бы (192.168.2.2/255.255.255.255/47/0), они бы отражали селекторы трафика, которые идентифицируют интересный трафик. @the-lebowski
проверьте, что режим туннеля одинаков на обеих сторонах, как указано в моем первоначальном посте.

[the-lebowski]

@Rob Ingram
Я ответил ниже, но единственная конфигурация, которая у меня есть с дальнего конца, показывает, что к интерфейсу туннеля эта команда не применяется.

[the-lebowski]

Да, это проблема, но почему? Я никак не могу понять, почему селектор туннеля не равен 0.0.0.0/0. И, как сказал
@Rob Ingram
, это может быть режим туннеля, но я не могу изменить его на дальнем конце, так как у меня еще нет к нему доступа.

[Rob Ingram]

@the-lebowski
это SVTI, вы можете изменить любой конец, так как это повлияет только на туннель между этими двумя узлами. Почему бы не изменить свой на GRE, чтобы запустить туннель и подтвердить, что это именно в этом проблема?

[the-lebowski]

Я изменил настройки на своем конце, но безрезультатно, туннель так и не проходит
IN-NEG.
Ничто из того, что я делаю на своем конце, не имеет значения, и без доступа к дальнему концу я застрял. На данный момент я просто предполагаю, что на дальнем конце что-то не так и это нужно исправить. Странно, что я могу настроить свою сторону как ipsec, и она запускается, но если я настраиваю как GRE, она никогда не запускается, что заставляет меня думать, что дальняя сторона не настроена как GRE, а настроена как ipsec?

[Rob Ingram]

@the-lebowski,
можете ли вы попробовать удалить интерфейс туннеля и воссоздать его с правильным режимом туннеля, а затем посмотреть на результат? Я заметил, что у партнера NAT, так что устройство перед ним разрешает udp/4500 от вашего маршрутизатора?

[the-lebowski]

Да, это зависит от поставщика, но они используют NAT для UDP/4500 t0 64517, поэтому я вижу этот порт, когда режим туннеля установлен на IPSEC. Я отключил/не отключил интерфейс туннеля, когда вносил изменения, что, как я полагаю, было достаточно для очистки шифрования? В любом случае, я полностью удалил интерфейс туннеля и воссоздал его, не устанавливая режим туннеля на IPSEC, но безрезультатно. interface Tunnel6 ip address 172.21.8.14 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel destination xx.xx.xx.xx tunnel protection ipsec profile ikev2
end Без настройки IPSEC он просто никогда не переключается на NAT-T, и я вижу это в отладочных данных: Sep 16 08:17:38.290 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):IPSec policy validate request sent for profile v2-profile with psh index 1. Sep 16 08:17:38.290 pst: IKEv2:(SESSION ID = 379275,SA ID = 1): Sep 16 08:17:38.291 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):(SA ID = 1):[IPsec -> IKEv2] Callback received for the validate proposal - FAILED.
Sep 16 08:17:38.291 pst: IKEv2-ERROR:(SESSION ID = 379275,SA ID = 1):: There was no IPSEC policy found for received TS
Sep 16 08:17:38.291 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):Sending TS unacceptable notify