06-02-2018 10:02 PM - edited 02-21-2020 07:50 AM
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
06-03-2018 06:03 AM
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?
06-03-2018 12:54 PM - edited 06-03-2018 01:12 PM
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
06-08-2018 06:28 AM
06-20-2018 10:47 AM
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.
07-25-2018 10:57 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide