Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2045
  • Last Modified:

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

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
David Blair
Asked:
David Blair
  • 6
  • 3
3 Solutions
 
naderzCommented:
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
 
David BlairAuthor Commented:
I understand your point, but making that change would prevent both sites B and C from accessing 10. networks at site A.
0
 
naderzCommented:
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
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
David BlairAuthor Commented:
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
 
naderzCommented:
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
 
David BlairAuthor Commented:
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
 
David BlairAuthor Commented:
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
 
David BlairAuthor Commented:
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
 
David BlairAuthor Commented:
Found the solution on Cisco's website, of all places!
0

Featured Post

Free recovery tool for Microsoft Active Directory

Veeam Explorer for Microsoft Active Directory provides fast and reliable object-level recovery for Active Directory from a single-pass, agentless backup or storage snapshot — without the need to restore an entire virtual machine or use third-party tools.

  • 6
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now