AnyConnect Client/Remote Site-to-Site connect to Remote Site-To-Site via HQ Hairpin.

stownsend · ‎02-25-2015

I'm trying to get my Remote Sites and my Remote AnyConnect Clients to be able to communicate with each other.

Remote ASA5505 <--> ASA5510 HQ <--> Remote ASA5505

AnyConnect <--> ASA5510 HQ <--> Remote ASA5505

The ASAs are running 8.3(2)

I've googled many of the Hairpin configs, and have the 'same-security-traffic permit intra-interface' command in the Config, which it is and then having the proper NAT exclusion in there. Many of the config examples seem to reference the deprecated NAT commands that do not work on 8.3(2)

I have in the Config

object network Network-HQ  
 subnet 10.0.0.0 255.255.0.0
object network Network-Site1  
 subnet 10.1.0.0 255.255.0.0
object network Network-Site2  
 subnet 10.2.0.0 255.255.0.0
object network Network-Site3
 subnet 10.3.0.0 255.255.0.0
object network Network-AnyCon  
 subnet 10.100.0.0 255.255.0.0


object-group network REMOTE_NETWORK
 network-object object Network-Site1
 network-object object Network-Site2
 network-object object Network-Site3
 network-object object Network-AnyCon

object-group network LOCAL_NETWORK
 network-object object NETWORK-HQ

nat (inside,outside) source static LOCAL_NETWORK LOCAL_NETWORK destination static REMOTE_NETWORK REMOTE_NETWORK 
nat (outside,outside) source static REMOTE_NETWORK REMOTE_NETWORK destination static REMOTE_NETWORK REMOTE_NETWORK

same-security-traffic permit intra-interface

I also have an Access List on the Outside Interface

access-group outside_access_in in interface outside

So I toyed around with access-Lists too and Added the following:

access-list outside_access_in extended permit ip object-group LOCAL_NETWORK object-group REMOTE_NETWORK 
access-list outside_access_in extended permit ip object-group REMOTE_NETWORK object-group REMOTE_NETWORK 
access-list outside_access_in extended permit ip object-group REMOTE_NETWORK object-group LOCAL_NETWORK

Still No Love.

In the Configs that used the deprecated NAT they also mentioned that the NAT statements needed to be first in the list. I'm not sure how to order them.

Any Suggestions would be helpful.

Thanks!

rizwanr74 · ‎02-26-2015

Please remove this object from REMOTE_NETWORK

object-group network REMOTE_NETWORK
no network-object object Network-AnyCon

Lets say this: 10.1.0.10 is permitted to access via the tunnels to all remote-LANs via site-to-site tunnels.

Lets create a dynamic-nat, so that your remote-in clients can access remote-lans as if they are coming from HQ directly.

object network HQ-UNUSED-IP
description: this is permited to traves to remote all sites
network-object host 10.1.0.10

nat (outside,outside) source dynamic Network-AnyCon HQ-UNUSED-IP destination static REMOTE_NETWORK REMOTE_NETWORK

Please remove these below lines, because tunnel bound traffic does not go via the acl filters put on outside interface.

no access-list outside_access_in extended permit ip object-group LOCAL_NETWORK object-group REMOTE_NETWORK
no access-list outside_access_in extended permit ip object-group REMOTE_NETWORK object-group REMOTE_NETWORK
no access-list outside_access_in extended permit ip object-group REMOTE_NETWORK object-group LOCAL_NETWORK

Hope this helps.

Thanks

Rizwan Rafeek

stownsend · ‎02-26-2015

Thank you for your reply, Though I'm confused why I would need to use a HQ-UNUSED-IP for the NAT? Why can I not use the original Source IP, they are all 10.x.x.x addresses.

I would like Remote Site A to Talk to Remote Site B and AnyConnect Client to Talk to Either Site A or Site B (as well as HQ) that's why I though these were what I needed, any think local to remote and anything remote to anything remote.

nat (inside,outside) source static LOCAL_NETWORK LOCAL_NETWORK destination static REMOTE_NETWORK REMOTE_NETWORK 
nat (outside,outside) source static REMOTE_NETWORK REMOTE_NETWORK destination static REMOTE_NETWORK REMOTE_NETWORK

rizwanr74 · ‎02-26-2015

If your remote tunnel administrators willing to add your AnyConnect pool range into permit line (i.e. in the crytop ACL at their end) to traverse via the tunnel, then you won't need a dynamic nat.

In which case you need is nat exemption to outside to outside, for AnyConnect accessing remote-LANs, similarly for Remote-LAN accessing another Remote-LAN and then again you need to inform remote tunnel administrators to permit other remote-LANs along with your AnyConnect subnet range to be permitted in the crypto ACL and set for them nat-exemption as well.

Hope that answers your question.

Thanks