Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a Cisco ASA providing multiple site tunnels to our clients. Most of our employees use standard VPN client connections to the ASA.

However, we also want to allow employees who have a static connection or multiple PCs to use a site tunnel.

How can we allow traffic from Employee1thruX <-> Cisco ASA <-> All Customer Tunnels, whilst not allowing CustomerA Tunnel <-> Cisco ASA <-> CustomerB Tunnel?

share|improve this question
    
How are the crypto ACLs configured, for the customers and for the remote workers? What subnets are assigned and used where? What kind of NAT is in place? It's absolutely possible, but depending on how everything's configured, it might be prohibitively messy to implement. –  Shane Madden Mar 29 '12 at 20:36
    
No NATs are in place - everything is on Private IPs (with unique subnets allocated to each Customer). Current ACLs only allow traffic to / from the ASA and client connections. –  Chromablue Mar 29 '12 at 22:45
    
So, the local network of the IPSec SA is just the ASA? Or are the clients talking to a server in your network? –  Shane Madden Mar 30 '12 at 1:34
    
No, the local network on the ASA has other hosts that can (and do) talk to all spokes. We basically want to say "some spokes can talk to any host on the hub LAN and all other spoke LANs, but other spokes can only talk to hosts on the hub LAN". –  Chromablue Mar 30 '12 at 20:26
    
Can you share some of how the IP scheme is set up? If the assignments follow some good rules (ie, 10.10.0.0/16 is internal, 10.50.0.0/16 is customer networks, and 10.15.0.0/20 is the employee networks), then you may be able to make it work with fairly simple rules. –  Shane Madden Mar 30 '12 at 21:13

1 Answer 1

Something along these lines - 192.168.168.0/24 seems a bit smallish; if you need to, then make an object-group for them too.

same-security-traffic permit intra-interface

object-group network Client_Networks
 ! Load up client network assignments here, so the ACLs don't get huge:
 network-object 192.0.2.0 255.255.255.0
 network-object 198.51.100.0 255.255.255.0

! ACL for tunnel to an example client - this one's on the 192.0.2.0 range.
! The entry covers traffic between the local net and the client
access-list outside_cryptomap_client_1 extended permit ip 172.16.89.0 255.255.255.0 192.0.2.0 255.255.255.0
! And this is needed for the traffic between the employee nets and the client
access-list outside_cryptomap_client_1 extended permit ip 192.168.168.0 255.255.255.0 192.0.2.0 255.255.255.0

! ACL for the tunnel to an employee - we'll stick them on 192.168.168.32/30;
! For the purposes of the tunnel, the client networks are local networks.
! The entry's going to create a ton of IPSec SAs -- makes a mess, but not a lot of choice.
access-list outside_cryptomap_employee_1 extended permit ip object-group Client_Networks 192.168.168.32 255.255.255.252
! And, the local whatnot.
access-list outside_cryptomap_employee_1 extended permit ip 172.16.89.0 255.255.255.0 192.168.168.32 255.255.255.252

! all the other config for the site-to-site tunnels..
crypto map outside_map 1 match address outside_cryptomap_client_1
! ...
crypto map outside_map 501 match address outside_cryptomap_employee_1

And if you have any NAT whatsoever going on, which you probably do since you're using RFC1918 ranges, you need NAT exemptions all around, matching all the traffic in your crypto ACLs.

! add to an existing NAT exemption ACL, if you have one.  Otherwise, make one..
! local to clients
access-list outside_nat0_outbound extended permit ip 172.16.89.0 255.255.255.0 object-group Client_Networks
! local to employees
access-list outside_nat0_outbound extended permit ip 172.16.89.0 255.255.255.0 192.168.168.0 255.255.255.0
! employees to clients
access-list outside_nat0_outbound extended permit ip 192.168.168.0 255.255.255.0 object-group Client_Networks
nat (Public) 0 access-list outside_nat0_outbound

Of course, you'll need to configure the remote VPN endpoint at the employee's location to have the client networks as a remote network, matching the crypto ACL for the site-to-site connection to them.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.