Solved

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

Posted on 2014-03-07
9
2,018 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
Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

 
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

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

Question has a verified solution.

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

Suggested Solutions

I've written this article to illustrate how we can implement a Dynamic Multipoint VPN (DMVPN) with both hub and spokes having a dynamically assigned non-broadcast multiple-access (NBMA) network IP (public IP). Here is the basic setup of DMVPN Pha…
Let’s list some of the technologies that enable smooth teleworking. 
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 …
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

776 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