5

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).

Thanks!

UPDATE:

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

with

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
 range 172.17.56.3 172.17.59.255
object network InternalIPs
 subnet 172.17.56.0 255.255.248.0
object network VpnIPs
 subnet 172.17.63.0 255.255.255.0
object network InternalIPs_OutOnly
 range 172.17.60.1 172.17.62.254
...

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 0.0.0.0 0.0.0.0 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, 172.17.56.8

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!

Thanks!

Novox
  • 504
  • 1
  • 9
  • 25
  • 1
    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 06 '13 at 15:45

1 Answers1

2

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!

ErikE
  • 4,676
  • 1
  • 19
  • 25
  • 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 02 '13 at 19:24
  • Have you got your access-lists in place for the nat (inside,inside)? – ErikE Dec 02 '13 at 20:35
  • I do not... please advise how that should work? I have `object network External_NAT_Range range 162.208.56.3 162.208.59.255 description ARIN IPv4 object network Internal_NAT_Range range 172.17.56.3 172.17.59.255` and I wand the loopback (hairpinning) to allow any internal IP in the range `range 172.17.56.3 172.17.59.255` to be able to access any IP in the range `range 162.208.56.3 162.208.59.255` – Novox Dec 05 '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 05 '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 05 '13 at 17:50
  • Thanks. I tried `access-list hairpin_allow extended permit tcp object Internal_NAT_Range object External_NAT_Range` with `access-group hairpin_allow in interface inside` and that didn't seem to fix the issue, also, that link, "http://nat0.net/cisco-asa-hairpinning/" appears to be broken now... I'll try the wayback machine or google cache. – Novox Dec 05 '13 at 18:33
  • OK, I've spent my evenings allowance but think I've identified the missing piece. I've found the pre-8.3 syntax and need to find/work out the post 8.3 one, but it will have to wait until another evening: One also needs to apply dynamic PAT to the client-to-server traffic (=source address of the client is rewritten as an ASA address), or the reply will be directed straight to the client using the servers internal address as source (which the client doesn't expect, it sent to ext). Pre-8.3 the command is similar to 'global (inside) 1 interface' a bit depending on setup. A link or two to follow.. – ErikE Dec 05 '13 at 22:11
  • https://supportforums.cisco.com/thread/2220403 *and* http://www.ciscohacks.com/home/security/hairpinning-with-static-nat *and* http://ckdake.com/content/2009/hairpinning-with-a-cisco-asa.html – ErikE Dec 05 '13 at 22:14
  • Thank you ErikE. I appreciate all your time you are putting into this. I checked those links and they refer to pre-8.3 IOS. I've updated my question to include more information which hopefully makes my situation more clear... – Novox Dec 06 '13 at 15:28
  • FYI ErikE, there is a flurry of activity on my posting at the Cisco Support Site, https://supportforums.cisco.com/message/4111179. My original posting has been hijacked a little, but I'm just happy that there is discussion going on! – Novox Dec 06 '13 at 21:36
  • That's brilliant Novox, I am very excited to be able to work with this without actually having access to a box, even if it makes it darned complicated too :-) However I'm too tired to really think tonight. If you gain insights through whatever channels please do share through writing your own answer! – ErikE Dec 06 '13 at 22:58