IPSec VPN Tunnel Not Coming Up

Answered Question
Sep 9th, 2008


I am trying to setup an IPSec VPN tunnel between my company and a remote company for the use of secure FTP.

I have used SDM to setup the tunnel on my router based on information provided by the company we are trying to connect to. The other company has provided my a debug log from when I was testing the connection but I'm not sure how to read it and what the problem might be. I'm hoping someone here can give me some insight into what is stopping the tunnel connecting.

Please let me know if more information is required.


Peter Haase

I have this problem too.
0 votes
Correct Answer by singhsaju about 8 years 1 month ago


Good work!

Since the tunnel is up we do not need debugs.

I am glad that finally it is working .



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (3 ratings)
singhsaju Tue, 09/09/2008 - 12:28

Hi Peter,

The Tunnel reaches Phase 2 end i.e Quick mode and then tunnel drops . Can you check the crypto acls on vpn end devices are mirror of each other.

Can you post configs of the vpn devices that might help to investigate further?



Pls rate if it helps

PeterHaase Wed, 09/10/2008 - 11:03

Hi Saju,

Thanks for your help. Here is the configuration on the remote router:

crypto isakmp key key_removed address

crypto map INTERNETVPN 1650 ipsec-isakmp description Crypto to Armada Toolworks Ltd set peer set transform-set TRANS-ESP-3DES match address ARMADA-TOOLWORKS

ip access-list extended ARMADA-TOOLWORKS permit ip host host

I made a change to the crypto ACL on my router as I am led to believe it should not contain private addresses:

crypto isakmp key key-removed address

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to64.37.198.169

set peer

set transform-set TRANS-ESP-3DES

match address COVISINT

ip access-list extended COVISINT

remark SDM_ACL Category=4

remark VPN to Covisint

permit ip host host

I've attached the troubleshooting report I get when testing the link after making the change to the ACL. It's the same as before but the routing errors are new since changing the ACL.



singhsaju Wed, 09/10/2008 - 12:06

Hi Peter,

I cannot access the attachment.

The access-lists used is using public ip address . I think also it is not correct.

Whats the LAN ip network on your side? what's the LAN on the remote side ?

The Crypto acl should contain thos private networks as source and destination.

PeterHaase Wed, 09/10/2008 - 12:16

Hi Saju,

The end result is a PC in our internal network connecting to an FTP server in the remote network using the VPN tunnel.

Details are:

Internal network =

External IP on our router =

Remote IPSec gateway =

FTP Server =


PeterHaase Wed, 09/10/2008 - 12:19

Here is the relevant parts from the troubleshooting log:

Checking Routing... Successful

Peer : through the crypto interface)

Traffic source : through the crypto interface)

Traffic destination : through the crypto interface)

The following source(s) are routed through the crypto map interface. 1) Go to 'Configure->Routing' and correct the routing table.

This led me to believe the ACL on my router needed to be from the internal network to the FTP server.


singhsaju Wed, 09/10/2008 - 12:36

Change your acl and have the remote side also change the acl as mirror image to following:

ip access-list extended COVISINT

remark SDM_ACL Category=4

remark VPN to Covisint

permit ip host

Are you sure FTP server does not has private ip address in the remote network?

Also besides ACL we also have to make Ipsec traffic bypass NAT on the router.

PeterHaase Thu, 09/11/2008 - 05:35

I originally had my access list as you suggested but the Network Engineer at the company we are connecting to said that was wrong. Her replies included:

"Your access-list for the encryption should not contain private addresses, this needs to be your public address."


"Your address translation is handled prior to the encryption."

From that I assumed we needed to perform NAT on the traffic from the local network and after that send it down the VPN tunnel.

Even when I mirror her ACL the tunnel still won't come up when being tested on the router. Should the tunnel only come up when you attempt to send traffic or should it be up regardless?

singhsaju Thu, 09/11/2008 - 05:46

ok now i understand , basically your private network only needs to access this FTP server and your private network will be hidden, and its translated to public ip of your router.So your access list should work then .

In this case your ipsec traffic to ftp server do not have to bypass nat , as i was thinking earlier.

You will have to generate traffic from your end to make the tunnel come up.

Can you post result of "show crypto isakmp sa" after you ping the FTP server.

and also enable debug "debug cry isa" and " debug cry ipsec" and post the latest debugs.

PeterHaase Thu, 09/11/2008 - 11:26

Sorry for the delay, I have been dealing with some urgent issues here.

Attached is the output from the command and debugging while I was pinging.

Thanks for your help so far

singhsaju Thu, 09/11/2008 - 11:36

From debugs :

001213: *Sep 11 15:29:19.997 PCTime: ISAKMP:(2004):Need XAUTH

why are you doing Xauth ? we do not need to do Xauth .

can you post your vpn config ?

Use the no-xauth keyword when you enter the isakmp key, so the device does not prompt the peer for XAUTH information (username and password). This keyword disables XAUTH for static IPsec peers. Enter a command similar to this on the device that has both L2L and RA VPN configured on the same crypto map:

router(config)# crypto isakmp key cisco123 address no-xauth

configure no-xauth and then check and post results.

PeterHaase Thu, 09/11/2008 - 11:59

I was using SDM rather than command line and didn't even notice an Xauth checkbox. I removed that from the preshared key and the VPN now comes up! I also get the replies on the ping to the ftp site.

I've attached the debug log in case there is anything else I have missed.

If not then thank you very much for you patience and time, it is much appreciated!



Correct Answer
singhsaju Thu, 09/11/2008 - 12:03


Good work!

Since the tunnel is up we do not need debugs.

I am glad that finally it is working .




This Discussion