Why don't more organizations use inside-to-inside NAT or similar solutions to allow NAT hairpins?

Obviously, there cannot be the definite answer for this, but I could think of a number of reasons:

1. Elegance: NAT is not very elegant to begin with, but a necessity with IPv4's restricted address space. If I can avoid NAT, I will. With IPv6 the problem is going away at any rate.
2. Complexity: especially in a case where you do not have just one single "core" router creating all of your security boundaries, filter configuraions can become quite tricky. Either that or you would have to spread and maintain the NAT rules across nearly all of your router devices.
3. Reference: wherever firewall admins are different folks than the rest of the server admin team, they might be difficult to reach. In order to ensure that changes are not delayed by the firewall admin's backlog (or vacations), the option to keep the responsibility in the same team is chosen
4. Portability and common practice: Using DNS views is "just the thing everybody knows is done" to solve this problem. Not every boundary router would support loopback NAT in a straightforward way, less people are likely to know how to set it up correctly in your specific environment. When troubleshooting network issues, the crew would need to be aware of the hairpin NAT configuration and all of its implications - even when they are chasing an apparently unrelated problem

There are a few reasons why I wouldn't do it:

• Why put extra strain on the DMZ routers and firewall if you don't need to? Most our internal services are not in the DMZ but the general corporate area, with proxying services in the DMZ for occasional remote access. Doing inside-to-inside nat adds more load to the DMZ, which in our case would be significant.
• If you don't do DNAT + SNAT, you will get asymettric routing, which is notoriously tricky to get right. So you SNAT and lose source IP infomation. However, it is bloody useful to link source IPs to people for troubleshooting purposes. Or occasionally nerfshooting purposes in cases of stupidity. "Hey this IP is doing something wonky on unauthenticated service X" "Oh, let's look in the imap server logs who it is".

Disclaimer - this is a flamebait answer.

A common reason i think solutions like this are avoided is an irrational fear/hatred of NAT on the part of network engineers. If you want to see some examples of discussion on this, check out these:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Tom's blog seems to keep attracting rather fervent NAT/IPv6 discussion)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (my blog)

From what i can tell, a lot of this fear stems from Cisco's poor implementations of NAT (so in that sense it may not be irrational), but to my mind the "classic" network engineer is so well-schooled in the "NAT is bad" worldview, that he or she can't see obvious examples like this where it makes perfect sense and actually simplifies the solution.

There you go - downvote to your heart's content! :-)

My guess is:

1. Split DNS is more easily understood.
2. NAT Hairpin uses up resources on the router while split-dns doesn't.
3. Routers may have bandwidth limitations that you don't get through a split-dns setup.
4. Split-dns will always be better performing as you avoid a routing/NAT steps.

On the plus side for hairpin NAT,

• Once it's setup it just works.
• No issues with DNS caches for laptops moved between work network and public internet.
• DNS for a server is only managed in one place.

For a small network with low traffic requirements to an internal server I'd go with hairpin NAT. For a larger network with many connections to the server and where bandwidth and latency are important, go with split-dns.

From my perspective, this changed a bit between the Cisco Pix to ASA transition. Lost the alias command. And in general, accessing the outside address from the inside interface on a Cisco firewall requires some sort of trickery. See: How do I reach my internal server on the external IP?

We don't always need to maintain a duplicate internal DNS zone, though. The Cisco ASA can redirect DNS queries for external addresses to internal addresses if configured on the NAT statement. But I prefer to keep an internal zone for the public DNS zone in order to have that granularity and to be able to manage this in one place rather than step to the firewall.

Typically, there are only a few servers that may require this within an environment (mail, web, a few public services), so it hasn't been a tremendous problem.

I can think of a few reasons:

1. Many organizations have split DNS already as a result of not wanting to publish all of their internal DNS information to the world, so it isn't much additional effort to handle the few servers that are also exposed via a public IP.
2. As an organization and its network grows larger, they often separate the systems servicing internal folks from servers servicing externals, so routing to the external ones for internal usage may be a much longer network path.
3. The fewer modifications that intermediary devices make to packets, the better it is when it comes to latency, response time, device load, and troubleshooting.
4. (very minor, admittedly) There are protocols that NAT will still break if the NATing device doesn't go beyond the headers of the packet and modify data in it with the new IP address(es). Even if it is just a case of institutional memory, it is still a valid reason for people to avoid it, especially if they are dealing with a protocol that they aren't 100% certain about.

If I were going to use NAT loopback I would be a bit worried about how the NAT device will handle spoofed source addresses. If it doesn't check which interface the packet came in, then I could spoof internal addresses from the WAN and send packets to the server with internal addresses. I couldn't get replies, but I might be able to compromise the server using an internal address.

I would setup NAT loopback, plug into the DMZ switch and send packets in with spoofed internal source addresses. Check the server log to see if they were received. Then I would go to the coffee shop and see if my ISP is blocking spoofed addresses. If I found my NAT router wasn't checking source interface, I probably wouldn't use NAT loopback even if my ISP is checking.