туннель IKEv2 не инкапсулирует трафик
-
@the-lebowski
у вас есть туннельный режим ipsec ipv4 под туннельным интерфейсом, но удаленная сторона настроена как GRE?....так как локальные/удаленные идентификаторы (255.255.255.255/
47
/0) указывают на использование GRE. Определите, является ли это gre/ipsec, и при необходимости внесите изменения. -
Я не уверен, у меня есть только конфигурация удаленного сайта до его отправки на место (могла измениться), которая приведена ниже, а интерфейс туннеля не настроен как ipsec. Я удалил эту команду с конца концентратора, перезапустил туннель, но теперь он не устанавливается. Он просто зависает на порту 500, никогда не переключается на NAT-T, и интерфейс туннеля никогда не появляется. Так как же один конец, настроенный как ipsec, а другой как GRE, устанавливает соединение, а когда обе стороны настроены на GRE, соединение не устанавливается? Не уверен, что смогу решить эту проблему, не имея доступа к удаленному концу, так как ничего из того, что я пробовал на стороне концентратора, не сработало. interface Tunnel1 ip address 172.21.8.13 255.255.255.252 ip mtu 1400 ip nat inside ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel destination xx.xx.xx.xx tunnel protection ipsec profile ikev2
-
@the-lebowski
, если вышеуказанная конфигурация принадлежит удаленному узлу, отсутствие «tunnel mode ipsec ipv4» в интерфейсе туннеля подтверждает, что он использует GRE, который является стандартным для интерфейса туннеля. Выполните команду «no tunnel mode ipsec ipv4» или «tunnel mode gre», чтобы изменить режим с ipsec на gre. -
Да, я ответил ранее, что удалил это с конца концентратора, но при этом туннель так и не устанавливается. Он просто висит над портом 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 -
tunnel protection ipsec policy ipv4 CACL Добавьте это в раздел «Туннель» Примечание: вам необходимо добавить ACL, как и в случае с VPN на основе политик. После добавления команды под туннелем необходимо сбросить криптографию MHM
-
Это должен быть маршрутный 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 -
Потому что ваш селектор не равен 0.0.0.0 Проблема заключается в том, что другая сторона использует политику, а ваша сторона использует маршрутизацию на основе VPN MHM
-
Если бы сосед использовал VPN на основе политики, то селекторы все равно не были бы (192.168.2.2/255.255.255.255/47/0), они бы отражали селекторы трафика, которые идентифицируют интересный трафик. @the-lebowski
проверьте, что режим туннеля одинаков на обеих сторонах, как указано в моем первоначальном посте. -
@Rob Ingram
Я ответил ниже, но единственная конфигурация, которая у меня есть с дальнего конца, показывает, что к интерфейсу туннеля эта команда не применяется. -
Да, это проблема, но почему? Я никак не могу понять, почему селектор туннеля не равен 0.0.0.0/0. И, как сказал
@Rob Ingram
, это может быть режим туннеля, но я не могу изменить его на дальнем конце, так как у меня еще нет к нему доступа. -
@the-lebowski
это SVTI, вы можете изменить любой конец, так как это повлияет только на туннель между этими двумя узлами. Почему бы не изменить свой на GRE, чтобы запустить туннель и подтвердить, что это именно в этом проблема? -
Я изменил настройки на своем конце, но безрезультатно, туннель так и не проходит
IN-NEG.
Ничто из того, что я делаю на своем конце, не имеет значения, и без доступа к дальнему концу я застрял. На данный момент я просто предполагаю, что на дальнем конце что-то не так и это нужно исправить. Странно, что я могу настроить свою сторону как ipsec, и она запускается, но если я настраиваю как GRE, она никогда не запускается, что заставляет меня думать, что дальняя сторона не настроена как GRE, а настроена как ipsec? -
@the-lebowski,
можете ли вы попробовать удалить интерфейс туннеля и воссоздать его с правильным режимом туннеля, а затем посмотреть на результат? Я заметил, что у партнера NAT, так что устройство перед ним разрешает udp/4500 от вашего маршрутизатора? -
Да, это зависит от поставщика, но они используют 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
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти