cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3530
Views
7
Helpful
12
Replies

IPSec VPN Tunnel Not Coming Up

PeterHaase
Level 1
Level 1

Hello,

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.

Thanks

Peter Haase

1 Accepted Solution

Accepted Solutions

Peter,

Good work!

Since the tunnel is up we do not need debugs.

I am glad that finally it is working .

HTH

Saju

View solution in original post

12 Replies 12

singhsaju
Level 4
Level 4

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?

HTH

Saju

Pls rate if it helps

Hi Saju,

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

crypto isakmp key key_removed address 67.69.27.154

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

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

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 64.37.198.169

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to64.37.198.169

set peer 64.37.198.169

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 67.69.27.154 host 64.37.249.63

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.

Regards

Peter

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.

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 = 192.168.1.0/24

External IP on our router = 67.69.27.154

Remote IPSec gateway = 64.37.198.169

FTP Server = 64.37.249.63

Peter

PeterHaase
Level 1
Level 1

Here is the relevant parts from the troubleshooting log:

Checking Routing... Successful

Peer :64.37.198.169:Valid(Routed through the crypto interface)

Traffic source :67.69.27.154:Invalid(Routed through the crypto interface)

Traffic destination :64.37.249.63:Valid(Routed through the crypto interface)

The following source(s) are routed through the crypto map interface. 1) 67.69.27.154 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.

Peter

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 192.168.1.0 0.0.0.255 host 64.37.249.63

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.

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."

and

"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?

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.

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

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 172.22.1.164 no-xauth

configure no-xauth and then check and post results.

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!

Regards

Peter

Peter,

Good work!

Since the tunnel is up we do not need debugs.

I am glad that finally it is working .

HTH

Saju

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: