Incrementing error counter on sa attempt 2 of 5 retransmit phase 1

Зарегистрирован: 12 янв 2013, 13:56Сообщения: 156
Автор Сообщение

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение IPSec не поднимается

Всем привет. Подскажите пожалуйста в чем может быть проблема. Не поднимается ipsec через GRE (DMVPN) туннель. Дебаг показывает следующее:
Aug 28 22:15:27.763 MSK: ISAKMP (1002): received packet from 1.1.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
Aug 28 22:15:27.763 MSK: ISAKMP:(1002): phase 1 packet is a duplicate of a previous packet.
Aug 28 22:15:27.763 MSK: ISAKMP:(1002): retransmitting due to retransmit phase 1
Aug 28 22:15:28.263 MSK: ISAKMP:(1002): retransmitting phase 1 MM_KEY_EXCH…
Aug 28 22:15:28.263 MSK: ISAKMP (1002): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
Aug 28 22:15:28.263 MSK: ISAKMP:(1002): retransmitting phase 1 MM_KEY_EXCH
Aug 28 22:15:28.263 MSK: ISAKMP:(1002): sending packet to 1.1.1.1 my_port 4500 peer_port 4500 (I) MM_KEY_EXCH
Aug 28 22:15:28.263 MSK: ISAKMP:(1002):Sending an IKE IPv4 Packet.
Aug 28 22:15:37.211 MSK: ISAKMP: set new node 0 to QM_IDLE
Aug 28 22:15:37.211 MSK: ISAKMP:(1002):SA is still budding. Attached new ipsec request to it. (local 172.17.192.10, remote 195.42.96.7)
Aug 28 22:15:37.211 MSK: ISAKMP: Error while processing SA request: Failed to initialize SA
Aug 28 22:15:37.211 MSK: ISAKMP: Error while processing KMI message 0, error 2.
Aug 28 22:15:38.015 MSK: ISAKMP (1002): received packet from 1.1.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
Aug 28 22:15:38.015 MSK: ISAKMP:(1002): phase 1 packet is a duplicate of a previous packet.
Aug 28 22:15:38.015 MSK: ISAKMP:(1002): retransmitting due to retransmit phase 1
Aug 28 22:15:38.515 MSK: ISAKMP:(1002): retransmitting phase 1 MM_KEY_EXCH…
Aug 28 22:15:38.515 MSK: ISAKMP (1002): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
Aug 28 22:15:38.515 MSK: ISAKMP:(1002): retransmitting phase 1 MM_KEY_EXCH
Aug 28 22:15:38.515 MSK: ISAKMP:(1002): sending packet to 1.1.1.1 my_port 4500 peer_port 4500 (I) MM_KEY_EXCH
Aug 28 22:15:38.515 MSK: ISAKMP:(1002):Sending an IKE IPv4 Packet.undebug all
All possible debugging has been turned off

Мой спок находится за натом. Смущают меня следующие строчки

sending packet to 1.1.1.1 my_port 4500 peer_port 4500 (I) MM_KEY_EXCH
received packet from 1.1.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH

Получается так, что СПОК отправляет пакет на порт 4500 (за натом). При этом от ХАБА приходят сообщения на порт 500.

Помогите разобраться пожалуйста.

28 авг 2017, 22:25

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

вторая фаза в каком режиме — транспорт или туннель ?

28 авг 2017, 23:56

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Туннель

29 авг 2017, 00:15

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

поменяй на транспорт

29 авг 2017, 00:29

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

К сожалению мне нужен именно туннель.

29 авг 2017, 00:53

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

ну ок, ты умней циски
:lol: :lol: :lol:

29 авг 2017, 10:54

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Цитата:

ну ок, ты умней циски

Чем я умней циски, если следую их рекомендациям?
Я могу объяснить зачем мне нужен режим туннеля и почему циска мне рекоммендовала его использовать. Нужна предыстория?

29 авг 2017, 11:14

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

ну давай

29 авг 2017, 11:21

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Как вы поняли у меня в компании используется DMVPN.
У DMVPN есть одно очень не приятное ограничение. Несколько удаленных объектов, находящиеся за одним НАТ адресом провайдера работать не будут. Будет работать только один из них.
У меня есть пул объектов, которые сидят за одним НАТ адресом провайдера.
Компания Cisco сказала, что такое ограничение действительно есть, но его можно обойти. Для этого нужно сделать две вещи.
1) Нужно перевести transform-set в режим tunnel
2) Сделать так, что бы source адрес, с которого строится туннель был уникален в рамках dmvpn облака

Оба условия выполнены и туннель даже поднялся и даже ограничение обошли, но вот неожиданно туннель упал и не поднимается (debug я приложил).

К слову я тестировал всю эту схему в unetlab и там все до сих пор работает, причем порт используется 4500 в обоих направлениях.

Не могу понять почему хаб шлет пакет споку на порт 500. Кстати debug с хаба.

843225: *Aug 29 11:07:30: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
843226: *Aug 29 11:07:30: ISAKMP: encryption 3DES-CBC
843227: *Aug 29 11:07:30: ISAKMP: hash SHA
843228: *Aug 29 11:07:30: ISAKMP: default group 2
843229: *Aug 29 11:07:30: ISAKMP: auth pre-share
843230: *Aug 29 11:07:30: ISAKMP: life type in seconds
843231: *Aug 29 11:07:30: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
843232: *Aug 29 11:07:30: ISAKMP:(0):atts are acceptable. Next payload is 0
843233: *Aug 29 11:07:30: ISAKMP:(0):Acceptable atts:actual life: 86400
843234: *Aug 29 11:07:30: ISAKMP:(0):Acceptable atts:life: 0
843235: *Aug 29 11:07:30: ISAKMP:(0):Fill atts in sa vpi_length:4
843236: *Aug 29 11:07:30: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
843237: *Aug 29 11:07:30: ISAKMP:(0):Returning Actual lifetime: 86400
843238: *Aug 29 11:07:30: ISAKMP:(0)::Started lifetime timer: 86400.

843239: *Aug 29 11:07:30: ISAKMP:(0): processing vendor id payload
843240: *Aug 29 11:07:30: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
843241: *Aug 29 11:07:30: ISAKMP (0): vendor ID is NAT-T RFC 3947
843242: *Aug 29 11:07:30: ISAKMP:(0): processing vendor id payload
843243: *Aug 29 11:07:30: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
843244: *Aug 29 11:07:30: ISAKMP (0): vendor ID is NAT-T v7
843245: *Aug 29 11:07:30: ISAKMP:(0): processing vendor id payload
843246: *Aug 29 11:07:30: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch
843247: *Aug 29 11:07:30: ISAKMP:(0): vendor ID is NAT-T v3
843248: *Aug 29 11:07:30: ISAKMP:(0): processing vendor id payload
843249: *Aug 29 11:07:30: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
843250: *Aug 29 11:07:30: ISAKMP:(0): vendor ID is NAT-T v2
843251: *Aug 29 11:07:30: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
843252: *Aug 29 11:07:30: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1

843253: *Aug 29 11:07:30: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
843254: *Aug 29 11:07:30: ISAKMP:(0): sending packet to 31.173.83.33 my_port 500 peer_port 62113 (R) MM_SA_SETUP
843255: *Aug 29 11:07:30: ISAKMP:(0):Sending an IKE IPv4 Packet.
843256: *Aug 29 11:07:30: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
843257: *Aug 29 11:07:30: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2

843258: *Aug 29 11:07:30: ISAKMP (0): received packet from 31.173.83.33 dport 500 sport 62113 inet (R) MM_SA_SETUP
843259: *Aug 29 11:07:30: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
843260: *Aug 29 11:07:30: ISAKMP:(0):Old State = IKE_R_MM2 New State = IKE_R_MM3

843261: *Aug 29 11:07:30: ISAKMP:(0): processing KE payload. message ID = 0
843262: *Aug 29 11:07:30: ISAKMP:(0): processing NONCE payload. message ID = 0
843263: *Aug 29 11:07:30: ISAKMP:(0):found peer pre-shared key matching 31.173.83.33
843264: *Aug 29 11:07:30: ISAKMP:(64495): processing vendor id payload
843265: *Aug 29 11:07:30: ISAKMP:(64495): vendor ID is DPD
843266: *Aug 29 11:07:30: ISAKMP:(64495): processing vendor id payload
843267: *Aug 29 11:07:30: ISAKMP:(64495): speaking to another IOS box!
843268: *Aug 29 11:07:30: ISAKMP:(64495): processing vendor id payload
843269: *Aug 29 11:07:30: ISAKMP:(64495): vendor ID seems Unity/DPD but major 203 mismatch
843270: *Aug 29 11:07:30: ISAKMP:(64495): vendor ID is XAUTH
843271: *Aug 29 11:07:30: ISAKMP:received payload type 20
843272: *Aug 29 11:07:30: ISAKMP (64495): His hash no match — this node outside NAT
843273: *Aug 29 11:07:30: ISAKMP:received payload type 20
843274: *Aug 29 11:07:30: ISAKMP (64495): His hash no match — this node outside NAT
843275: *Aug 29 11:07:30: ISAKMP:(64495):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
843276: *Aug 29 11:07:30: ISAKMP:(64495):Old State = IKE_R_MM3 New State = IKE_R_MM3

