Traffic between VPN Tunnels

Unanswered Question

I have a strange problem that I have been fighting.

Site A - internal network

Site B - Internal Network

Site C - Internal Network /8

I have vpn tunnels connected from Site A to each site. Sites A & C can talk to each other. I cannot get the traffic from Site B to talk to Site C.

Attached is my config.

The VPN tunnels are up and working.

Any Ideas?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Farrukh Haroon Sun, 12/14/2008 - 22:21

Since you havent provided the complete configuration, I would suggest to compare your configuration with the following document and see whats missing:

Also incase default routes are not present, make sure both SiteB and SiteC have the appropriate 'route' statements for the remote side's LAN subnet.



jiangu Sun, 12/14/2008 - 22:34

Did you happen to sanitize the following command too?

same-security-traffic permit intra-interface

It would be helpful if you did not sanitize the OS version.

Farrukh Haroon Sun, 12/14/2008 - 22:40

The same-sec...command is there. Its the first thing I checked :)



The Main site is running ASA 5510 7.2(3) and the same-security-traffic permit intra-interface command is being utilized. Site C is a business partner, so I don't access to the config. Based on the troubleshooting so far, the problem is with Site A. Site A can talk to both B and C. It seems like the ASA in Site A is blocking the traffic from traversing the site. The routes are all in place at all 3 sites. The traffic is going to the right places, I just can't get through Site A.

Farrukh Haroon Mon, 12/15/2008 - 11:12

You can run the packet-tracer command on SiteA to verify the SiteB to SiteC traffic.



rkalia1 Mon, 12/15/2008 - 13:17

Your configuration should look like this:

On site A:

1) Crypto ACL For VPN A to B:

access-list 100 extended permit ip

access-list 100 extended permit ip

2) Crypto ACL For VPN A to C:

access-list 101 extended permit ip

access-list 101 extended permit ip

On Site B:

Crypto ACL for VPN to site A:

access-list 201 extended permit ip

access-list 201 extended permit ip

On Site C:

Crypto ACL for VPN to site A:

access-list 301 extended permit ip

access-list 301 extended permit ip

rkalia1 Mon, 12/15/2008 - 13:20

Also change the following :

crypto map outside_map 10 ipsec-isakmp dynamic dynmap


crypto map outside_map 65000 ipsec-isakmp dynamic dynmap

rkalia1 Tue, 12/16/2008 - 05:42

10 is the sequence number of the Crypto map and in this case for a Dynamic map. By design the dynamic maps should be given much higher sequence numbers than the static maps. I have seen that the Phase II of static L2L tunnels not working if the sequence number of the static map is greater than the dynamic map. It should be the other way round for things to work. You may have to delete the crypto map entry for dynamic map and then put it back with a higher sequence number.

I was able to move the crypto map to a higher number. Didn't solve the problem. I did run the packet-tracer. When I run it on the outside interface with an IP from both sites, I get notification that the packet was dropped, due to (IPSEC-Spoof) IPSEC Spoof detected. Any ideas why the traffic will not flow in and out of the outside interface between the 2 tunnels?

ajagadee Fri, 12/19/2008 - 09:38


Can you post the outputs of "show crypto ipsec sa". Are you seeing packets encrypt and decrypt.

Based on the configuration from the initial post, I do not see 10.x.x.x to in your NONAT statement.

That is:

access-list inside_nat0_outbound extended permit ip

Can you add this statement and let me know if it works.



*Pls rate all helpful posts*

ajagadee Fri, 12/19/2008 - 10:18


Can you also post the current configurtion. The reason I ask is, I can see the packets from 17.x are getting enctyped for the 10.x.x.x but no decrypts.

Who owns the 10.x.x.x/8 network. Looks like the issue could be on the other side, where things are not configured correctly. Could be a routing issue, NAT, ACL, etc. But, the problem seems to be on the remote side because they are not encrypting the packets and sending back to you.



*Pls rate if it helps*

TJ Kelly Fri, 12/19/2008 - 10:36


A business partner owns the network that the other site needs to access. They have assured me that the network is allowed through their tunnel to our main site.



ajagadee Fri, 12/19/2008 - 10:47


It is going to be really hard to find the root cause unless you get a copy of the configuration/screen shots/etc from the 10/8 side. If their security policy does not allow posting config/screen shots in a forum, maybe you can take a look at it and confirm that everything is configured correctly.

From the show crypto ipsec sa below, you can see the packets from destined to 10/8 are getting encrypted on your side.

Crypto map tag: outside_map, seq num: 5, local addr:

access-list 100 permit ip log

local ident (addr/mask/prot/port): (

remote ident (addr/mask/prot/port): (

current_peer: 207.x.x.x

#pkts encaps: 24, #pkts encrypt: 24, #pkts digest: 24

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

So, you need the below info from the other side to further troubleshoot this issue:

1. Show crypto ipsec sa for this specific IPSEC SA or screen shots showing Packets Rx/Tx/

2. Is the 10/8 side seeing packets decrypted

3. Is the 10/8 side seeing packet transmitted

4. The IPSEC Part may be configured correctly but what about the routing? Does 10/8 know how to route the packets destined for

I hope it makes sense.



*Pls rate all helpful posts*


This Discussion