ASA 55XX Hairpinning

[usfregale]

Our VPN is comprised of a ASA 5510 at the hub and ASA 5505s at the spokes. Presently bidirectional communication is possible between all spokes and the hub; however, spoke to spoke communication is impossible. In an attempt to add spoke to spoke communication I added the following commands to our 5510 and two of the 5505s:

ASA 5510 (central site, 10.20.0.0)

same-security-traffic permit intra-interface
access-list 27351_to_13765 extended permit ip 10.123.0.0 255.255.255.0 10.101.0.0 255.255.255.0
access-list 13765_to_27351 extended permit ip 10.101.0.0 255.255.255.0 10.123.0.0 255.255.255.0
access-list nonat extended permit ip 10.123.0.0 255.255.255.0 10.101.0.0 255.255.255.0
access-list nonat extended permit ip 10.101.0.0 255.255.255.0 10.123.0.0 255.255.255.0
nat (inside) 0 access-list nonat

ASA 5505 (remote site, 10.101.0.0)

same-security-traffic permit intra-interface
access-list vpn_to_27351 extended permit ip 10.101.0.0 255.255.255.0 10.123.0.0 255.255.255.0
access-list nonat extended permit ip 10.101.0.0 255.255.255.0 10.123.0.0 255.255.255.0
nat (inside) 0 access-list nonat

ASA 5505 (remote site, 10.123.0.0)

same-security-traffic permit intra-interface
access-list vpn_to_13765 extended permit ip 10.123.0.0 255.255.255.0 10.101.0.0 255.255.255.0
access-list nonat extended permit ip 10.123.0.0 255.255.255.0 10.101.0.0 255.255.255.0
nat (inside) 0 access-list nonat

After making those changes I think it should work; however, it does not. Additionally, I don't fully understand the purpose of the "nat (inside) 0 access-list nonat" command; however, I added it following some reading on the Cisco website.

Thoughts?

Richard

 

[unclerico]

In theory what you have should work. Have you run any debugs?? The nat (inside) 0 command is there so that when each site in the L2L setup attempts to communicate with one another the traffic does not get NATed (called NAT bypass/NAT exemption)

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[usfregale]

I think perhaps I have a misunderstanding of what I'm trying to do. My understanding of hairpinning between three devices is as follows: 2 VPN tunnels are already in place and traffic between the spokes is to be routed through the hub device. In conducting some additional reading it almost appears that hairpinning as described here (

http://www.cisco.com/en/US/products..._configuration_example09186a00804675ac.shtml)

is attempting to create a third VPN tunnel between the two spokes independent of the central site.

This isn't desirable because we don't have static IPs at most of our remote sites (in fact fewer than 5 of our 50+ sites have static IP), what we need is true hairpinning that is routing traffic from the 10.123 network to the 10.20 network and then onto 10.101.

Richard

 

[unclerico]

No it will not create a third tunnel; it will use the existing tunnels to communicate. If you have your routing setup correctly it will work. The beautiful thing about L2L VPN's is you can use RRI or Reverse Route Injection. Each entry in the crypto ACL will be a dynamic route that will be added to each peer. So if you add reverse-route to your crypto map on the hub the 10.101 site should see a route for the 10.123 network and the 10.123 site should see a route for the 10.101 network. Each of these will point to the hub as the next hop in order to allow them to communicate to one another.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[usfregale]

Now for the truly bizarre part. I was able to make the original configuration work by changing the names of the VPN tunnels. I was attempting to assign logical names based on the function of the tunnel "27351_to_13765" paired with "13765_to_27351" for example. Then only one of the tunnels was defined in the actual crypto map, thus the other tunnel didn't have a peer associated with it. By using the same names I was able to make the spoke to spoke communication work. Still having some issues, specifically I can only initiate the VPN tunnel from the 10.101 network rather than from either side. Attempts to contact 10.101 from the 10.123 network are unsuccessful until the tunnel is first opened fro the 10.101 side.

We're using L2L and RA VPN tunnels. Will the RRI work for both types?

The sites in question are three of a total of 45 sites all of which are connected via VPN. Also, I added the "crypto map outside_dyn_map 5 set reverse-route" command to the central site's ASA 5510; however, it hasn't had the intended effect of allowing the various networks to broadly communicate. Have I placed it in the wrong place?

crypto ipsec transform-set ESP-AES-MD5 esp-aes esp-md5-hmac
crypto dynamic-map outside_dyn_map 5 set transform-set ESP-AES-MD5
crypto dynamic-map ouside_dyn_map 5 set reverse-route
crypto map outside_map 65500 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
isakmp identity address
isakmp enable outside
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

Thanks for your help.

Richard

 

[unclerico]

You have it in the right spot. On Spoke1 do you see the route for Spoke2?? Did you enable RRI on all of the devices??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[usfregale]

Since I already had a semi functional tunnel between the 10.101 and 10.123 networks, I added a third network (10.105) to the mix and added the RRI command to that ASA as well as the 10.123 ASA (it was already on the 10.20 ASA). It was unsuccessful and the routes are not visible.

I found a configuration diagram on the Cisco website that seems to indicate that for RRI to function you need to run software version 8.0 or later. We're only running 7.2, so I'm going to upgrade to see if that sheds some light on why the SSI isn't working.

Richard