cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
19265
Views
0
Helpful
29
Replies

IPSec VPN Tunnel not coming up

raulzulueta
Level 1
Level 1

I am trying to get a tunell up between two sites to allow traffic from machines in TOR to access machines in SF (both ways)

I have configured most of it and performed a Test Tunnel process. It passes all tests except when I perform a ping.

Attached are the configurations from the TOR and the SF office. What am I missing here.

TOR internal nets is 10.6.0.0

SF internal nets is 192.168.0.0

Thanks for your help.

14 Accepted Solutions

Accepted Solutions

Lei Tian
Cisco Employee
Cisco Employee

Hi,

Don't know exactly how did you test the ping, but I guess the problem is the source of the ping packet is not covered in the ACL 140.


Regards,

Lei Tian

View solution in original post

Hi,

The ACL inside crypto-map is used to control what traffic will be encrypted and send over the insecure network. The ACL on one side should mirror the ACL on the otherside.

If you want protect the traffic send between 10.6.0.0/16 and 192.168.0.0/16, then the ACL will be 'permit ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255' on TOR side, and 'permit ip 192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255' on SF side.

HTH,

Lei Tian

View solution in original post

Maybe I miss-understood your question. You said 'It passes all tests except when I perform a ping', that makes feel the tunnel is working only fail when you tested the ping

Ok, so the tunnel is not up at all. Can you ping 216.156.80.218 source from 76.227.156.212? Can you share the output of 'show cry isakmp sa' and 'show cry ipsec sa'? Can you remove 'ip route 10.6.0.0 255.255.0.0 Tunnel1' from TOR's config?

Regards,

Lei Tian

View solution in original post

Ok, so the tunnel is up, but traffic doesn't pass between 192.168.0.0/16 and 10.6.0.0/16.

Can you

1,remove the static route 'ip route 10.6.0.0 255.255.0.0 Tunnel1' on TOR.

2,make  sure 'permit ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255' is on TOR  side (it was on SF side in your initial config), and 'permit ip  192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255' on SF side.

3, Not  sure if the NAT is working on TOR. If it is working, then exclude  traffic src 10.6.0.0/16 to 192.168.0.0/16 from NAT on TOR. You can  modify the ACL 101 to 'deny ip 10.6.0.0 0.0.255.255 192.168.0.0  0.0.255.255' on TOR.

HTH,

Lei Tian

View solution in original post

Lei Tian
Cisco Employee
Cisco Employee

Hi,

The output from SF looks fine, but on TOR side why '209.220.177.67' is trying to negotiate with TOR for ipsec tunnel? What's the configure on 209.220.177.67?

Regards,

Lei Tian

View solution in original post

Ok. Can you do the following and paste the output?

1  do 'clear crypto sa counter' on both SF and TOR

2 ping 10.6.1.250 source 192.168.50.x (you need to specify the source from 192.168.50.x, otherwise it will source from 209.220.177.67.)

3 capture the output of 'show cry ipsec sa' on both SF and TOR

Regards,

Lei Tian

View solution in original post

Lei Tian
Cisco Employee
Cisco Employee

Yes, I noticed 192.168.0.0/16 is not directly connect. Is that the directly connected subnet on 209.220.177.67? Can you test it from that device?

Yes, we are close:)

Regards,

Lei Tian

View solution in original post

Lei Tian
Cisco Employee
Cisco Employee

Ok, seems no interest traffic hit on both sides. The ICMP packet from 192.168.50.x to 10.6.1.250 didn't match on the ACL.

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0


There must be something wrong on 209.220.177.67. Can you share the config for this device?

Regards,

Lei Tian

View solution in original post

Lei Tian
Cisco Employee
Cisco Employee

Hi,

There are something you might want to change on this router.

1,remove ' crypto map Client_VPN' from interface fa1

2,modify the ACL 'ip access-list extended internetOutbound', add permit ip 192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255.

3,modify the ACL 'ip access-list extended NoNAT', add 'deny ip 192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255' before the permit statement.

Help that helps,

Lei Tian

View solution in original post

Glad that I can help, and thanks for the rating.

Hope that can help you to build the rest tunnels.

Regards,

Lei Tian

View solution in original post

You are missing a few things here :-

router 1941 :-

all you are missing here is a nat expemt for vpn traffic , so your first line for access-list 101 should be :-

access-list 101 deny ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255

On the other router 1811 :-

1> I do not see 192.168.0.0 subnet on any interface in the configuration.

2> you are missing Nat configuration as well ( both dynamic PAT as well as nat exempt for vpn traffic).

Do that & then move forwards for rest of the issues.

thanks

Manish

View solution in original post

Ok , it is a different senario then i thought, we make the changes on 1911 router as i mentioned earlier. The tunnel endpont router 1811 seems fine to me.

On the downstream 1811 router, make an nonat statement in the access-list :-

ip access-list extended NONAT


