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

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

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

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.