cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
7789
Views
5
Helpful
11
Replies
JoeSS8700
Beginner

Problem with Site to Site VPN. VPN Tunnel is down, but can ping

Ok, so I'm am trying to figure out why I can't get nothing to show up when I do sh crypto isakmp sa or sh crypto ipsec sa. I did the basic setup for a site to site vpn and I can ping across both networks just fine no problem. So when I ping from a pc in the 172.16.0.0 network to 192.168.0.0 network there is no problem at all because the pings are recieved just fine. But when I go to sh crypto isakmp sa, there is just nothing there and I can't for the life of me figure out why. I looked at my sh run for both routers and everything looks fine, but I guess I may be overlooking something. If someone could help me diagnose this problem I would truely appreciate. 

I have attached my packet tracer file and both routers are using the password binary. I also have the sh run of both routers also attached.

1 ACCEPTED SOLUTION

Accepted Solutions

I cannot see on any of the router 172.16.0.0/24, only 172.16.0.0/16 and I think this is the issue.

In Crypto ACL you have on branch router:

!

ip access-list extended S2S-VPN-TRAFFIC

permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255

shouldn't it be:

!

ip access-list extended S2S-VPN-TRAFFIC

permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.255.255

and of coursed mirrored on the the main router.

If this is not the case you are saying that some ping between 192.168.0.x and 172.16.0.x is going ok. Can you please point exactly which one? I could see that you attached some packet tracer, but I couldn't open it.

View solution in original post

11 REPLIES 11
Jennifer Halim
Cisco Employee

Are you sure they are routing it correctly?

Also on the main site, you should remove the crypto map on the trunk interface as it's incorrect:

interface FastEthernet0/1

description TRUNK TO MAIN SWITCH A

no crypto map vader

And on the branch site, remove the crypto map from fa0/1 if it's not required as you only need to apply them to the interface where the peer address is:

interface FastEthernet0/1

no crypto map vader

Then, try to do extended ping from the branch router, sourcing it from interface fa0/1, and see if you can ping something on 172.16.0.x subnet.

Alright, I removed the crypto map on the fa0/1 interface of both routers. I also tired pinging something from the 172.16.0.x subnet and I was able to ping just fine. I can pretty much ping across almost any where with a problem. Which confuses me more of why the VPN tunnel isn't showing up and why nothing shows in sh crypto idakmp sa.

If the VPN tunnel isn't showing up, it's most probably routing via a different path, not via the interface where the crypto map is applied.

Can you pls check the routing to see if it's routing correctly?

ok, I what I did was do a tracert from a pc on both networks and they both show that they are routing propertly across the interface. Plus i don't see how it could route across a different path because there is just one path which is across the cable that connects the two routers.

Can you explain us how 172.16.0.0 is reachable on main router? I cannot see it directly connected, but I can see that you are setting up ospf for that network.

We need to be sure that we are going to this network through interface fast 0/0.

'show ip route' output from both routers would be helpfull.

Here is are the show ip route for both routers.

Main Router

     172.16.0.0/16 is variably subnetted, 8 subnets, 3 masks

C       172.16.10.0/28 is directly connected, FastEthernet0/1.10

C       172.16.20.0/24 is directly connected, FastEthernet0/1.20

C       172.16.30.0/24 is directly connected, FastEthernet0/1.30

C       172.16.40.0/24 is directly connected, FastEthernet0/1.40

C       172.16.70.0/24 is directly connected, FastEthernet0/1.70

C       172.16.95.0/28 is directly connected, FastEthernet0/1.95

C       172.16.95.100/32 is directly connected, Loopback0

C       172.16.150.0/24 is directly connected, FastEthernet0/1.150

     192.0.2.0/29 is subnetted, 1 subnets

C       192.0.2.24 is directly connected, FastEthernet0/0

O IA 192.168.0.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA 192.168.1.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA 192.168.10.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA 192.168.20.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA 192.168.30.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

     192.168.95.0/24 is variably subnetted, 2 subnets, 2 masks

O IA    192.168.95.0/28 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA    192.168.95.100/32 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

O IA 192.168.150.0/24 [110/2] via 192.0.2.27, 00:04:45, FastEthernet0/0

Branch Router

     172.16.0.0/16 is variably subnetted, 8 subnets, 3 masks

O IA    172.16.10.0/28 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.20.0/24 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.30.0/24 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.40.0/24 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.70.0/24 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.95.0/28 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.95.100/32 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

O IA    172.16.150.0/24 [110/2] via 192.0.2.25, 00:02:22, FastEthernet0/0

     192.0.2.0/29 is subnetted, 1 subnets

C       192.0.2.24 is directly connected, FastEthernet0/0

C    192.168.0.0/24 is directly connected, FastEthernet0/1

C    192.168.1.0/24 is directly connected, FastEthernet0/1.1

C    192.168.10.0/24 is directly connected, FastEthernet0/1.10

C    192.168.20.0/24 is directly connected, FastEthernet0/1.20

C    192.168.30.0/24 is directly connected, FastEthernet0/1.30

     192.168.95.0/24 is variably subnetted, 2 subnets, 2 masks

C       192.168.95.0/28 is directly connected, FastEthernet0/1.95

C       192.168.95.100/32 is directly connected, Loopback0

C    192.168.150.0/24 is directly connected, FastEthernet0/1.150

I cannot see on any of the router 172.16.0.0/24, only 172.16.0.0/16 and I think this is the issue.

In Crypto ACL you have on branch router:

!

ip access-list extended S2S-VPN-TRAFFIC

permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255

shouldn't it be:

!

ip access-list extended S2S-VPN-TRAFFIC

permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.255.255

and of coursed mirrored on the the main router.

If this is not the case you are saying that some ping between 192.168.0.x and 172.16.0.x is going ok. Can you please point exactly which one? I could see that you attached some packet tracer, but I couldn't open it.

View solution in original post

How about vlans traffic going through the vpn tunnel? I don't know why I didn't mention this in the question because that is something I having issue with as well. Like I have a PC connect to a switch on the Main router side and its connect to VLAN 40, so I gave it a 172.16.40.13 address with a gateway of 172.16.40.1.   On the Branch side the pc is connected to VLAN 30, so I gave it a 192.16.30.13 address with a gatewary of 172.16.30.1. I can ping between both pc's just fine no problem and ping the gateway as well. Shouldn't this traffic active the vpn tunnel and show up if I were to look at sh crypto isakmp sa?

I am a little bit confused with the IP addressess that you put above, since you mixed probably 192.168 with 172.16.

Anway you didn't have 172.16.0.0/24 network at all meaning the traffic between for instance 172.16.40.5 and 192.168.0.5 will not establish the tunnel since it doesn't match crypto acl.

You can check that it is the issue by looking at show access-list. You will see probably no hit count.

After you modify access-list properly than this hit counts will go start to go up and then if the tunnel is still not up we are having some isakmp phase 1 problems.

If you need further help please say exactly from where to and to what you are intiaiting traffic (exact IPs) and your current crypto ACl configuration (if you changed anything). Routing we already have.

Hey Piotr, I did what you said and changed the ACL around it and the VPN tunnel is working like it should now.  Thank you for your help, I really appreciate it a lot.  Its funny how some of the most challenging problems can be solved with a simple fix.  Thanks Again.

Great to hear Joseph that it worked!

Feel free to rate any posts that you found helpful.

Have a great afternoon:)

Content for Community-Ad