Solved

Trouble passing traffic between remote Site to Site VPN subnets ASA 5505 5520

Posted on 2014-03-07
9
2,029 Views
Last Modified: 2014-03-15
We have an ASA 5520 at Site A with Site to Site VPN tunnels to  Site B and Site C.  While traffic can move between Sites A and B, and Sites A and C, no traffic may pass between Sites B and C.

 It should be noted that numerous 10.x.x.x subnets exist elsewhere at Site A (behind the 172.18.x.x LAN) with which Sites B and C can (and must) freely communicate.

SITE A (LAN: 172.18.4.x\24  WAN: 12.231.x.x)
access-list outside_cryptomap extended permit ip 172.18.4.0 255.255.255.0 10.6.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.0.0.0 255.0.0.0 10.6.0.0 255.255.0.0
access-list outside_access_in extended permit ip 12.192.x.x 255.255.255.0 any
access-list outside_access_in extended permit ip 64.x.x.x 255.255.255.240 any
access-list outside_access_in extended permit icmp any any
access-list inside_nat0_outbound extended permit ip any 10.6.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip any 10.10.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 172.18.4.0 255.255.255.0 10.10.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 10.0.0.0 255.0.0.0 10.10.0.0 255.255.0.0

SITE B (LAN: 10.6.0.0/16  WAN: 64.x.x.x)
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 172.18.4.0 255.255.255.0
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.0.0.0 255.0.0.0
access-list outside_access_in extended permit ip host 12.231.x.x any
access-list outside_access_in extended permit icmp any any
access-list inside_nat0_outbound extended permit ip 10.6.0.0 255.255.0.0 172.18.4.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 10.6.0.0 255.255.0.0 10.0.0.0 255.0.0.0

SITE C (LAN: 10.10.0.0/16  WAN: 12.192.x.x)
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 172.18.4.0 255.255.255.0
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.0.0.0 255.0.0.0
access-list outside_access_in extended permit ip host 12.231.x.x any
access-list outside_access_in extended permit icmp any any
access-list inside_nat0_outbound extended permit ip 10.10.0.0 255.255.0.0 172.18.4.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 10.10.0.0 255.255.0.0 10.0.0.0 255.0.0.0

Open in new window

0
Comment
Question by:David Blair
  • 6
  • 3
9 Comments
 
LVL 11

Expert Comment

by:naderz
ID: 39913930
I see one potential issue: The ACLs for VPN (if I am reading your config correctly) don't match:


SITE B (LAN: 10.6.0.0/16  WAN: 64.x.x.x)
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.0.0.0 255.0.0.0


SITE C (LAN: 10.10.0.0/16  WAN: 12.192.x.x)
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.0.0.0 255.0.0.0


For VPN tunnel they have to match exactly (provided being mirror of each other)

Possible solution:

SITE B (LAN: 10.6.0.0/16  WAN: 64.x.x.x)
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.10.0.0 255.255.0.0


SITE C (LAN: 10.10.0.0/16  WAN: 12.192.x.x)
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.6.0.0 255.255.0.0
0
 
LVL 1

Author Comment

by:David Blair
ID: 39914068
I understand your point, but making that change would prevent both sites B and C from accessing 10. networks at site A.
0
 
LVL 11

Expert Comment

by:naderz
ID: 39914208
Understood. You would then need to have multiple lines. Do include the 10.0.0.0/8 as well. But, do have the specific routes between B and C.

Do 10.6.0.0/16 and 10.10.0.0/16 exist on Site A behind the 172.18.4.x? If yes, that would make things challenging! If they do exist in Site A, then one way would be to NAT them.
0
Now Available: Firebox Cloud for AWS and FireboxV

Firebox Cloud brings the protection of WatchGuard’s leading Firebox UTM appliances to public cloud environments. It enables organizations to extend their security perimeter to protect business-critical assets in Amazon Web Services (AWS).

 
LVL 1

Author Comment

by:David Blair
ID: 39915076
So just to clarify then, even though traffic from 10.6.0.0 to 10.10.0.0 would be covered by:

access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.0.0.0 255.0.0.0

You're suggesting I add lines like this:

access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.10.0.0 255.0.0.0

to the  cryptomaps (and the same in reverse)?

To answer your question, on the other side of 172.18.4.0 there are only 10.0.x.x, 10.1.x.x, 10.2.x.x, 10.3.x.x, 10.5.x.x, and 10.8.x.x at Site A.  Too many, in my opinion to try and add lines for each.
0
 
LVL 11

Assisted Solution

by:naderz
naderz earned 250 total points
ID: 39915278
To establish the IPSec tunnel the ACLs for hte interesting traffic on each end need to match exactly. So, I would try to add those specific ACLs.

Also, have you verified that routing and other ACLs are fine. Would you please post results of "show run access-group" and "show ip route"?
0
 
