IPSec VPN Tunnel not coming up

Answered Question
Sep 7th, 2010

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.

I have this problem too.
0 votes
Correct Answer by manish arora about 6 years 2 months ago

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

Correct Answer by manish arora about 6 years 2 months ago

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

Correct Answer by manish arora about 6 years 2 months ago

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

Correct Answer by manish arora about 6 years 2 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Hope that can help you to build the rest tunnels.

Regards,

Lei Tian

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

Correct Answer by Lei Tian about 6 years 3 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (14 ratings)
Loading.
Correct Answer
Lei Tian Tue, 09/07/2010 - 19:18

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

Correct Answer
Lei Tian Tue, 09/07/2010 - 20:27

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

raulzulueta Tue, 09/07/2010 - 20:30

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

Correct Answer
Lei Tian Tue, 09/07/2010 - 20:44

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

raulzulueta Tue, 09/07/2010 - 20:43

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

Correct Answer
Lei Tian Wed, 09/08/2010 - 03:25

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

raulzulueta Wed, 09/08/2010 - 09:43

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.

Correct Answer
Lei Tian Wed, 09/08/2010 - 10:46

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

raulzulueta Wed, 09/08/2010 - 11:07

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.

Correct Answer
Lei Tian Wed, 09/08/2010 - 11:15

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

raulzulueta Wed, 09/08/2010 - 11:22

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.

raulzulueta Wed, 09/08/2010 - 11:36

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.

Correct Answer
Lei Tian Wed, 09/08/2010 - 11:35

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

Correct Answer
Lei Tian Wed, 09/08/2010 - 11:51

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

Correct Answer
Lei Tian Wed, 09/08/2010 - 13:40

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

Correct Answer
Lei Tian Wed, 09/08/2010 - 17:29

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

Hope that can help you to build the rest tunnels.

Regards,

Lei Tian

raulzulueta Tue, 09/14/2010 - 19:03

I am building another tunnel on a c1941w router to the same SF peer. Enclosed are the configs for SF and another router called TOR. The tunnels are up and can ping each other but the internal nets cannot. I need 10.6.0.0 to reach 192.168.0.0

What am I missing here?

I can send the outputs of the debug if that would help.

Thanks again.

raulzulueta Thu, 09/16/2010 - 10:54

Hi,

Can someone assist me in resolving this? I have a few more tunnels to build and this learning curve would eb very useful to me.

Thanks again.

Correct Answer
manish arora Thu, 09/16/2010 - 12:31

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

raulzulueta Thu, 09/16/2010 - 13:35

I made the changes on the 1941 router. The 192.168.0.0 network is conencted to another 1811 router that connects via Fa 7 vlan 1 on this router.

This route statement shows it :

ip route 192.168.50.0 255.255.255.0 209.220.177.67
ip route 192.168.51.0 255.255.255.0 209.220.177.67

I will include the config for this downstream 1811 router. Please let me know what changes I need to do.

I am not quite sure I understand your second set onf instructions for the 1811 router. Please expand.

Thanks again.

Correct Answer
manish arora Thu, 09/16/2010 - 13:57

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

raulzulueta Thu, 09/16/2010 - 14:13

I hope I made all the changes required.  Attached are the new configs for the TOR-1941, the SF-1811 and the SF-1811 downstream routers.

The tunnel looks up but still cannot ping from 10.6.0.0 and 192.168.0.0

Any help would be most appreciated in solving this. I thinks we are close.

Thanks again.

Correct Answer
manish arora Thu, 09/16/2010 - 14:19

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

raulzulueta Thu, 09/16/2010 - 14:31

Things are looking better now. The ping packets are going through.

Thanks a lot, really. I hope the next tunnels I build are flawless.

Correct Answer
manish arora Thu, 09/16/2010 - 14:40

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

Actions

This Discussion