Can anyone tell me what is going wrong here?

Answered Question
Aug 1st, 2008

Trying to establish an ipsec vpn connection to a remote site but also have the router configured for cisco vpn client connections.

debug crypto isakmp output in the attatched file:

Thanks in advance

I have this problem too.
0 votes
Correct Answer by Richard Burts about 8 years 2 months ago


Thanks for the clarification. Since we are not finding the problem when we look on your router, perhaps we should look at the other end. What can you tell us about the device on the other end of the VPN and how it is configured?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Daniel Voicu Fri, 08/01/2008 - 04:21


Where is the problem? With the site to site or the VPN client.

What happens usually when you have both enabled on a router is that for the site to site you need to specify that no client authentication is required:

crypto isakmp key xxx address xxx no-xauth

"Without the ability to disable Xauth, a user cannot select which peer on the same crypto map should use Xauth. That is, if a user has router-to-router IP security (IPSec) on the same crypto map as a virtual private network (VPN)-client-to-Cisco-IOS IPSec, both peers are prompted for a username and password."

For more info:

Please rate if this helped.



rnsimpson Sat, 08/02/2008 - 12:02

Hi Daniel,

The vpn clients work fine, it is the site to site one that I am having trouble with.

show crypto isakmp sa shows the peer MM_NO_STATE

It seems to get through phase 1 ok but then the sa is deleted.

The messages below are from the logs and this is where it looks to be going wrong?

19:54:55.959: ISAKMP:(2259):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

19:54:55.983: ISAKMP (0:2259): received packet from dport 500 sport 500 Global (I) QM_IDLE

19:54:55.983: ISAKMP: set new node 756490430 to QM_IDLE

19:54:55.983: ISAKMP:(2259): processing HASH payload. message ID = 756490430

19:54:55.983: ISAKMP:received payload type 18

19:54:55.983: ISAKMP:(2259): processing DELETE_WITH_REASON payload, message ID = 756490430, reason: Unknown delete reason!

19:54:55.983: ISAKMP:(2259):peer does not do paranoid keepalives.

19:54:55.983: ISAKMP:(2259):deleting SA reason "No error" state (I) QM_IDLE (peer

19:54:55.983: ISAKMP:(2259):deleting node 756490430 error FALSE reason "Informational (in) state 1"

Richard Burts Sat, 08/02/2008 - 12:57


It would help us to see what is going wrong if you would post the configuration of the router.



rnsimpson Sat, 08/02/2008 - 13:09

Hi Rick,

I have attached the relevant parts of the routers configuration. If there is anything missing please let me know.

Kind regards,


Richard Burts Sat, 08/02/2008 - 15:20


I believe that Daniel correctly identified the issue in his post as being related to xauth. For user (software client) VPN the router needs to authenticate the remote by prompting for ID and password and needs to authenticate them. But for site to site vpn the router should not prompt for ID and password. You achieve this by adding a parameter on the pre-shared-key command. I suggest that you try this and see if it works better:

crypto keyring ltnz

pre-shared-key address key xxxxxx no-xauth



rnsimpson Sat, 08/02/2008 - 16:20

Hi Rick,

There is no option to add no-xauth at the end of that line under the keyring config.

So instead I removed the keyring and just added

crypto isakmp key xxxx address x.x.x.x no-xauth

crypto isakmp profile ltnz

keyring default

I ran some more tests but still nothing has changed.

It seems very strange, especially the debug line below

00:11:02.894: ISAKMP:(2074): processing DELETE_WITH_REASON payload, message ID = 1453285237, reason: Unknown delete reason!

Your help is much appreciated.

Kind regards,


Richard Burts Sat, 08/02/2008 - 18:13


I had hoped that the no-xauth would fix the issue. But if it does not then we will look for something else. Since the debug that you posted shows that the peers get through Main mode negotiation and have problems in Quick mode, then I wonder if the output of debug crypto ipsec might have something helpful.

And it would be a good idea to check the IPSec parameters on this router against the parameters on the other router to be sure that there is not some mismatch.



rnsimpson Sat, 08/02/2008 - 18:25

Hi Rick,

Please the the attached file for debug crypto ipsec output.

Kind regards,


Richard Burts Sat, 08/02/2008 - 19:02


Thanks for the debug output. It seems to be not as helpful as I had hoped. I am very curious about this line in the debug:

protocol= ESP, transform= NONE (Tunnel),

it puzzles me about the transform.

Perhaps it might help if you would post the output of show crypto map from the router.



Richard Burts Sun, 08/03/2008 - 14:15


I am a bit puzzled. The config that you posted shows this for the transform set:

set transform-set LTNZ2

But the output of show crypto map shows that the transform is

Transform sets={



Can you shed any light on this?



rnsimpson Sun, 08/03/2008 - 14:56

Hi Rick,

Sorry yeah as part of my troubleshooting I created a second transform set named LTNZ2 and that is the one that was in use when I captured the config. I found that no matter which transform set I used the debug output was always the same.

Correct Answer
Richard Burts Sun, 08/03/2008 - 18:23


Thanks for the clarification. Since we are not finding the problem when we look on your router, perhaps we should look at the other end. What can you tell us about the device on the other end of the VPN and how it is configured?



rnsimpson Sun, 08/03/2008 - 18:35

Hi Rick

The other end is a checkpoint firewall. As it is not under my control I have asked them to send the logs through to me and will post an update shortly.

Kind regards,


cisco24x7 Sun, 08/17/2008 - 16:14

Were you able to solve the issue? If not,

ask the Checkpoint Firewall engineer to do


1- log into the firewall, NOT the SmartCenter via ssh,

2- type "vpn debug ikeoff",

3- type "vpn debug trunc"

4- type "vpn debug ikeon"

5- initiate traffics from either side,

6- get the ike.elg file in the $FWDIR/log


7- Use IkeView.exe to examine. It will tell

you EXACTLY why your VPN is not working.

8- Checkpoint troubleshooting is about 20

times better than Cisco.

Let me know if you need additional help

rnsimpson Sun, 08/17/2008 - 21:16

Hi there,

Yes it turns out there was a problem with the configuration at the checkpoint end. They have resolved this and now the vpn works fine.

Thank you all for your help.

Kind regards,


Richard Burts Mon, 08/18/2008 - 08:00


Thank you for posting back to this thread and indicating that you had resolved the problem. And thank you for using the rating system to indicate that your problem was resolved (and thanks for the rating). It makes the forum more useful when people can read about a problem and can know that they will read the solution to the problem.




This Discussion