CPN Client problem after replace 2621 with 2901

Unanswered Question
Sep 13th, 2010

Hello,


i replace a 2621XM router with a 2901 Router, now i have e problem with the Cisco VPN Client Version 5

The connection hangs on State IKE_R_AM2 but i don't know why.


Note: Static IPSEC connections works.


Thanks for your help

Michael.

Sep 12 23:46:15   8868: Sep 12 23:46:15: ISAKMP:(0):Fill atts in sa vpi_length:4
Sep 12 23:46:15   8869: Sep 12 23:46:15: ISAKMP:(0):Fill atts in sa life_in_seconds:2147483
Sep 12 23:46:15   8870: Sep 12 23:46:15: ISAKMP:(0):Returning Actual lifetime: 86400
Sep 12 23:46:15   8871: Sep 12 23:46:15: ISAKMP:(0)::Started lifetime timer: 86400.
Sep 12 23:46:15   8872:
Sep 12 23:46:15   8873: Sep 12 23:46:15: ISAKMP:(0): processing KE payload. message ID = 0
Sep 12 23:46:15   8874: Sep 12 23:46:15: ISAKMP:(0): processing NONCE payload. message ID = 0
Sep 12 23:46:15   8875: Sep 12 23:46:15: ISAKMP:(0): vendor ID is NAT-T v2
Sep 12 23:46:15   8876: Sep 12 23:46:15: AAA/AUTHOR (0x24): Pick method list 'groupauthor'
Sep 12 23:46:15   8877: Sep 12 23:46:15: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
Sep 12 23:46:15   8878: Sep 12 23:46:15: ISAKMP:(0):Old State = IKE_READY  New State = IKE_R_AM_AAA_AWAIT
Sep 12 23:46:15   8879:
Sep 12 23:46:15   8880: Sep 12 23:46:15: AAA SRV(00000024): process author req
Sep 12 23:46:15   8881: Sep 12 23:46:15: AAA SRV(00000024): Author method=LOCAL
Sep 12 23:46:15   8882: Sep 12 23:46:15: AAA SRV(00000024): protocol reply PASS for Authorization
Sep 12 23:46:15   8883: Sep 12 23:46:15: AAA SRV(00000024): Return Authorization status=PASS
Sep 12 23:46:15   8884: Sep 12 23:46:15: ISAKMP:(1033): constructed NAT-T vendor-02 ID
Sep 12 23:46:15   8885: Sep 12 23:46:15: ISAKMP:(1033):SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
Sep 12 23:46:15   8886: Sep 12 23:46:15: ISAKMP (1033): ID payload
Sep 12 23:46:15   8887:         next-payload : 10
Sep 12 23:46:15   8888:         type         : 1
Sep 12 23:46:15   8889:         address      : 79.2.x.xx
Sep 12 23:46:15   8890:         protocol     : 0
Sep 12 23:46:15   8891:         port         : 0
Sep 12 23:46:15   8892:         length       : 12
Sep 12 23:46:15   8893: Sep 12 23:46:15: ISAKMP:(1033):Total payload length: 12
Sep 12 23:46:16   8894: Sep 12 23:46:15: ISAKMP:(1033): sending packet to 91.62.130.220 my_port 500 peer_port 51041 (R) AG_INIT_EXCH
Sep 12 23:46:16   8895: Sep 12 23:46:15: ISAKMP:(1033):Sending an IKE IPv4 Packet.
Sep 12 23:46:16   8896: Sep 12 23:46:15: ISAKMP:(1033):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
Sep 12 23:46:16   8897: Sep 12 23:46:15: ISAKMP:(1033):Old State = IKE_R_AM_AAA_AWAIT  New State = IKE_R_AM2
Sep 12 23:46:16   8898:
Sep 12 23:46:26   8899: Sep 12 23:46:25: ISAKMP:(1033): retransmitting phase 1 AG_INIT_EXCH...
Sep 12 23:46:26   8900: Sep 12 23:46:25: ISAKMP (1033): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
Sep 12 23:46:26   8901: Sep 12 23:46:25: ISAKMP:(1033): retransmitting phase 1 AG_INIT_EXCH
Sep 12 23:46:26   8902: Sep 12 23:46:25: ISAKMP:(1033): sending packet to 91.62.130.220 my_port 500 peer_port 51041 (R) AG_INIT_EXCH

Sep 12 23:46:15   8865: Sep 12 23:46:15: ISAKMP:(0):atts are acceptable. Next payload is 3
Sep 12 23:46:15   8866: Sep 12 23:46:15: ISAKMP:(0):Acceptable atts:actual life: 86400
Sep 12 23:46:15   8867: Sep 12 23:46:15: ISAKMP:(0):Acceptable atts:life: 0

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
praprama Mon, 09/13/2010 - 00:49

Hi Mike,

I am not sure why changing the router would cause such a behavior but based on the debugs from the router, it looks like the router is replying to the first packet from the VPN client but never receives a packet in response to that. My suspicion is that this second aggressive mode exchange from the router is getting blocked somewhere. Can you send the config from the router and also the logs from the VPN client?

Thanks and Regards,

Prapanch

gosystemelektronik Mon, 09/13/2010 - 12:34

Hi Prapanch,

i found the problem.

The answer is

no crypto ipsec nat-transparency udp-encaps

thank you,

  Michael.

Actions

This Discussion

Related Content