843277: *Aug 29 11:07:30: ISAKMP:(64495): sending packet to 31.173.83.33 my_port 500 peer_port 62113 (R) MM_KEY_EXCH
843278: *Aug 29 11:07:30: ISAKMP:(64495):Sending an IKE IPv4 Packet.
843279: *Aug 29 11:07:30: ISAKMP:(64495):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

843280: *Aug 29 11:07:30: ISAKMP:(64495):Old State = IKE_R_MM3 New State = IKE_R_MM4

843282: *Aug 29 11:07:35: ISAKMP:(64469): retransmitting phase 1 MM_KEY_EXCH…
843283: *Aug 29 11:07:35: ISAKMP (64469): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
843284: *Aug 29 11:07:35: ISAKMP:(64469): retransmitting phase 1 MM_KEY_EXCH
843285: *Aug 29 11:07:35: ISAKMP:(64469): sending packet to 31.173.83.33 my_port 500 peer_port 62113 (R) MM_KEY_EXCH
843286: *Aug 29 11:07:35: ISAKMP:(64469):Sending an IKE IPv4 Packet.

Есть мысли.

29 авг 2017, 11:42

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

тебе не кажется, что с этого надо было начинать тему ? :)
по такой специфике подсказать не могу

29 авг 2017, 11:49

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Да бог с ним со спецификой. Есть дебаг. Настройка в принципе стандартная, только ipsec в режиме туннеля. Это не должно мешать работе. Сама по себе ошибка о чем может говорить?

29 авг 2017, 11:57

Профиль WWW

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Скажем так, когда я смотрю в тестовую лабу, то вижу, что там hub шлем пакет на порт 4500 и дальше все устанавливается.
Тут же он отправляет пакет на порт 500. Вот это меня смущает. Возможно какая-то опция есть, типа включения nat traversal и т.д.

29 авг 2017, 12:18

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

вот такая команда есть в конфиге ?
crypto ipsec nat-transparency udp-encapsulation

29 авг 2017, 12:21

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Такой команды нет. Как вариант проверить можно, но я боюсь как бы другие объекты не поломались, начальство может заругать.

Заметил вот такую интересную штуку. У меня получилось поднять но с костылем.

Я создал промежуточный нат, в котором при обращении на свой HUB подменил src-port с 4500 на 1313(придумал из головы).

И теперь в дебаге я вижу, что хаб отправляет мне IKE пакет на порт 4500
received packet from 1.1.1.1 dport 4500 sport 4500 Global
Сессия поднялась.

Такое ощущение, как если на хабе активен nat-traversal, но при этом, что бы он работал, необходимо что бы порт сорса обязательно был не дефолтный (не 500 и не 4500), тогда он начинает работать.

29 авг 2017, 13:01

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

это дефолтная команда, нужно искать в sh run all

29 авг 2017, 13:23

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Точно, в дефолтной конфигурации она есть

#show run all | i crypto ipsec nat-t
crypto ipsec nat-transparency udp-encapsulation

29 авг 2017, 13:31

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

у тебя два спока за одним публичным ip ?
в какие порты провайдер их натит ?

29 авг 2017, 13:46

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Сейчас таких с десяток. НАТит как попало. Как у физ. лиц в общем. Если точнее то это ПАТ.
В будущем таких будет пару сотен.

30 авг 2017, 08:02

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

проблема случается, когда провайдер натит udp 4500 в 4500 ?

30 авг 2017, 11:08

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Когда сорс порт натит 500 в 500 или 4500 в 4500.
Если порт на пути меняется, то сессия поднимается.

30 авг 2017, 11:57

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

сделал ради интереса в лабе — работает.
один и тот же роутер натит один спок в 4500, второй в 1025

Router#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 12.12.12.2:4500 192.168.23.3:4500 12.12.12.1:4500 12.12.12.1:4500
udp 12.12.12.2:1025 192.168.24.4:4500 12.12.12.1:4500 12.12.12.1:4500
Router#

30 авг 2017, 18:14

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Я пересмотрел все дебаги еще раз и у меня предположение следующее по поводу того, что у меня получается:
Изначально спок ломится на порт 500, далее определяет, что он за НАТом (не знаю как он это делает, но делает), дальше ломится на 4500. В обоих случаях сорс порт у него не меняется, т.е. остается 500 и 4500 соответственно.
Хаб при этом получает первое обращение на 500-й порт с сорс портом так же 500 и дальше уже пытается общаться со споком как с устройством, которое не находится за натом, и на следующие обращения на порт 4500 не реагирует.

Получается такой специфический рассинхрон.

Как это обойти, кроме как занатить порты 500 и 4500 в какой-нибудь левый я пока хз. Гуглю, думаю.

31 авг 2017, 10:08

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

ты же понимаешь как нат-т работает ? :)
маршрутизатор не может понять самостоятельно за натом он находится или нет. поэтому изначально обращение идет на 500 порт, и за счет сравнивания специального хэша в первых сообщениях первой фазы пиры понимают кто из них за натом, и уже далее переключаются на 4500

31 авг 2017, 10:50

Профиль

lp13

Зарегистрирован: 12 янв 2013, 13:56
Сообщения: 156

Сообщение Re: IPSec не поднимается

Да, это понятно. Но почему хаб не понимает, что спок за натом. Ведь адрес на пути меняется. И почему он начинает понимать когда я меняю source порт.

Можешь кинуть debug успешный своей лабы (спок и хаб) плз ))

31 авг 2017, 10:59

Профиль WWW

Рубен Папян

Зарегистрирован: 25 сен 2014, 21:51
Сообщения: 906

Сообщение Re: IPSec не поднимается

View post on imgur.com

R1 — хаб
R3, R4 — споки
R2 делает нат

Последний раз редактировалось Рубен Папян 31 авг 2017, 11:24, всего редактировалось 1 раз.

31 авг 2017, 11:13

Профиль

Contents

Introduction

This document contains the most common solutions to Dynamic Multipoint VPN (DMVPN) problems. Many of these solutions can be implemented prior to the in-depth troubleshooting of the DMVPN connection. This document is presented as a checklist of common procedures to try before you begin to troubleshoot a connection and call Cisco Technical Support.

If you need configuration example documents for the DMVPN, refer to DMVPN Configuration Examples and TechNotes.

Note: Refer to IPsec Troubleshooting — Understanding and Using debug Commands to provide an explanation of common debug commands that are used to troubleshoot IPsec issues.

Prerequisites

Requirements

Cisco recommends that you have knowledge of DMVPN configuration on Cisco IOS® routers.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco IOS

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

DMVPN Configuration does not work

Problem

A recently configured or modified DMVPN solution does not work.

A current DMVPN configuration no longer works.

Solutions

This section contains solutions to the most common DMVPN problems.

These solutions (in no particular order) can be used as a checklist of items to verify or try before you engage in in-depth troubleshooting:

  • Common Issues

  • Verify if ISAKMP packets are blocked at ISP

  • Verify if GRE is working fine by removing the tunnel protection

  • NHRP registration is failing

  • Verify whether the lifetimes are configured properly

  • Verify whether the traffic flows in only one direction

  • Verify that routing protocol neighbor is established

Note: Before you begin, check these:

  1. Sync-up the timestamps between the hub and spoke

  2. Enable msec debug and log timestamps:

    Router(config)#service timestamps debug datetime msec

    Router(config)#service timestamps log datetime msec

  3. Enable terminal exec prompt timestamp for the debugging sessions:

    Router#terminal exec prompt timestamp

Note: This way, you can easily correlate the debug output with the show command output.

Common Issues

Verify the basic connectivity

  1. Ping from the hub to the spoke’s using NBMA addresses and reverse.

    These pings should go directly out the physical interface, not through the DMVPN tunnel. Hopefully, there is not a firewall that blocks ping packets. If this does not work, check the routing and any firewalls between the hub and spoke routers.

  2. Also, use traceroute to check the path that the encrypted tunnel packets are taking.

  3. Use the debug and show commands to verify no connectivity:

    • debug ip icmp

    • debug ip packet

      Note: The debug ip packet command generates a substantial amount of output and uses a substantial amount of system resources. This command should be used with caution in production networks. Always use with the access-list command.

      Note: For more information on how to use the access-list with debug ip packet, refer to Troubleshoot with IP access-lists.