deny ip 192.168.50.0 0.0.0.255 10.6.0.0 0.0.255.255

Now , make sure both the nat exempt statements appears before any permit statement.use sh access-list NONAT and adjust the statement no so that the above mention statement appears before the permit statement.

Thanks

Manish

View solution in original post

On the 1941 router the deny statement is at the bottom of the the access list statements, you have to make sure that statement is the first one.

redo access list 101 on the 1941 router with access-list 101 deny ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255 as statement no one.

Thanks

Manish

View solution in original post

Good to hear that. here's few tips and troubleshooting guide for vpns :-

creating a vpn tunnel :-

1> create phase 1 (isakmp).

2> authentication for the peer.

3> identity intresting traffic ( there should be a mirror acl on both end points)

4> phase 2 configuration

5> check for nat exempt.

6> see traffic is allowed through the access lists on the interface.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml

use above link for troubleshooting.

thanks

manish

View solution in original post

29 Replies 29

Lei Tian
Cisco Employee
Cisco Employee

Hi,

Don't know exactly how did you test the ping, but I guess the problem is the source of the ping packet is not covered in the ACL 140.


Regards,

Lei Tian

How should ACL 140 look like?

Hi,

The ACL inside crypto-map is used to control what traffic will be encrypted and send over the insecure network. The ACL on one side should mirror the ACL on the otherside.

If you want protect the traffic send between 10.6.0.0/16 and 192.168.0.0/16, then the ACL will be 'permit ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255' on TOR side, and 'permit ip 192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255' on SF side.

HTH,

Lei Tian

I corrected the ACLs on both sides. The tunnel still does not want to come up.

Maybe I miss-understood your question. You said 'It passes all tests except when I perform a ping', that makes feel the tunnel is working only fail when you tested the ping

Ok, so the tunnel is not up at all. Can you ping 216.156.80.218 source from 76.227.156.212? Can you share the output of 'show cry isakmp sa' and 'show cry ipsec sa'? Can you remove 'ip route 10.6.0.0 255.255.0.0 Tunnel1' from TOR's config?

Regards,

Lei Tian

the tunnel came up after i changed the ACLs on both sides. However I cannot ping from a 192.168.50.1 to 10.6.1.250 (both directions).

Ok, so the tunnel is up, but traffic doesn't pass between 192.168.0.0/16 and 10.6.0.0/16.

Can you

1,remove the static route 'ip route 10.6.0.0 255.255.0.0 Tunnel1' on TOR.

2,make  sure 'permit ip 10.6.0.0 0.0.255.255 192.168.0.0 0.0.255.255' is on TOR  side (it was on SF side in your initial config), and 'permit ip  192.168.0.0 0.0.255.255 10.6.0.0 0.0.255.255' on SF side.

3, Not  sure if the NAT is working on TOR. If it is working, then exclude  traffic src 10.6.0.0/16 to 192.168.0.0/16 from NAT on TOR. You can  modify the ACL 101 to 'deny ip 10.6.0.0 0.0.255.255 192.168.0.0  0.0.255.255' on TOR.

HTH,

Lei Tian

Here is the debug output from both TOR and SF routers when I do a ping from 10.6.1.250 to 192.168.50.1

I have made the changes you recommended. Still no success.

Thanks.

Lei Tian
Cisco Employee
Cisco Employee

Hi,

The output from SF looks fine, but on TOR side why '209.220.177.67' is trying to negotiate with TOR for ipsec tunnel? What's the configure on 209.220.177.67?

Regards,

Lei Tian

That is a router behind the SF peer router that is the gateway to the internal nets of 192.168.0.0

I tried to create the tunnel on this router but it did not come up so i tried the edge router that is the default gateway to the internet for this location - 216.156.80.218 (SF-peer). I removed the tunnel crypto map configuration on 209.220.177.67 and now I dont get any output on my debugs.

Ok. Can you do the following and paste the output?

1  do 'clear crypto sa counter' on both SF and TOR

2 ping 10.6.1.250 source 192.168.50.x (you need to specify the source from 192.168.50.x, otherwise it will source from 209.220.177.67.)

3 capture the output of 'show cry ipsec sa' on both SF and TOR

Regards,

Lei Tian

The problem is 192.168.0.0 does not exist as an interface in the SF-peer router which is our tunnel endpoint also. 192.168.0.0 is known via 209.220.177.67. (vlan 1 and Fa7)

I attached the SF-peer router config.

I know we are close to solving this.

Thanks.

Here is the show crypto ipsec sa output from both sides.

I have a few more of these tunnels to create so this learning curve is very useful.

Lei Tian
Cisco Employee
Cisco Employee

Yes, I noticed 192.168.0.0/16 is not directly connect. Is that the directly connected subnet on 209.220.177.67? Can you test it from that device?

Yes, we are close:)

Regards,

Lei Tian

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco