ASA and Hairpinning/u-turn external NAT rule for DMZ host with 9.2.4

[Stephen Saunders]

Here is the issue. We used 5520's with 8.4(6) on them and were able to allow our inside hosts to hit a DMZ host using the DMZ's real IP address and the inside hosts could also hit the NAT address of those hosts. So in my example, host 10.1.1.22 could access the DMZ host of 192.168.1.33 and it's public IP of 172.33.33.33 without issues. We replaced those ASA's with a pair of 5525's with 9.2(4) and now can't access the NAT address of the DMZ host without me doing some crazy stuff or breaking access to the real IP address. So in other words, without adding a work around, our inside hosts can get to either the public IP address or the private IP address of the DMZ, you can't access both. I'll add some fictitious lines representing the config and add the log file output using those IP's. It acts like it has no idea what how to handle the NAT translation. You can easily fix it by changing the NAT rule to not use specific interfaces, however that makes the real IP address inaccessible. I would like to know if there is a fix for this or if I would have to continue to put work arounds in? 

!Sample Config below

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

object network TESTMRR1
 host 192.168.1.33

object network TESTMRR1_NAT
 host 172.33.33.33

object network DefaultDynamic
 host 172.33.33.2

object network TESTMRR1
 nat (WebDMZ, Public) static TESTMRR1_NAT

nat (Inside,Public) after-auto source dynamic any DefaultDynamic

!Sample Log output

Jun  9 08:51:22 asa1 Jun 09 2015 08:51:22: %ASA-6-302013: Built outbound TCP connection 42677175 for Public:172.33.33.33/80 (172.33.33.33/80) to Inside:10.1.1.22/52506 (172.33.33.2/52506)

Jun  9 08:51:52 asa1 Jun 09 2015 08:51:52: %ASA-6-302014: Teardown TCP connection 42677175 for Public:172.33.33.33/80 to Inside:10.1.1.22/52506 duration 0:00:30 bytes 0 SYN Timeout

I know how to work around the issue (there are several ways), but none of them are pretty, I would much rather have a simple object NAT like above, this used to work with 8.4(6) and now it is broken with our new 9.2(4) 5525's. Again, I can work around it with some crazy methods (I have a couple methods), but I'd prefer to not use a work around. Maybe there is a new command to allow this to happen, I've researched it for a few hours and can't find anything out there for this.

Thanks in advance

[Vibhor Amrodia]

Hi ,

You can use a Manual NAT statement for this requirement:-
nat (inside,Webdmz) source dynamic any interface destination static TESTMRR1_NAT TESTMRR1

Thanks and Regards,

Vibhor Amrodia

[Stephen Saunders]

Sorry Vibhor, but that doesn't help. That will make the NAT address accessible from the inside, but then the actual IP address will not be accessible anymore. I can work around the issue by putting a couple other NAT statements in, but this seems like it should work just like the older version of ASA's. Like I said, I can work around it, one method is to put a few NAT statements in to compensate for it, or I can simply route the traffic out another ASA or I can tell everyone to use just the public IP's of the servers and not the DMZ address. Neither option is very clean and leads to confusion. The ASA should allow me to NAT a device to the outside and if I try to hit that NAT address from the inside, it should allow us to hairpin the connection on the Public (outside) interface. If this feature is not allowed anymore, please let me know what version of firmware that I can downgrade our ASA's to, so I can get this feature back. Thank you for the response though, I appreciate it.

[prateek.verma]

Hi Stephen,

Could you try the following commands:

object-network obj-10.1.0.0

subnet 10.1.0.0 255.255.0.0 (this is just for an example enter your inside subnet here)

exit

nat (inside,Webdmz) source dynamic  obj-10.1.0.0  interface destination static TESTMRR1_NAT TESTMRR1

Regards,

Prateek Verma

[David McCaleb]

I have the same issue.  The problem seems to occur when upgrading from 9.1 to 9.2.  I'm running sub interfaces over a trunk.  Are you running sub interfaces?  This could be attributed to sub interfaces.

[Stephen Saunders]

We are using sub interfaces. Were you able to resolve the issue by changing from sub interfaces or did you just downgrade the ASA's?

[David McCaleb]

We rolled back to 9.1 and the problem went away.  This is a production ASA and we don't have the resources to lab a replica. I have another client with a near identical setup, but without sub interfaces. That client does not have any issues.  This appears to be a major bug with NAT and sub interfaces on 9.2+.  Hopefully many of us can open TAC cases and pressure Cisco to expedite a fix.  I like the flexibility of sub interfaces; however, we need to get SourceFire up and running so 9.2 is a must.

[Stephen Saunders]

I goofed and put a post in the wrong place, I have corrected it, but for some reason it won't let me delete this reply so I'm putting garbage in :).

[Stephen Saunders]

I might submit a support ticket to Cisco using my companies account, being that I'm not getting too many responses (thank you David and Vibhor for your responses). In the meantime, I figured I would show you all a work around in case someone else run's into this issue. We can't downgrade to 9.1 because we are using BGP on our ASA pair and would rather not rip that configuration out. The section title Sample Config is copied from above, then below that in the workaround section is the commands needed to work around this issue. Just to be clear, what this gives you the ability to do is access a DMZ host using it's real IP address or it's externally NAT'ed address, in the past (I think 8.3 and above), the sample code was sufficient.

!Sample Config below

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

object network TESTMRR1
 host 192.168.1.33

object network TESTMRR1_NAT
 host 172.33.33.33

object network DefaultDynamic
 host 172.33.33.2

object network TESTMRR1
 nat (WebDMZ, Public) static TESTMRR1_NAT

nat (Inside,Public) after-auto source dynamic any DefaultDynamic

!!Work around

nat (Inside,WebDMZ) source static any any destination static WebDMZ_Network WebDMZ_Network no-proxy-arp route-lookup

!Change your object NAT to use any interface instead of being specific

object network TESTMRR1
 nat (any, any) static TESTMRR1_NAT

The work around basically tells the ASA to not NAT your internal network when talking to the real IP address of any host in DMZ network but makes the external NAT accessible on any interface. The only issue with this is a little funkiness when you ping the external NAT address, it will reply with the real IP address instead. I've only tested this with a simple web server and so far and it seems to be fine. Using TCP instead of ICMP seems to show the correct IP (I used wireshark to tell). If for some reason you have an app that has issues with this, you could add the following command (needs to be ABOVE the no NAT command work around) every time you add an object NAT, you would have to add a statement similar to the following. This command basically NAT's your inside network to the DMZ interface of the ASA and NAT's the DMZ host at the same time. Actually doing this method, you probably could change your object NAT back to being on specific interfaces. This way when you ping the external IP of the host, it replies with the external address and not the real IP.

nat (Inside,WebDMZ) source dynamic any interface destination static CPTESTMRR1_NAT CPTESTMRR1

There are two other work arounds and those are to simply do the object NAT and have your inside hosts only use the external IP address, this would keep you from having to add the additional rule(s). The other option would be to route the traffic out another router/firewall for the External IP's. The last option isn't recommended, but can work if you have a spare ASA sitting around and don't want to do either of the above work arounds.