Verify for incompatible ISAKMP policy

If the configured ISAKMP policies do not match the proposed policy by the remote peer, the router tries the default policy of 65535. If that does not match either, it fails the ISAKMP negotiation.

The show crypto isakmp sa command shows the ISAKMP SA to be in MM_NO_STATE, meaning the main-mode failed.

Verify for incorrect pre-shared key secret

If the pre-shared secrets are not the same on both sides, the negotiation will fail.

The router returns the «sanity check failed» message.

Verify for incompatible IPsec transform set

If the IPsec transform-set is not compatible or mismatched on the two IPsec devices, the IPsec negotiation will fail.

The router returns the «atts not acceptable» message for the IPsec proposal.

Verify if ISAKMP packets are blocked at ISP

Router#show crypto isakmp sa


IPv4 Crypto ISAKMP SA
Dst	            src	               state	   conn-id	  slot	   status
172.17.0.1	  172.16.1.1	    MM_NO_STATE	     0	           0	   ACTIVE
172.17.0.1	  172.16.1.1	    MM_NO_STATE	     0	           0	   ACTIVE (deleted)
172.17.0.5        172.16.1.1        MM_NO_STATE      0             0	   ACTIVE
172.17.0.5        172.16.1.1        MM_NO_STATE      0             0	   ACTIVE (deleted)

The above shows the VPN tunnel flapping.

Further, check debug crypto isakmp to verify that the spoke router is sending udp 500 packet:

Router#debug crypto isakmp
04:14:44.450: ISAKMP:(0):Old State = IKE_READY  
                       New State = IKE_I_MM1
04:14:44.450: ISAKMP:(0): beginning Main Mode exchange
04:14:44.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:44.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:14:54.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 1 of 5: retransmit phase 1
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
04:14:54.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:54.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 2 of 5: retransmit phase 1
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

The above debug output shows spoke router is sending udp 500 packet in every 10 seconds.

Check with ISP to see if the spoke router is directly connected to the ISP router to make sure they are allowing udp 500 traffic.

After ISP allowed udp 500, add inbound ACL in egress interface, which is tunnel source to allow udp 500 to make sure udp 500 traffic is coming into the router. Use the show access-list command to verify whether hit counts are incrementing:

Router#show access-lists 101
Extended IP access list 101
    10 permit udp host 172.17.0.1 host 172.16.1.1 eq isakmp log (4 matches)
    20 permit udp host 172.17.0.5 host 172.16.1.1 eq isakmp log (4 matches)
    30 permit ip any any (295 matches)

caution Caution: Make sure you have ip any any allowed in your access-list. Otherwise, all other traffic will be blocked as an access-list applied inbound on the egress interface.

Verify if GRE is working by removing the tunnel protection

When DMVPN is not working, before troubleshooting with IPsec, verify that the GRE tunnels are working fine without IPsec encryption.

For more information, refer to Configure the GRE Tunnel.

NHRP registration is failing

The VPN tunnel between hub and spoke is up, but unable to pass data traffic:

Router#show crypto isakmp sa
        dst             src             state          conn-id  slot   status
        172.17.0.1      172.16.1.1      QM_IDLE           1082    0    ACTIVE
Router#show crypto IPSEC sa
local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
#pkts encaps: 154, #pkts encrypt: 154, #pkts digest: 154
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
inbound esp sas:
spi: 0xF830FC95(4163959957)
outbound esp sas:
spi: 0xD65A7865(3596253285)

!--- !--- Output is truncated !---

It shows that return traffic is not coming back from the other end of the tunnel.

Check NHS entry in the spoke router:

Router#show  ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding
Tunnel0: 172.17.0.1  E  req-sent 0  req-failed 30 repl-recv 0
Pending Registration Requests:
Registration Request: Reqid 4371, Ret 64  NHS 172.17.0.1

It shows that the NHS request is failing. To resolve this problem, make sure the configuration on the spoke router tunnel interface is correct.

Configuration example:

interface Tunnel0
 ip address 10.0.0.9 255.255.255.0
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp nhs 172.17.0.1

!--- !--- Output is truncated !---

Configuration example with the correct entry for the NHS server:

interface Tunnel0
 ip address 10.0.0.9 255.255.255.0
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp nhs 10.0.0.1

!--- !--- Output is truncated !---

Now, verify the NHS entry and IPsec encrypt/decrypt counters:

Router#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding
Tunnel0:        10.0.0.1 RE  req-sent 4  req-failed 0  repl-recv 3 (00:01:04 ago)

Router#show crypto IPSec sa 
local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
#pkts encaps: 121, #pkts encrypt: 121, #pkts digest: 121
#pkts decaps: 118, #pkts decrypt: 118, #pkts verify: 118
inbound esp sas:
spi: 0x1B7670FC(460747004)
outbound esp sas:
spi: 0x3B31AA86(993110662)

!--- !--- Output is truncated !---

Verify whether the lifetimes are configured properly

Use these commands to verify the current SA lifetime and the time for next renegotiation:

  • show crypto isakmp sa detail

  • show crypto ipsec sa peer <NBMA-address-peer>

Notice SA lifetime values. If they are close to the configured lifetimes (default is 24 hrs for ISAKMP and 1 hour for IPsec), then that means these SAs have been recently negotiated. If you look a little while later and they have been re-negotiated again, then the ISAKMP and/or IPsec may be bouncing up and down.

Router#show crypto ipsec security-assoc lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds

Router#show crypto isakmp policy
Global IKE policy
Protection suite of priority 1
Encryption algorithm: DES-Data Encryption Standard (65 bit keys)
Hash algorithm: Message Digest 5
Authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
Lifetime: 86400 seconds, no volume limit
Default protection suite
 Encryption algorithm: DES- Data Encryption Standard (56 bit keys)
 Hash algorithm: Secure Hash Standard
 Authentication method: Rivest-Shamir-Adleman Signature
 Diffie-Hellman group: #1 (768 bit)
 Lifetime: 86400 seconds, no volume limit

Router# show crypto ipsec sa
interface: Ethernet0/3
    Crypto map tag: vpn, local addr. 172.17.0.1
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
   current_peer: 172.17.0.1:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 19, #pkts encrypt: 19, #pkts digest 19
    #pkts decaps: 19, #pkts decrypt: 19, #pkts verify 19
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 172.16.1.1, remote crypto endpt.: 172.17.0.1
     path mtu 1500, media mtu 1500
     current outbound spi: 8E1CB77A

 inbound esp sas:
      spi: 0x4579753B(1165587771)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4456885/3531)
        IV size: 8 bytes
        replay detection support: Y
outbound esp sas:
      spi: 0x8E1CB77A(2384246650)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4456885/3531)
        IV size: 8 bytes
        replay detection support: Y  

Verify whether the traffic flows in only one direction

The VPN tunnel between the spoke-to-spoke router is up, but unable to pass data traffic:

Spoke1# show crypto ipsec sa peer 172.16.2.11
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
    #pkts encaps: 110, #pkts encrypt: 110
    #pkts decaps: 0, #pkts decrypt: 0, 
local crypto endpt.: 172.16.1.1, 
remote crypto endpt.: 172.16.2.11
      inbound esp sas:
      spi: 0x4C36F4AF(1278669999)
      outbound esp sas:
      spi: 0x6AC801F4(1791492596)

!--- !--- Output is truncated !---


Spoke2#sh crypto ipsec sa peer 172.16.1.1
   local  ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   #pkts encaps: 116, #pkts encrypt: 116,             
   #pkts decaps: 110, #pkts decrypt: 110,  
