cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to Cisco Firewalls Community


524
Views
0
Helpful
5
Replies
Highlighted
Beginner

ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

I have an interesting request from a remote-site not wanting to allow access to a public facing IP.  We have a tunnel between their ASA & ours which hairpins traffic to 2 networks out the outside interface.

(IPs have been changed to protect the innocent)

From the remote-site perspective, they are pointing a host to 10.0.0.1 & 10.0.0.2, then NATing on the edge of their tunnel to destinations 172.16.0.1 & 172.16.0.2 (to keep everything pointed to private IPs).

Our outside interface has a private IP on the 172.16.0.x/24 network.

172.16.0.1 is the real IP of SERVER1

172.16.0.2 is an unused dummy IP on the same subnet, & is only used to NAT to the public I'll refer to as 8.8.8.8.

 

All traffic is initiated from the client's private network, so I would think the stateful TCP connections should allow this to work, & I was able to prove this works in my ASA lab with a simple hairpin nat, but it doesn't seem to be working on the real network with a tunnel involved.  Is there something I'm missing that I need to do to allow this to work?  Packet-tracer shows the NATing is working as expected, but it claims a deny at the end of the hairpin because it's no longer tunneled traffic once it's headed for the public internet.  I've seen in other forums that this is a normal limitation to the packet-tracer tool in regards to tunneled traffic.

 

I have same-security-traffic permit inter/intra-interface enabled.  Either one of my nat statements "should" work, but it doesn't seem to be doing the trick.

 

I've included a generic firewall in the drawing to show our public IP for the L2L tunnel is passed through another firewall to us, & that this firewall has the 172.16.0.0/24 network connected to it.

 

What am I missing to make this work as desired?

hairpin.png

 

 

 

 

 (EDIT/update with details on my ASA)

 

object network PRIV-IP

 host 172.16.0.2
object network PUB-IP
 host 8.8.8.8
object network REMOTE-HOST
 host 192.168.1.10

object network REMOTE-HOST2

 host 192.168.1.11

 

object-group network REMOTE-SITE

 network-object object REMOTE-HOST

 network-object object REMOTE-HOST2

 

access-list TUNNEL-ACL extended permit ip object SERVER1 object-group REMOTE-SITE
access-list TUNNEL-ACL extended permit ip object PRIV-IP object-group REMOTE-SITE
crypto map outside_map 10 match address TUNNEL-ACL

 

nat (outside,outside) source static REMOTE-HOST REMOTE-HOST destination static PRIV-IP PUB-IP
[should also work?] nat (outside,outside) source dynamic REMOTE-HOST interface destination static PRIV-IP PUB-IP

 

object network REMOTE-HOST

 nat (outside,outside) dynamic interface

object network REMOTE-HOST2

 nat (outside,outside) dynamic interface

5 REPLIES 5
VIP Advocate

Re: ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

Are you NATing at both firewalls? 10.0.0.2 to 172.16.0.2 and then again 172.16.0.2 to 8.8.8.8?

--
Please remember to rate and select a correct answer
Beginner

Re: ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

yes.

 Updated original post with more details, but here's the essential nat flow:

10.0.0.2 > 172.16.0.2 (tunnel) 172.16.0.2 > 8.8.8.8

Frequent Contributor

Re: ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

Can you add route-lookup at the end of the nat statement?
Beginner

Re: ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

No, it will not accept that command.  I think I can only use that if I'm keeping the NATs the same on the statement.

 

Sorry for the delay- I was waiting on feedback if I could have the remote ASA NAT to the real IP before the tunnel but was just denied, so I'm back to trying to making this thrice-nat thing work again.

Beginner

Re: ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet

UPDATE:

I ended up routing this traffic Inside instead of haripinning.  Funny thing is it still didn't work until I removed the network objects referenced in the NAT statement & added them back.  Since that fixed it, I didn't care to try it with the hairpin again to see if that was really all I needed to do.