Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

As I asked here and duplicated here it appears NAT Hairpinning is the answer I'm looking for to allow internal servers to loopback through the ASA to access external IP's (without using DNS Doctoring). However, the instructions presented in those posts, and here, http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#solution2 do not seem to cover NAT Hairpinning on IOS 8.3+ (I'm running 9.1) 9.1 doesn't even have the static command (by itself) anymore.

How do I NAT Hairpin in IOS 8.3+ (specifically 9.1(2) on a Cisco ASA 5505).



This is what I posted to Cisco's Support site... perhaps the additional information makes my situation more clear

I can't seem to get nat hairpinning to work... Most instructions on the internet indicate how to do this with commands available prior to 8.3.

I've tried the following:

same-security-traffic permit intra-interface

asa-box(config-network-object)# object network my-inside-address-obj
asa-box(config-network-object)# nat (inside,inside) static my-outside-address-obj

which didn't work.

Then I added:

access-list hairpin_allow extended permit tcp object Internal_NAT_Range object External_NAT_Range


access-group hairpin_allow in interface inside

which also didn't work (trying to show due dilligence here...).

Then I tried:

nat (inside,inside) source static Internal_NAT_Range Internal_NAT_Range destination static External_NAT_Range External_NAT_Range

Still a no go.

Finally, I performed these steps (as seen here): "9. To avoid packet-drops due to the asymmetric nature of routing that's occuring internally, we need the ASA to bypass stateful inspection for this particular traffic. For this, we need to configure the following:

ASA(config)#access-list tcp_bypass extended permit tcp object Internal_NAT_Range object External_NAT_Range !--- Configure the access list to specify the TCP traffic !--- that needs to by-pass inspection to improve the performance.

!--- Configure the class map and specify the match parameter for the !--- class map to match the interesting traffic.

ASA(config)#class-map tcp_bypass ASA(config-cmap)#description "TCP traffic that bypasses stateful firewall" ASA(config-cmap)#match access-list tcp_bypass

!--- Configure the policy map and specify the class map !--- inside this policy map for the class map.

ASA(config-cmap)#policy-map tcp_bypass_policy ASA(config-pmap)#class tcp_bypass

!--- Use the set connection advanced-options tcp-state-bypass !--- command in order to enable TCP state bypass feature.

ASA(config-pmap-c)#set connection advanced-options tcp-state-bypass

!--- Use the service-policy policymap_name [ global | interface intf ] !--- command in global configuration mode in order to activate a policy map !--- globally on all interfaces or on a targeted interface.

ASA(config-pmap-c)#service-policy tcp_bypass_policy inside"

Again, nothing...

My config (clean/before any of the above) is as follows...

object network External_NAT_Range
 range x.x.56.3 x.x.59.255
object network Internal_NAT_Range
object network InternalIPs
object network VpnIPs
object network InternalIPs_OutOnly

nat (inside,outside) source static InternalIPs InternalIPs destination static VpnIPs VpnIPs no-proxy-arp route-lookup description Un-Nats VPN IPs
nat (inside,outside) source dynamic InternalIPs_OutOnly interface description Allows remaining interior network to access the Internet
object network Internal_NAT_Range
 nat (inside,outside) static External_NAT_Range net-to-net
access-group outside_access_in in interface outside
route outside x.x.56.1 1

I just want to be able to access an external resource, say, http://x.x.56.5 from an internal IP, say,

I tried to use DNS doctoring. The configuration was much simpler, and worked, but when PTR requests came in from the internet, DNS Doctoring seemed to also translate the outbound responses to reflect my internal IP's which was obviously quite wrong...

Any help from you Cisco pros would be appreciated!


share|improve this question
And this is why internal DNS is a useful method to work around this. Sometimes hair pinning works, sometimes it doesn't. I haven't dug deep enough to find out why. Handling via DNS has been far more consistent in my environments. –  ewwhite Dec 6 '13 at 15:45
add comment

1 Answer

As an obsolete ex-PIX/ASA admin I of course found this irresistible. I have no appliance (but an old PIX 506E running 6.3) to try it on, so it's kind of totally lame. But this is what I found in the online documentation for 9.1 and through some random Googling. Reference links are provided at the bottom of the post. So fingers crossed...

Assuming all other config is correct such as routing, access-lists etc, you would still need to use the command

same-security-traffic permit intra-interface

in order to have traffic from an inside client to an externally mapped address allowed to re-translate towards an internal server address, i.e. having it "hairpinned".

To port map the internal address i.i.i.i to the external address x.x.x.x you would prior to 8.3 have used the command

static (inside,inside) x.x.x.x i.i.i.i

in order to allow nat hairpinning for an internal host to the inside server using the external address gotten from dns. This differs from the regular "un-hairpinned" syntax which would be

static (inside,outside) x.x.x.x i.i.i.i

and which naturally also would be present to allow for external clients calling the server using the public ip.

In ver 8.3 and onward this syntax has been rewritten and the corresponding hairpinning-port map instruction to the ASA would look like this as one feeds it in:

asa-box(config)# object network my-outside-address-obj
asa-box(config-network-object)# host x.x.x.x
asa-box(config-network-object)# object network my-inside-address-obj
asa-box(config-network-object)# host i.i.i.i
asa-box(config-network-object)# nat (inside,inside) static my-outside-address-obj

This would be complemented with a regular "un-hairpinned" instruction too.

That seems to be the only real difference I can find, but am of course terribly curious as to how it works in practice.

I found the 9.1 command syntax for port address translation (i.e. corresponding to the old static command) here: http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/firewall/nat_objects.html#wp1106703

I found an absolutely outstanding historical guide to the hairpinning syntax, showing the same example design as it would be configured throughout the different versions here: http://nat0.net/cisco-asa-hairpinning/

Best of luck!

share|improve this answer
I already have the following in my config: object network Internal_NAT_Range nat (inside,outside) static External_NAT_Range net-to-net as soon as I added: nat (inside,inside) static External_NAT_Range my traffic stopped flowing :/ –  Novox Dec 2 '13 at 19:24
Have you got your access-lists in place for the nat (inside,inside)? –  ErikE Dec 2 '13 at 20:35
I do not... please advise how that should work? I have object network External_NAT_Range range description ARIN IPv4 object network Internal_NAT_Range range and I wand the loopback (hairpinning) to allow any internal IP in the range range to be able to access any IP in the range range –  Novox Dec 5 '13 at 17:18
do I want something like access-list hairpin_allow extended permit tcp object Internal_NAT_Range object External_NAT_Range with access-group hairpin_allow in interface inside? –  Novox Dec 5 '13 at 17:28
Ok, they are a requirement, hopefully the only one :-) If I get the time I'll look at it tonight, you'll find them represented in the links above though. –  ErikE Dec 5 '13 at 17:50
show 6 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.