local crypto endpt.: 172.16.2.11, 
remote crypto endpt.: 172.16.1.1
     inbound esp sas:
     spi: 0x6AC801F4(1791492596)
     outbound esp sas:
     spi: 0x4C36F4AF(1278669999

!--- !--- Output is truncated !---

There is no decap packets in spoke1, which means esp packets are dropped somewhere in the path return from spoke2 towards spoke1.

The spoke2 router shows both encap and decap, which means that ESP traffic is filtered before reaching spoke2. It may happen at the ISP end at spoke2 or at any firewall in path between spoke2 router and spoke1 router. After allowing ESP (IP Protocol 50), spoke1 and spoke2 both show encaps and decaps counters are incrementing.

spoke1# show crypto ipsec sa peer 172.16.2.11
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
    #pkts encaps: 300, #pkts encrypt: 300
    #pkts decaps: 200, #pkts decrypt: 200

!--- !--- Output is truncated !---

spoke2#sh crypto ipsec sa peer 172.16.1.1
   local  ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   #pkts encaps: 316, #pkts encrypt: 316,             
   #pkts decaps: 300, #pkts decrypt: 310

!--- !--- Output is truncated !---

Verify that routing protocol neighbor is established

Spokes are unable to establish routing protocol neighbor relationship:

Hub# show ip eigrp neighbors
H   Address     Interface   Hold Uptime     SRTT    RTO  	 Q  	Seq
                                  (sec)             (ms)  Cnt 	Num
2   10.0.0.9     Tu0         13  00:00:37     1    5000  	 1  	0
0   10.0.0.5     Tu0         11	 00:00:47   1587   5000  	 0 	1483
1   10.0.0.11    Tu0         13	 00:00:56     1    5000  	 1  	0
Syslog message: 
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: 
Neighbor 10.0.0.9 (Tunnel0) is down: retry limit exceeded

Hub# show ip route eigrp
	172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Tunnel0
C    192.168.0.0/24 is directly connected, FastEthernet0/1
S*   0.0.0.0/0 [1/0] via 172.17.0.100

Verify if NHRP multicast mapping is configured properly in the hub.

In the hub, it is required to have dynamic nhrp multicast mapping configured in the hub tunnel interface.

Configuration example:

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip mtu 1400
 no ip next-hop-self eigrp 10
 ip nhrp authentication test
 ip nhrp network-id 10
 no ip split-horizon eigrp 10
 tunnel mode gre multipoint

!--- !--- Output is truncated !---

Configuration example with the correct entry for dynamic nhrp multicast mapping:

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip mtu 1400
 no ip next-hop-self eigrp 10
 ip nhrp authentication test
 ip nhrp map multicast dynamic
 ip nhrp network-id 10
 no ip split-horizon eigrp 10
 tunnel mode gre multipoint

!--- !--- Output is truncated !---

This allows NHRP to automatically add spoke routers to the multicast NHRP mappings.

For more information, refer to the ip nhrp map multicast dynamic section of NHRP Commands.

Hub#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H   Address     Interface   Hold   Uptime   SRTT    RTO     Q     Seq
                                           (sec)    (ms)   Cnt    Num
2   10.0.0.9     Tu0         12   00:16:48   13     200     0     334
1   10.0.0.11    Tu0         13   00:17:10   11     200     0     258
0   10.0.0.5     Tu0         12   00:48:44  1017    5000    0     1495

Hub#show ip route

     172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/0
D    192.168.11.0/24 [90/2944000] via 10.0.0.11, 00:16:12, Tunnel0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Tunnel0
C    192.168.0.0/24 is directly connected, FastEthernet0/1
D    192.168.2.0/24 [90/2818560] via 10.0.0.9, 00:15:45, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.17.0.100

Routes to the spokes are learned through eigrp protocol.

Problem with integrating remote-access VPN with DMVPN

Problem

DMVPN is working fine, but unable to establish the RAVPN.

Solution

Use ISAKMP profiles and IPsec profiles to achieve this.

Create separate profiles for the DMVPN and RAVPN.

For more information, refer to DMVPN and Easy VPN Server with ISAKMP Profiles Configuration Example.

Problem with dual-hub-dual-dmvpn.

Problem

Problem with dual-hub-dual-dmvpn. Specifically, tunnels are going down and unable to re-negotiate.

Solution

Use the shared keyword in the tunnel IPsec protection for both the tunnel interfaces on the hub, and on the spoke also.

Configuration example:

interface Tunnel43
 description <<tunnel to primary cloud>>
 tunnel source interface vlan10
 tunnel protection IPSec profile myprofile shared

!--- !--- Output is truncated !---

interface Tunnel44
 description <<tunnel to secondary cloud>>
 tunnel source interface vlan10
 tunnel protection IPSec profile myprofile shared

!--- !--- Output is truncated !---

For more information, refer to the tunnel protection section in Cisco IOS Security Command Reference.

Trouble logging into a server through DMVPN

Problem

Issue with accessing a server through the DMVPN network.

Solution

The problem could be related to the MTU and MSS size of the packet which is using GRE and IPsec.

Now, the packet size could be an issue with the fragmentation. To eliminate this problem, use these commands:

ip mtu 1400
ip tcp adjust-mss 1360
crypto IPSec fragmentation after-encryption (global)

You could also configure the tunnel path-mtu-discovery command to dynamically discover the MTU size.

For a more detailed explanation, refer to Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC.

Unable to access the servers on DMVPN through certain ports

Problem

Unable to access servers on DMVPN through specific ports.

Solution

Verify by disabling the IOS firewall feature set and see if it works.

If it works fine, then the problem is related to the IOS firewall config, not with the DMVPN.

Related Information

  • Dynamic Multipoint VPN (DMVPN)
  • IPSec Negotiation/IKE Protocols
  • Technical Support & Documentation — Cisco Systems

Was does the MM_NO_STATE usually mean when having errors bringing phase 1 up?

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
X.X.X.122  X.X.X.107    MM_NO_STATE          0 ACTIVE

Debug log:

Feb 18 09:25:36.732: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= X.X.X.107:500, remote= X.X.X.122:500,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0,
    protocol= ESP, transform= esp-aes 256 esp-sha256-hmac  (Tunnel), 
    lifedur= 3600s and 4608000kb, 
    spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Feb 18 09:25:36.732: ISAKMP:(0): SA request profile is (NULL)
Feb 18 09:25:36.732: ISAKMP: Created a peer struct for X.X.X.122, peer port 500
Feb 18 09:25:36.732: ISAKMP: New peer created peer = 0x21027558 peer_handle = 0x80000022
Feb 18 09:25:36.732: ISAKMP: Locking peer struct 0x21027558, refcount 1 for isakmp_initiator
Feb 18 09:25:36.732: ISAKMP: local port 500, remote port 500
Feb 18 09:25:36.732: ISAKMP: set new node 0 to QM_IDLE      
Feb 18 09:25:36.732: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 3D3B8698
Feb 18 09:25:36.732: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
Feb 18 09:25:36.732: ISAKMP:(0):found peer pre-shared key matching X.X.X.122
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-07 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-03 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-02 ID
Feb 18 09:25:36.732: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Feb 18 09:25:36.732: ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1 

Feb 18 09:25:36.732: ISAKMP:(0): beginning Main Mode exchange
Feb 18 09:25:36.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:36.732: ISAKMP:(0):Sending an IKE IPv4 Packet
Feb 18 09:25:46.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:25:46.732: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
Feb 18 09:25:46.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:25:46.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:46.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:25:51.340: ISAKMP:(0):purging node -1205386052
Feb 18 09:25:51.340: ISAKMP:(0):purging node 359996904
Feb 18 09:25:56.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:25:56.732: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
Feb 18 09:25:56.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:25:56.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:56.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:01.340: ISAKMP:(0):purging SA., sa=3D3A9E34, delme=3D3A9E34
Feb 18 09:26:06.732: IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= X.X.X.107:0, remote= X.X.X.122:0,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0
Feb 18 09:26:06.732: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= X.X.X.107:500, remote= X.X.X.122:500,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0,
    protocol= ESP, transform= esp-aes 256 esp-sha256-hmac  (Tunnel), 
    lifedur= 3600s and 4608000kb, 
    spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Feb 18 09:26:06.732: ISAKMP: set new node 0 to QM_IDLE      
Feb 18 09:26:06.732: ISAKMP:(0):SA is still budding. Attached new ipsec request to it. (local X.X.X.107, remote X.X.X.122)
Feb 18 09:26:06.732: ISAKMP: Error while processing SA request: Failed to initialize SA
Feb 18 09:26:06.732: ISAKMP: Error while processing KMI message 0, error 2.
Feb 18 09:26:06.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:06.732: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
Feb 18 09:26:06.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:06.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:06.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:16.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:16.732: ISAKMP (0): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
Feb 18 09:26:16.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:16.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:16.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:26.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:26.732: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
Feb 18 09:26:26.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:26.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:26.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:36.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:36.732: ISAKMP:(0):peer does not do paranoid keepalives.

Feb 18 09:26:36.732: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.122)
Feb 18 09:26:36.732: IPSEC(key_engine): request timer fired: count = 2,
  (identity) local= X.X.X.107:0, remote= X.X.X.122:0,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0
Feb 18 09:26:36.732: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.122) 
Feb 18 09:26:36.732: ISAKMP: Unlocking peer struct 0x21027558 for isadb_mark_sa_deleted(), count 0
Feb 18 09:26:36.732: ISAKMP: Deleting peer node by peer_reap for X.X.X.122: 21027558
Feb 18 09:26:36.732: ISAKMP:(0):deleting node 1892890669 error FALSE reason "IKE deleted"
Feb 18 09:26:36.732: ISAKMP:(0):deleting node -2013997155 error FALSE reason "IKE deleted"
Feb 18 09:26:36.732: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Feb 18 09:26:36.732: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA 