LVL 1

Author Comment

by:David Blair
ID: 39917752
Still no luck, unfortunately.  Here are the new crypto statements and results of the commands you requested:

SITE A
access-list outside_cryptomap extended permit ip 10.0.0.0 255.255.0.0 10.6.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.1.0.0 255.255.0.0 10.6.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.2.0.0 255.255.0.0 10.6.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.6.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 10.0.0.0 255.255.0.0 10.10.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 10.1.0.0 255.255.0.0 10.10.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 10.2.0.0 255.255.0.0 10.10.0.0 255.255.0.0
access-list outside_cryptomap_1 extended permit ip 10.6.0.0 255.255.0.0 10.10.0.0 255.255.0.0

SITE B
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.0.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.1.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.6.0.0 255.255.0.0 10.10.0.0 255.255.0.0

SITE C
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.0.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.1.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.10.0.0 255.255.0.0 10.6.0.0 255.255.0.0


SITE A - sh route
C    172.18.4.0 255.255.255.0 is directly connected, inside
C    127.0.0.0 255.255.255.0 is directly connected, _internal_loopback
S    10.10.0.0 255.255.0.0 [1/0] via 12.231.x.x, outside
S    10.8.0.0 255.255.0.0 [1/0] via 172.18.4.1, inside
S    10.2.0.0 255.255.0.0 [1/0] via 172.18.4.1, inside
S    10.0.0.0 255.255.0.0 [1/0] via 172.18.4.1, inside
S    10.1.0.0 255.255.0.0 [1/0] via 172.18.4.1, inside
S    10.6.0.0 255.255.0.0 [1/0] via 12.231.x.x, outside
S    10.5.0.0 255.255.0.0 [1/0] via 172.18.4.1, inside
C    12.231.x.x 255.255.255.192 is directly connected, outside
S*   0.0.0.0 0.0.0.0 [1/0] via 12.231.x.x, outside

SITE B - sh route
C    64.x.x.x 255.255.255.240 is directly connected, outside
S    172.18.4.0 255.255.255.0 [1/0] via 64.x.x.x, outside
S    10.10.0.0 255.255.0.0 [1/0] via 64.x.x.x, outside
S    10.2.0.0 255.255.0.0 [1/0] via 64.x.x.x, outside
S    10.0.0.0 255.255.0.0 [1/0] via 64.x.x.x, outside
S    10.1.0.0 255.255.0.0 [1/0] via 64.x.x.x, outside
C    10.6.0.0 255.255.0.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 64.x.x.x, outside

SITE C - sh route
S    172.18.4.0 255.255.255.0 [1/0] via 12.192.x.x, outside
C    127.1.0.0 255.255.0.0 is directly connected, _internal_loopback
C    10.10.0.0 255.255.0.0 is directly connected, inside
S    10.2.0.0 255.255.0.0 [1/0] via 12.192.x.x, outside
S    10.0.0.0 255.255.0.0 [1/0] via 12.192.x.x, outside
S    10.1.0.0 255.255.0.0 [1/0] via 12.192.x.x, outside
S    10.6.0.0 255.255.0.0 [1/0] via 12.192.x.x, outside
C    12.192.x.x 255.255.255.0 is directly connected, outside
S*   0.0.0.0 0.0.0.0 [1/0] via 12.192.x.x, outside


SITE A - show run access-group
access-group outside_access_in in interface outside

SITE B - show run access-group
access-group outside_access_in in interface outside

SITE C - show run access-group
access-group outside_access_in in interface outside

Open in new window

0
 
LVL 1

Assisted Solution

by:David Blair
David Blair earned 0 total points
ID: 39917762
Point of clarification on the above....  As mentioned in the original question there are several 10.x.x.x subnets at Site A, and technically there should be statements for 10.5.0.0 and 10.8.0.0.  For testing I just did the three subnets that are most critical: 10.0.0.0/16, 10.1.0.0/16, and 10.2.0.0/16.
0
 
LVL 1

Accepted Solution

by:
David Blair earned 0 total points
ID: 39918093
Found the answer.  It apparently WAS necessary to have the subnet-specific crypto statements, but it was ALSO necessary to have this line in the config:

same-security-traffic permit intra-interface

Thanks for your help!
0
 
LVL 1

Author Closing Comment

by:David Blair
ID: 39931098
Found the solution on Cisco's website, of all places!
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Imagine you have a shopping list of items you need to get at the grocery store. You have two options: A. Take one trip to the grocery store and get everything you need for the week, or B. Take multiple trips, buying an item at a time, to achieve t…
Many of the companies I’ve worked with have embraced cloud solutions due to their desire to “get out of the datacenter business.” The ability to achieve better security and availability, and the speed with which they are able to deploy, is far grea…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …

756 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question