Проблема с новым сайтом, удаленная часть которого находится за брандмауэром. Интерфейс туннеля работает, маршруты есть, но через туннель ничего не инкапсулируется. Я вижу декапсуляцию, но трафик не проходит от хаба к спице. Я также не могу пинговать удаленный конец интерфейса туннеля, который является /30. В настоящее время у меня нет доступа к удаленному концу (есть файл конфигурации), поэтому я пытаюсь заставить это работать со стороны хаба, но без особого успеха. У меня есть другие идентичные конфигурации, которые работают без проблем, но эта не работает, и я не понимаю, почему. Предполагаю, что проблема в маршрутизации на дальнем конце, но я должен хотя бы иметь возможность пинговать дальний конец туннеля 172.21.8.13, нет? Tunnel6 172.21.8.14 YES manual up up 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 99.66.77.88 tunnel protection ipsec profile ikev2-
end Crypto map tag: Tunnel6-head-0, local addr 88.55.66.77 protected vrf: (none) local ident (addr/mask/prot/port): (88.55.66.77/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (192.168.2.2/255.255.255.255/47/0) current_peer 99.66.77.88 port 64917 PERMIT, flags={} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 349, #pkts decrypt: 349, #pkts verify: 349 #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.: 88.55.66.77, remote crypto endpt.: 99.66.77.88 plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0 current outbound spi: 0x85BEAFA7(2243866535) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x97864AAC(2542160556) transform: esp-256-aes esp-sha256-hmac , in use settings ={Tunnel UDP-Encaps, } conn id: 8517, flow_id: ESG:6517, sibling_flags FFFFFFFF80000048, crypto map: Tunnel6-head-0 sa timing: remaining key lifetime (k/sec): (4607966/3412) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE)

]]>https://sla247.ru/forum/topic/2406/туннель-ikev2-не-инкапсулирует-трафикRSS for NodeFri, 15 May 2026 06:10:26 GMTMon, 02 Mar 2026 12:42:43 GMT60Да, это зависит от поставщика, но они используют 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

]]>https://sla247.ru/forum/post/16893https://sla247.ru/forum/post/16893Mon, 02 Mar 2026 12:42:59 GMT@the-lebowski,
можете ли вы попробовать удалить интерфейс туннеля и воссоздать его с правильным режимом туннеля, а затем посмотреть на результат? Я заметил, что у партнера NAT, так что устройство перед ним разрешает udp/4500 от вашего маршрутизатора?

]]>https://sla247.ru/forum/post/16892https://sla247.ru/forum/post/16892Mon, 02 Mar 2026 12:42:58 GMTЯ изменил настройки на своем конце, но безрезультатно, туннель так и не проходит
IN-NEG.
Ничто из того, что я делаю на своем конце, не имеет значения, и без доступа к дальнему концу я застрял. На данный момент я просто предполагаю, что на дальнем конце что-то не так и это нужно исправить. Странно, что я могу настроить свою сторону как ipsec, и она запускается, но если я настраиваю как GRE, она никогда не запускается, что заставляет меня думать, что дальняя сторона не настроена как GRE, а настроена как ipsec?

]]>https://sla247.ru/forum/post/16891https://sla247.ru/forum/post/16891Mon, 02 Mar 2026 12:42:57 GMT@the-lebowski
это SVTI, вы можете изменить любой конец, так как это повлияет только на туннель между этими двумя узлами. Почему бы не изменить свой на GRE, чтобы запустить туннель и подтвердить, что это именно в этом проблема?

]]>https://sla247.ru/forum/post/16890https://sla247.ru/forum/post/16890Mon, 02 Mar 2026 12:42:56 GMTДа, это проблема, но почему? Я никак не могу понять, почему селектор туннеля не равен 0.0.0.0/0. И, как сказал
@Rob Ingram
, это может быть режим туннеля, но я не могу изменить его на дальнем конце, так как у меня еще нет к нему доступа.

]]>https://sla247.ru/forum/post/16889https://sla247.ru/forum/post/16889Mon, 02 Mar 2026 12:42:55 GMT@Rob Ingram
Я ответил ниже, но единственная конфигурация, которая у меня есть с дальнего конца, показывает, что к интерфейсу туннеля эта команда не применяется.

]]>https://sla247.ru/forum/post/16888https://sla247.ru/forum/post/16888Mon, 02 Mar 2026 12:42:54 GMTЕсли бы сосед использовал VPN на основе политики, то селекторы все равно не были бы (192.168.2.2/255.255.255.255/47/0), они бы отражали селекторы трафика, которые идентифицируют интересный трафик. @the-lebowski
проверьте, что режим туннеля одинаков на обеих сторонах, как указано в моем первоначальном посте.

]]>https://sla247.ru/forum/post/16887https://sla247.ru/forum/post/16887Mon, 02 Mar 2026 12:42:53 GMTПотому что ваш селектор не равен 0.0.0.0 Проблема заключается в том, что другая сторона использует политику, а ваша сторона использует маршрутизацию на основе VPN MHM

]]>https://sla247.ru/forum/post/16886https://sla247.ru/forum/post/16886Mon, 02 Mar 2026 12:42:52 GMTЭто должен быть маршрутный 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

]]>https://sla247.ru/forum/post/16885https://sla247.ru/forum/post/16885Mon, 02 Mar 2026 12:42:51 GMTtunnel protection ipsec policy ipv4 CACL Добавьте это в раздел «Туннель» Примечание: вам необходимо добавить ACL, как и в случае с VPN на основе политик. После добавления команды под туннелем необходимо сбросить криптографию MHM

]]>https://sla247.ru/forum/post/16884https://sla247.ru/forum/post/16884Mon, 02 Mar 2026 12:42:50 GMTДа, я ответил ранее, что удалил это с конца концентратора, но при этом туннель так и не устанавливается. Он просто висит над портом 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

]]>https://sla247.ru/forum/post/16883https://sla247.ru/forum/post/16883Mon, 02 Mar 2026 12:42:49 GMT@the-lebowski
, если вышеуказанная конфигурация принадлежит удаленному узлу, отсутствие «tunnel mode ipsec ipv4» в интерфейсе туннеля подтверждает, что он использует GRE, который является стандартным для интерфейса туннеля. Выполните команду «no tunnel mode ipsec ipv4» или «tunnel mode gre», чтобы изменить режим с ipsec на gre.

]]>https://sla247.ru/forum/post/16882https://sla247.ru/forum/post/16882Mon, 02 Mar 2026 12:42:48 GMTЯ не уверен, у меня есть только конфигурация удаленного сайта до его отправки на место (могла измениться), которая приведена ниже, а интерфейс туннеля не настроен как 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

]]>https://sla247.ru/forum/post/16881https://sla247.ru/forum/post/16881Mon, 02 Mar 2026 12:42:47 GMT@the-lebowski
у вас есть туннельный режим ipsec ipv4 под туннельным интерфейсом, но удаленная сторона настроена как GRE?....так как локальные/удаленные идентификаторы (255.255.255.255/
47
/0) указывают на использование GRE. Определите, является ли это gre/ipsec, и при необходимости внесите изменения.

]]>https://sla247.ru/forum/post/16880https://sla247.ru/forum/post/16880Mon, 02 Mar 2026 12:42:46 GMT@the-lebowski
отлично, установлены ли входящий/исходящий esp sa, я не могу сказать по этому выводу. Я заметил, что в удаленном туннеле настроен NAT. Может ли удаленный узел непреднамеренно преобразовывать трафик через туннель? И ваш локальный маршрутизатор не имеет маршрута к IP-адресу NAT, что и вызывает проблему?

]]>https://sla247.ru/forum/post/16879https://sla247.ru/forum/post/16879Mon, 02 Mar 2026 12:42:45 GMTСелектор теперь равен 0.0.0.0, что очень хорошо Возвращайтесь к падению трафика, почему вы настроили туннель с ip nat внутри? MHM

]]>https://sla247.ru/forum/post/16878https://sla247.ru/forum/post/16878Mon, 02 Mar 2026 12:42:44 GMT