Feb 18 09:26:36.732: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Feb 18 09:27:26.732: ISAKMP:(0):purging node 1892890669
Feb 18 09:27:26.732: ISAKMP:(0):purging node -2013997155
Feb 18 09:27:36.732: ISAKMP:(0):purging SA., sa=3D3B8698, delme=3D3B869

One of the Top 10  common Cisco VPN problems are not-matching shared keys. This is an easy one to fix, but not always easy to notice, see the case below.

A simple IPsec tunnel between fast Ethernet interfaces of routers SW1 (f1/1) and R1(f0/0).

Loopback0—10.0.0.2—R1<-.2-f0/0—192.168.1/24—f1/1-.1->SW1—10.0.10.1— Loopback0

I can’t ping loopback interfaces of these routers, see below

 SW1#ping 10.0.0.2 source 10.0.10.1
                      Type escape sequence to abort.
                      Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
                      Packet sent with a source address of 10.0.10.1
                      .....
                      Success rate is 0 percent (0/5) 
                      

Open in new window

 R1#ping 10.0.10.1 source 10.0.0.2
                      Type escape sequence to abort.
                      Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
                      Packet sent with a source address of 10.0.0.2
                      .....
                      Success rate is 0 percent (0/5) 
                      

Open in new window

The configuration is simple and straightforward, see below:

 R1#sh crypto map tag VPN
                      Crypto Map "VPN" 200 ipsec-isakmp
                              Peer = 192.168.1.1
                              Extended IP access list ACL
                                  access-list ACL permit ip 10.0.0.0 0.0.0.255 10.0.10.0 0.0.0.255
                              Current peer: 192.168.1.1
                              Security association lifetime: 4608000 kilobytes/3600 seconds
                              PFS (Y/N): N
                              Transform sets={
                                      SET,
                              }
                              Interfaces using crypto map VPN:
                                      FastEthernet0/0
                      

Open in new window

 SW1#sh crypto map tag VPN
                      Crypto Map "VPN" 100 ipsec-isakmp
                              Peer = 192.168.1.2
                              Extended IP access list ACL
                                  access-list ACL permit ip 10.0.10.0 0.0.0.255 10.0.0.0 0.0.0.255
                              Current peer: 192.168.1.2
                              Security association lifetime: 4608000 kilobytes/3600 seconds
                              PFS (Y/N): N
                              Transform sets={
                                      SET,
                              }
                              Interfaces using crypto map VPN:
                                      FastEthernet1/1
                      

Open in new window

RIP is setup on both routers:

 #sh run | section router
                      router rip
                       version 2
                       network 10.0.0.0
                       network 192.168.1.0
                       no auto-summary
                      

Open in new window

See crypto configurations:

 SW1#sh run | section crypto
                      crypto isakmp policy 20
                       authentication pre-share
                      crypto isakmp key cisco address 192.168.1.2
                      crypto ipsec transform-set SET esp-des esp-sha-hmac
                      crypto map VPN 100 ipsec-isakmp
                       set peer 192.168.1.2
                       set transform-set SET
                       match address ACL
                       crypto map VPN
                      

Open in new window

 R1#sh run | section crypto
                      crypto isakmp policy 10
                       authentication pre-share
                      crypto isakmp key  cisco address 192.168.1.1
                      crypto ipsec transform-set SET esp-des esp-sha-hmac
                      crypto map VPN 200 ipsec-isakmp
                       set peer 192.168.1.1
                       set transform-set SET
                       match address ACL
                       crypto map VPN
                      

Open in new window

And interfaces:

 SW1#sh run int f1/1
                      Building configuration...
                      Current configuration : 102 bytes
                      !
                      interface FastEthernet1/1
                       no switchport
                       ip address 192.168.1.1 255.255.255.0
                       crypto map VPN
                      end
                      

Open in new window

 R1#sh run int f0/0
                      Building configuration...
                      Current configuration : 112 bytes
                      !
                      interface FastEthernet0/0
                       ip address 192.168.1.2 255.255.255.0
                       duplex auto
                       speed auto
                       crypto map VPN
                      end
                      

Open in new window

From R1 routing seems to be correct:

 R1#sh ip route
                           10.0.0.0/24 is subnetted, 2 subnets
                      R       10.0.10.0 [120/1] via 192.168.1.1, 00:00:07, FastEthernet0/0
                      C       10.0.0.0 is directly connected, Loopback0
                      C    192.168.1.0/24 is directly connected, FastEthernet0/0
                      

Open in new window

 R1#sh crypto isakmp sa
                      IPv4 Crypto ISAKMP SA
                      dst             src             state          conn-id slot status
                      IPv6 Crypto ISAKMP SA
                      

Open in new window

I cannot ping SW1 loopback from R1 loopback:

 R1#ping 10.0.10.1 source 10.0.0.2
                      Type escape sequence to abort.
                      Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
                      Packet sent with a source address of 10.0.0.2
                      .....
                      Success rate is 0 percent (0/5) 
                      

Open in new window

But Phase ‘I’ is not completed, see below:

 R1#sh crypto isakmp sa
                      IPv4 Crypto ISAKMP SA
                      dst             src             state          conn-id slot status
                      192.168.1.1     192.168.1.2     MM_KEY_EXCH       1004    0 ACTIVE
                      IPv6 Crypto ISAKMP SA
                      

Open in new window

Let’s see debug of Phase I

