topic ASA 5510 Hairpin/U-Turn Traffic to escape tunnel to public internet in Network Security

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

wstucky01 — Fri, 21 Feb 2020 15:50:34 GMT

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?

(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

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

Marius Gunnerud — Sun, 03 Jun 2018 13:03:55 GMT

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?

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

wstucky01 — Sun, 03 Jun 2018 20:12:56 GMT

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

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

Florin Barhala — Fri, 08 Jun 2018 13:28:28 GMT

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

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

wstucky01 — Wed, 20 Jun 2018 17:47:51 GMT

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.

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

wstucky01 — Wed, 25 Jul 2018 17:57:19 GMT

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.