I have a strange problem that I have been fighting.
Site A - internal network 172.31.16.0/24
Site B - Internal Network 172.31.17.0/24
Site C - Internal Network 10.0.0.0 /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.
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.
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.
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.
Your configuration should look like this:
On site A:
1) Crypto ACL For VPN A to B:
access-list 100 extended permit ip 172.31.16.0 255.255.255.0 172.31.17.0 255.255.255.0
access-list 100 extended permit ip 10.0.0.0 255.0.0.0 172.31.17.0 255.255.255.0
2) Crypto ACL For VPN A to C:
access-list 101 extended permit ip 172.31.16.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list 101 extended permit ip 172.31.17.0 255.255.255.0 10.0.0.0 255.0.0.0
On Site B:
Crypto ACL for VPN to site A:
access-list 201 extended permit ip 172.31.17.0 255.255.255.0 172.31.16.0 255.255.255.0
access-list 201 extended permit ip 172.31.17.0 255.255.255.0 10.0.0.0 255.0.0.0
On Site C:
Crypto ACL for VPN to site A:
access-list 301 extended permit ip 10.0.0.0 255.0.0.0 172.31.16.0 255.255.255.0
access-list 301 extended permit ip 10.0.0.0 255.0.0.0 172.31.17.0 255.255.255.0
Also change the following :
crypto map outside_map 10 ipsec-isakmp dynamic dynmap
crypto map outside_map 65000 ipsec-isakmp dynamic dynmap
Thanks for the detailed information. I verified the ACLs on the gear that I can. Waiting to hear back on the other site. It would not let me change the crytpo map from 10 to 65000. I am using 10 for the vpn clients. What was the reason for that change?
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?
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 172.31.17.0 in your NONAT statement.
access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 172.31.17.0 255.255.255.0
Can you add this statement and let me know if it works.
*Pls rate all helpful posts*
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*