R1#ping 10.0.10.1 source 10.0.0.2
                      Type escape sequence to abort.
                      Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
                      Packet sent with a source address of 10.0.0.2
                      *Mar  1 00:42:59.127: ISAKMP:(0): SA request profile is (NULL)
                      *Mar  1 00:42:59.131: ISAKMP: Created a peer struct for 192.168.1.1, peer port 500
                      *Mar  1 00:42:59.135: ISAKMP: New peer created peer = 0x63B01638 peer_handle = 0x80000005
                      *Mar  1 00:42:59.139: ISAKMP: Locking peer struct 0x63B01638, refcount 1 for isakmp_initiator
                      *Mar  1 00:42:59.139: ISAKMP: local port 500, remote port 500
                      *Mar  1 00:42:59.143: ISAKMP: set new node 0 to QM_IDLE
                      *Mar  1 00:42:59.147: insert sa successfully sa = 64D7851C
                      *Mar  1 00:42:59.147: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
                      *Mar  1 00:42:59.151: ISAKMP:(0):found peer pre-shared key matching 192.168.1.1
                      *Mar  1 00:42:59.155: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
                      *Mar  1 00:42:59.159: ISAKMP:(0): constructed NAT-T vendor-07 ID
                      *Mar  1 00:42:59.163: ISAKMP:(0): constructed NAT-T vendor-03 ID
                      *Mar  1 00:42:59.163: ISAKMP:(0): constructed NAT-T vendor-02 ID
                      *Mar  1 00:42:59.167: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
                      *Mar  1 00:42:59.167: ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1
                      *Mar  1 00:42:59.171: ISAKMP:(0): beginning Main Mode exchange
                      *Mar  1 00:42:59.175: ISAKMP:(0): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_NO_STATE
                      *Mar  1 00:42:59.179: ISAKMP:(0):Sending an IKE IPv4 Packet.
                      *Mar  1 00:42:59.287: ISAKMP (0:0): received packet from 192.168.1.1 dport 500 sport 500 Global (I) MM_NO_STATE
                      *Mar  1 00:42:59.295: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
                      *Mar  1 00:42:59.295: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2
                      *Mar  1 00:42:59.347: ISAKMP:(0): processing SA payload. message ID. = 0
                      *Mar  1 00:42:59.347: ISAKMP:(0): processing vendor id payload
                      *Mar  1 00:42:59.351: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
                      *Mar  1 00:42:59.351: ISAKMP (0:0): vendor ID is NAT-T RFC 3947
                      *Mar  1 00:42:59.355: ISAKMP:(0):found peer pre-shared key matching 192.168.1.1
                      *Mar  1 00:42:59.355: ISAKMP:(0): local preshared key found
                      *Mar  1 00:42:59.355: ISAKMP : Scanning profiles for xauth ...
                      *Mar  1 00:42:59.355: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
                      *Mar  1 00:42:59.355: ISAKMP:      encryption DES-CBC
                      *Mar  1 00:42:59.355: ISAKMP:      hash SHA
                      *Mar  1 00:42:59.355: ISAKMP:      default group 1
                      *Mar  1 00:42:59.355: ISAKMP:      auth pre-share
                      *Mar  1 00:42:59.355: ISAKMP:      life type in seconds
                      *Mar  1 00:42:59.355: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
                      *Mar  1 00:42:59.355: ISAKMP:(0):atts are acceptable. Next payload is 0
                      *Mar  1 00:42:59.355: ISAKMP:(0):Acceptable atts:actual life: 0
                      *Mar  1 00:42:59.355: ISAKMP:(0):Acceptable atts:life: 0
                      *Mar  1 00:42:59.355: ISAKMP:(0):Fill atts in sa vpi_length:4
                      *Mar  1 00:42:59.359: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
                      *Mar  1 00:42:59.359: ISAKMP:(0):Returning Actual lifetime: 86400
                      *Mar  1 00:42:59.363: ISAKMP:(0)::Started lifetime timer: 86400.
                      *Mar  1 00:42:59.363: ISAKMP:(0): processing vendor id payload
                      *Mar  1 00:42:59.367: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
                      *Mar  1 00:42:59.371: ISAKMP (0:0): vendor ID is NAT-T RFC 3947
                      *Mar  1 00:42:59.371: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
                      *Mar  1 00:42:59.371: ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2
                      *Mar  1 00:42:59.371: ISAKMP:(0): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_SA_SETUP
                      *Mar  1 00:42:59.371: ISAKMP:(0):Sending an IKE IPv4 Packet.
                      *Mar  1 00:42:59.375: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
                      *Mar  1 00:42:59.375: ISAKMP:(0):Old State = IKE_I_M.M2  New State = IKE_I_MM3
                      *Mar  1 00:42:59.523: ISAKMP (0:0): received packet from 192.168.1.1 dport 500 sport 500 Global (I) MM_SA_SETUP
                      *Mar  1 00:42:59.527: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
                      *Mar  1 00:42:59.531: ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4
                      *Mar  1 00:42:59.543: ISAKMP:(0): processing KE payload. message ID = 0
                      *Mar  1 00:42:59.635: ISAKMP:(0): processing NONCE payload. message ID = 0
                      *Mar  1 00:42:59.635: ISAKMP:(0):found peer pre-shared key matching 192.168.1.1
                      *Mar  1 00:42:59.635: ISAKMP:(1004): processing vendor id payload
                      *Mar  1 00:42:59.635: ISAKMP:(1004): vendor ID is Unity
                      *Mar  1 00:42:59.635: ISAKMP:(1004): processing vendor id payload
                      *Mar  1 00:42:59.635: ISAKMP:(1004): vendor ID is DPD
                      *Mar  1 00:42:59.635: ISAKMP:(1004): processing vendor id payload
                      *Mar  1 00:42:59.635: ISAKMP:(1004): speaking to another IOS box!
                      *Mar  1 00:42:59.635: ISAKMP:received payload type 20
                      *Mar  1 00:42:59.635: ISAKMP:received payload type 20
                      *Mar  1 00:42:59.635: ISAKMP:(1004):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
                      *Mar  1 00:42:59.635: ISAKMP:(1004):Old State = IKE_I_MM4  New State = IKE_I_MM4
                      *Mar  1 00:42:59.635: ISAKMP:(1004):Send initial contact
                      *Mar  1 00:42:59.635: ISAKMP:(1004):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
                      *Mar  1 00:42:59.635: ISAKMP (0:1004): ID payload
                              next-payload : 8
                              type         : 1
                              address      : 192.168.1.2
                              protocol     : 17
                              port         : 500
                              length       : 12
                      *Mar  1 00:42:59.635: ISAKMP:(1004):Total payload length: 12
                      *Mar  1 00:42:59.635: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:42:59.635: ISAKMP:(1004):Sending an IKE IPv4 Packet.
                      *Mar  1 00:42:59.639: ISAKMP:(1004):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
                      *Mar  1 00:42:59.639: ISAKMP:(1004):Old State = IKE_I_MM4  New State = IKE_I_MM5
                      *Mar  1 00:43:00.743: ISAKMP (0:1004): received packe.t from 192.168.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
                      *Mar  1 00:43:00.747: ISAKMP:(1004): phase 1 packet is a duplicate of a previous packet.
                      *Mar  1 00:43:00.751: ISAKMP:(1004): retransmitting due to retransmit phase 1
                      *Mar  1 00:43:01.251: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH...
                      *Mar  1 00:43:01.251: ISAKMP (0:1004): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
                      *Mar  1 00:43:01.255: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH
                      *Mar  1 00:43:01.259: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:43:01.263: ISAKMP:(1004):Sending an IKE IPv4 Packet...
                      Success rate is 0 percent (0/5)
                      R1#
                      *Mar  1 00:43:11.267: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH...
                      *Mar  1 00:43:11.271: ISAKMP (0:1004): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
                      *Mar  1 00:43:11.271: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH
                      *Mar  1 00:43:11.275: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:43:11.279: ISAKMP:(1004):Sending an IKE IPv4 Packet.
                      *Mar  1 00:43:11.879: ISAKMP (0:1004): received packet from 192.168.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
                      *Mar  1 00:43:11.883: ISAKMP:(1004): phase 1 packet is a duplicate of a previous packet.
                      R1#
                      *Mar  1 00:43:11.887: ISAKMP:(1004): retransmission skipped for phase 1 (time since last transmission 600)
                      R1#
                      *Mar  1 00:43:21.283: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH...
                      *Mar  1 00:43:21.287: ISAKMP (0:1004): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
                      *Mar  1 00:43:21.287: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH
                      *Mar  1 00:43:21.291: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:43:21.295: ISAKMP:(1004):Sending an IKE IPv4 Packet.
                      *Mar  1 00:43:21.927: ISAKMP (0:1004): received packet from 192.168.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
                      *Mar  1 00:43:21.931: ISAKMP:(1004): phase 1 packet is a duplicate of a previous packet.
                      R1#
                      *Mar  1 00:43:21.935: ISAKMP:(1004): retransmission skipped for phase 1 (time since last transmission 632)
                      R1#
                      *Mar  1 00:43:29.127: ISAKMP: set new node 0 to QM_IDLE
                      *Mar  1 00:43:29.131: ISAKMP:(1004):SA is still budding. Attached new ipsec request to it. (local 192.168.1.2, remote 192.168.1.1)
                      *Mar  1 00:43:29.135: ISAKMP: Error while processing SA request: Failed to initialize SA
                      *Mar  1 00:43:29.135: ISAKMP: Error while processing KMI message 0, error 2.
                      R1#
                      *Mar  1 00:43:31.299: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH...
                      *Mar  1 00:43:31.303: ISAKMP (0:1004): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
                      *Mar  1 00:43:31.303: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH
                      *Mar  1 00:43:31.307: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:43:31.311: ISAKMP:(1004):Sending an IKE IPv4 Packet.
                      *Mar  1 00:43:31.851: ISAKMP (0:1004): received packet from 192.168.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
                      *Mar  1 00:43:31.855: ISAKMP:(1004): phase 1 packet is a duplicate of a previous packet.
                      R1#
                      *Mar  1 00:43:31.859: ISAKMP:(1004): retransmission skipped for phase 1 (time since last transmission 540)
                      R1#
                      *Mar  1 00:43:41.315: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH...
                      *Mar  1 00:43:41.319: ISAKMP (0:1004): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
                      *Mar  1 00:43:41.319: ISAKMP:(1004): retransmitting phase 1 MM_KEY_EXCH
                      *Mar  1 00:43:41.323: ISAKMP:(1004): sending packet to 192.168.1.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
                      *Mar  1 00:43:41.327: ISAKMP:(1004):Sending an IKE IPv4 Packet.
                      R1#
                      

Open in new window

 

The solution lays in the ISAKMP key. At first look keyword ‘cisco’ on both routers is exactly the same but look closer at these lines shows

R1 and SW1:

crypto isakmp key  cisco address 192.168.1.1
crypto isakmp key cisco address 192.168.1.2

that there is a space before it on Router R1

Let’s fix it and see what’s happen:

 R1#conf t
                      Enter configuration commands, one per line.  End with CNTL/Z.
                      R1(config)#no crypto isakmp key  cisco address 192.168.1.1
                      R1(config)#crypto isakmp key "cisco" address 192.168.1.1
                      

Open in new window

 R1#ping 10.0.10.1 source 10.0.0.2
                      Type escape sequence to abort.
                      Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
                      Packet sent with a source address of 10.0.0.2
                      .!!!!
                      Success rate is 80 percent (4/5), round-trip min/avg/max = 92/173/252 ms
                      

Open in new window

 R1#sh crypto isakmp sa
                      IPv4 Crypto ISAKMP SA
                      dst             src             state          conn-id slot status
                      192.168.1.1     192.168.1.2     QM_IDLE           1006    0 ACTIVE
                      192.168.1.1     192.168.1.2     MM_NO_STATE       1005    0 ACTIVE (deleted)
                      IPv6 Crypto ISAKMP SA
                      

Open in new window

 R1#sh crypto ipsec sa
                      interface: FastEthernet0/0
                          Crypto map tag: VPN, local addr 192.168.1.2
                         protected vrf: (none)
                         local  ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
                         remote ident (addr/mask/prot/port): (10.0.10.0/255.255.255.0/0/0)
                         current_peer 192.168.1.1 port 500
                           PERMIT, flags={origin_is_acl,}
                          #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
                          #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
                      

Open in new window

So it’s working now

Paladin


  • Add bookmark

  • #1

So I’m helping a guy setup a VPN between his ASA5505 and a Cisco 2801 ISR (probably running 12.3 or 12.4 code, not sure, don’t have access to it). The 2801 is run by another company but they provided the basic config outline for the VPN setup and the key and IP info etc. So we got it all setup and of course it won’t bring up the tunnel.

Here are the (obfuscated but accurate) details:

Config on the ASA:

Code:

access-list outside_access_inextended extended permit icmp any any 
access-list inside_access_in extended permit ip any any 
access-list inside_nat0_outbound extended permit ip 10.100.200.0 255.255.255.192 host 10.250.250.150 
access-list fptrading extended permit ip 10.100.200.0 255.255.255.192 host 10.250.250.150 
nat (inside) 0 access-list inside_nat0_outbound
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac 
crypto ipsec security-association lifetime seconds 86400
crypto ipsec security-association lifetime kilobytes 4608000
crypto map newmap 20 match address fptrading
crypto map newmap 20 set peer 5.6.7.8 
crypto map newmap 20 set transform-set ESP-AES-256-SHA
crypto map newmap 20 set security-association lifetime seconds 86400
crypto map newmap interface outside
crypto isakmp identity address 
crypto isakmp enable outside
crypto isakmp policy 2
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
crypto isakmp nat-traversal  60
crypto isakmp disconnect-notify
tunnel-group 5.6.7.8 type ipsec-l2l
tunnel-group 5.6.7.8 ipsec-attributes
 pre-shared-key *

Config on the 2801 (as it was emailed to me, I hope it is accurate):

Code:

! 
crypto keyring ASAuserEnd pre-shared-key address 22.22.22.1 key ******** 
! 
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2
!
crypto isakmp profile ISAKMP-ASAuserEnd
description Profile for LAN-to-LAN VPN to ASAuserEnd
keyring ASAuserEnd
match identity address 22.22.22.1 255.255.255.255
!
crypto ipsec transform-set TRANSFORM-AES256-SHA esp-aes 256 esp-sha-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer 22.22.22.1
set transform-set TRANSFORM-AES256-SHA
set isakmp-profile ISAKMP-ASAuserEnd
match address ASAuserEnd
!
ip access-list extended ASAuserEnd
permit ip 10.250.250.150 0.0.0.0 10.100.200.0 0.0.0.63
!
ip route 10.100.200.0 255.255.255.192 22.22.22.1

Debug output from the ASA:

Code:

%ASA-5-713041: IP = 5.6.7.8, IKE Initiator: New Phase 1, Intf inside, IKE Peer 5.6.7.8  local Proxy Address 10.100.200.0, remote Proxy Address 10.250.250.150,  Crypto map (newmap)
%ASA-5-111005: 22.22.22.1 end configuration: OK
%ASA-6-713219: IP = 5.6.7.8, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
%ASA-6-713219: IP = 5.6.7.8, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
%ASA-6-713219: IP = 5.6.7.8, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
%ASA-6-713219: IP = 5.6.7.8, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
%ASA-6-713219: IP = 5.6.7.8, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
%ASA-3-713902: IP = 5.6.7.8, Removing peer from peer table failed, no match!
%ASA-4-713903: IP = 5.6.7.8, Error: Unable to remove PeerTblEntry

Debug output from the 2801:

Code:

*Feb 17 20:15:34.821: IPSEC(sa_request): , 
 (key eng. msg.) OUTBOUND local= 5.6.7.8:500, remote= 22.22.22.1:500,
 local_proxy= 10.250.250.150/255.255.255.255/0/0 (type=1), 
 remote_proxy= 10.100.210.0/255.255.255.192/0/0 (type=4), 
 protocol= ESP, 
 transform= esp-aes 256 esp-sha-hmac (Tunnel), 
 lifedur= 3600s and 4608000kb, 
 spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0 
 
*Feb 17 20:15:34.825: ISAKMP:(0): SA request profile is ISAKMP-ASAuserEnd 
*Feb 17 20:15:34.825: ISAKMP: Created a peer struct for 22.22.22.1, peer port 500 
*Feb 17 20:15:34.825: ISAKMP: New peer created peer = 0x490BD3A8 peer_handle = 0x80000003 
*Feb 17 20:15:34.825: ISAKMP: Locking peer struct 0x490BD3A8, refcount 1 for isakmp_initiator 
*Feb 17 20:15:34.825: ISAKMP: local port 500, remote port 500 
*Feb 17 20:15:34.825: ISAKMP: set new node 0 to QM_IDLE 
*Feb 17 20:15:34.825: ISAKMP:(0):insert sa successfully sa = 4A6B827C 
*Feb 17 20:15:34.825: ISAKMP:(0):Can not start Aggressive mode, trying Main mode . 
*Feb 17 20:15:34.825: ISAKMP:(0):Found ADDRESS key in keyring ASAuserEnd 
*Feb 17 20:15:34.825: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID 
*Feb 17 20:15:34.825: ISAKMP:(0): constructed NAT-T vendor-07 ID 
*Feb 17 20:15:34.825: ISAKMP:(0): constructed NAT-T vendor-03 ID 
*Feb 17 20:15:34.825: ISAKMP:(0): constructed NAT-T vendor-02 ID 
*Feb 17 20:15:34.825: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM 
*Feb 17 20:15:34.825: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1 
*Feb 17 20:15:34.825: ISAKMP:(0): beginning Main Mode exchange 
*Feb 17 20:15:34.825: ISAKMP:(0): sending packet to 22.22.22.1 my_port 500 peer_port 500 (I) MM_NO_STATE 
*Feb 17 20:15:34.825: ISAKMP:(0):Sending an IKE IPv4 Packet. 
*Feb 17 20:15:44.829: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE... 
*Feb 17 20:15:44.829: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1 
*Feb 17 20:15:44.829: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE 
*Feb 17 20:15:44.829: ISAKMP:(0): sending packet to 22.22.22.1 my_port 500 peer_port 500 (I) MM_NO_STATE 
*Feb 17 20:15:44.829: ISAKMP:(0):Sending an IKE IPv4 Packet. 
*Feb 17 20:15:54.829: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE... 
*Feb 17 20:15:54.829: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1

The error «Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.» on the ASA indicates to me that phase 1 is phailing. ;)

The question is why? So far as I can tell the key matches, the encryption and hash match, and the IPs for the peers are correct. From what I know, there are no unusual network design problems in between these devices, just plain old internet service.

I have a conference call hopefully with someone on Monday to actually look at the router config and tell me more for certain how it is setup and maybe walk through changing the key to be safe but, anyone have anything like this before?

Of course, now that I look at it all spread out like that, I wonder if they might be running IOS 15.x and have SHA2 support?

Arbelac

Ars Tribunus Angusticlavius


  • Add bookmark

  • #2

You’ve checked to make sure the PSKs actually match right?

  • Add bookmark

  • #3

You got a NAT issue, at first glance.

IKE schemes match, and most every other config issuee is encyption domain (typically masking). Seems your not getting response packets during the phase 1 portion.

Paladin


  • Add bookmark

  • #4

Well, I hope the keys match. I am using the one they provided. Hopefully Monday I will get someone on the phone to go through trying a different key live with me.

The NAT on the other end is the part that is completely unknown to me. As usual I was brought in when this customer fired their IT guy after he failed to get this running after who knows how long, plus whatever else he failed at. I’m not sure if the other end has their NAT stuff setup right or not. From their config excerpt they make no mention of it but they could have just omitted it since it has no bearing on my config.

Paladin


  • Add bookmark

  • #5

Well, after many scheduling conflicts and aborted attempts at a conference call (and in the mean time, me upgrading the firewall from 7.2.5 to 8.2 then 8.4 and eventually swapping the hardware with another 5505 I had on the shelf), I finally got on the phone with the guys at the other end of the VPN.

They didn’t even really bother to ask me about my setup, just confirmed that it was an ASA and that I had the correct IP for their end and key for the setup. Then the 2 guys I got on the phone spent the rest of an hour going back and forth between them, trying to login to various routers, modifying access lists and even giving out their internal IPs and passwords for various routers (plus some entertaining cursing and condemning of their arcane network design).

I spent the time assembling and putting the water transfer decals on this:

Eventually they found an access-list on a router they didn’t even thing was involved that was blocking pretty much everything but a few TCP ports and ICMP. Once they added ESP protocol and UDP 500, bing! Tunnel came up and all was well with the world again.

It’s funny how I went back and forth through email with them for hours but the moment I got on the phone with them they pretty much just knew that their network was a steaming pile of spaghetti and spent the whole time tearing it up (literally and verbally). :rolleyes:

Fortunately my customer understood and is very happy with my work since it turned out to not be my fault. :D

Paladin


  • Add bookmark

  • #8

Yup, Chara-works Macross 1/144 scale (about 4 inches in length). Basically it is a step up from gashapon (Japanese vending machine toys). The wings are articulated quite nicely and you have to put the decals on and the landing gear if you want. It is part of a collection with 6 other variants that come in a blind box so you don’t know which you will get when you buy it. That one is the ‘secret’ item of the collection. I’m sorely tempted to buy the rest of the collection on Amazon for another $40 or so. :D

That one was flown by Hayao Kakizaki who was killed in like the second mission in the show I think. Pretty much made one appearance and was bumped off. :(

I have a couple of Revoltech Macross Battroid mode figures that don’t transform but are super posable too. If I ever find a really good source, I’ll see about getting some of the 1/60 scale transforming versions that are mostly die-cast, but they cost more like $200 and up so… yeah.

I’ve been trying to get DMVPN working behind NAT/PAT, however I’m running into a wall with ISAKMP NAT-T. Cisco’s docs say 12.2(13)T and newer should have support and no configuration is needed as the two peers will automatically detect and negotiate NAT-T. The hub is an older 3745 running 12.4 and the spoke is an 819 running 15.3.

Looking at the debugs I do see some indication of this initially, but during Main Mode exchange it doesn’t actually appear to negotiate NAT-T and just uses udp/500 until it reaches death by retransmission.

I’m at a bit of a loss and not sure what else to look at so any help is appreciated.

.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): SA request profile is (NULL)
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: Created a peer struct for $HUBIP, peer port 500
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: New peer created peer = 0xFDD5908 peer_handle = 0x800003BD
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: Locking peer struct 0xFDD5908, refcount 1 for isakmp_initiator
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: local port 500, remote port 500
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: set new node 0 to QM_IDLE
.Dec 12 2015 19:19:32.800 UTC: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 39C68168
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0):found peer pre-shared key matching $HUBIP
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): constructed NAT-T vendor-07 ID
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): constructed NAT-T vendor-03 ID
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): constructed NAT-T vendor-02 ID
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): beginning Main Mode exchange
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:19:32.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:19:42.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:19:42.800 UTC: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
.Dec 12 2015 19:19:42.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
.Dec 12 2015 19:19:42.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:19:42.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:19:52.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:19:52.800 UTC: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
.Dec 12 2015 19:19:52.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
.Dec 12 2015 19:19:52.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:19:52.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:20:02.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:20:02.800 UTC: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
.Dec 12 2015 19:20:02.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
.Dec 12 2015 19:20:02.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:20:02.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:20:02.800 UTC: ISAKMP: set new node 0 to QM_IDLE
.Dec 12 2015 19:20:02.800 UTC: ISAKMP:(0):SA is still budding. Attached new ipsec request to it. (local $NATIP, remote $HUBIP)
.Dec 12 2015 19:20:02.800 UTC: ISAKMP: Error while processing SA request: Failed to initialize SA
.Dec 12 2015 19:20:02.800 UTC: ISAKMP: Error while processing KMI message 0, error 2.
.Dec 12 2015 19:20:12.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:20:12.800 UTC: ISAKMP (0): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
.Dec 12 2015 19:20:12.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
.Dec 12 2015 19:20:12.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:20:12.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:20:22.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:20:22.800 UTC: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
.Dec 12 2015 19:20:22.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
.Dec 12 2015 19:20:22.800 UTC: ISAKMP:(0): sending packet to $HUBIP my_port 500 peer_port 500 (I) MM_NO_STATE
.Dec 12 2015 19:20:22.800 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):peer does not do paranoid keepalives.
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer $HUBIP)
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer $HUBIP)
.Dec 12 2015 19:20:32.800 UTC: ISAKMP: Unlocking peer struct 0xFDD5908 for isadb_mark_sa_deleted(), count 0
.Dec 12 2015 19:20:32.800 UTC: ISAKMP: Deleting peer node by peer_reap for $HUBIP: FDD5908
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):deleting node -699787086 error FALSE reason "IKE deleted"
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):deleting node 749384040 error FALSE reason "IKE deleted"
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
.Dec 12 2015 19:20:32.800 UTC: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA
.Dec 12 2015 19:21:22.800 UTC: ISAKMP:(0):purging node -699787086
.Dec 12 2015 19:21:22.800 UTC: ISAKMP:(0):purging node 749384040
.Dec 12 2015 19:21:32.800 UTC: ISAKMP:(0):purging SA., sa=39C68168, delme=39C68168

I would appreciate any insight/solutions to my issue.  One of our VPN tunnels had the service changed at one of the endpoint from DSL to Fibre.  A new IP address has been set up for the remote location.  I have tried going over and over this, but I can’t seem to locate the cause.  When I changed the remote endpoints IP address the tunnel never completes the setup.  On one end, I will get a QM_IDLE but shortly after another MM_KEY_EXCH begins and the idle connection shows MM_NO_STATE 

debug isakmp shows:

007097: Jun 11 09:50:09.897 CDT: ISAKMP (0:2059): received packet from N.E.W.IP dport 500 sport 500 Global (R) QM_IDLE  
007098: Jun 11 09:50:09.897 CDT: ISAKMP:(2059): phase 1 packet is a duplicate of a previous packet.
007099: Jun 11 09:50:09.897 CDT: ISAKMP:(2059): retransmitting due to retransmit phase 1
007100: Jun 11 09:50:10.397 CDT: ISAKMP:(2059): retransmitting phase 1 QM_IDLE      …
007101: Jun 11 09:50:10.397 CDT: ISAKMP (0:2059): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
007102: Jun 11 09:50:10.397 CDT: ISAKMP:(2059): retransmitting phase 1 QM_IDLE
007103: Jun 11 09:50:10.397 CDT: ISAKMP:(2059): sending packet to N.E.W.IP my_port 500 peer_port 500 (R) QM_IDLE
007104: Jun 11 09:50:19.897 CDT: ISAKMP (0:2059): received packet from N.E.W.IP dport 500 sport 500 Global (R) QM_IDLE  
007105: Jun 11 09:50:19.897 CDT: ISAKMP:(2059): phase 1 packet is a duplicate of a previous packet.
007106: Jun 11 09:50:19.897 CDT: ISAKMP:(2059): retransmitting due to retransmit phase 1
007107: Jun 11 09:50:20.397 CDT: ISAKMP:(2059): retransmitting phase 1 QM_IDLE      …
007108: Jun 11 09:50:20.397 CDT: ISAKMP (0:2059): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
007109: Jun 11 09:50:20.397 CDT: ISAKMP:(2059): retransmitting phase 1 QM_IDLE
etc.

*

*

*
*
*
007454: Jun 11 09:53:12.456 CDT: ISAKMP:(2062): sending packet to N.E.W.IP my_port 500 peer_port 500 (R) MM_KEY_EXCH
007455: Jun 11 09:53:12.456 CDT: ISAKMP:(2062):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
007456: Jun 11 09:53:12.456 CDT: ISAKMP:(2062):Old State = IKE_R_MM5  New State = IKE_P1_COMPLETE

007457: Jun 11 09:53:12.456 CDT: ISAKMP:(2061):deleting SA reason «No reason» state (R) QM_IDLE       (peer N.E.W.IP)
007458: Jun 11 09:53:12.456 CDT: ISAKMP: Unlocking peer struct 0x84371818 for isadb_mark_sa_deleted(), count 1
007459: Jun 11 09:53:12.456 CDT: ISAKMP:(2061):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
007460: Jun 11 09:53:12.456 CDT: ISAKMP:(2061):Old State = IKE_DEST_SA  New State = IKE_DEST_SA

007461: Jun 11 09:53:12.456 CDT: ISAKMP:(2062):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
007462: Jun 11 09:53:12.456 CDT: ISAKMP:(2062):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

config for the new tunnel is exactly the same as the old tunnel except for the new IP address

any suggestions?

Ray

Понравилась статья? Поделить с друзьями:
  • Incorrect skeleton type for anim 552 at creation как исправить
  • Incorrect path to ini file как исправить
  • Incorrect media paths media in config file expect some media to be missing как исправить
  • Incomplete session by time out ошибка принтера
  • Incompatible program detected как исправить