Why don't more organizations configure NAT U-turns/hairpins?

Question

I asked a similar question a while ago, but foolishly referenced inside-to-inside NAT. Not being a network admin my terminology on the networking side of things was limited and lead to answers that answered my question, but not the spirit of my question.

Imagine a situation which is common for most small/medium businesses that host their own servers:

1. You have a single firewall with multiple interfaces. They are LAN, WAN, and DMZ.

2. Your web/mail servers have RFC1918 addresses that are 1:1 NAT'd from the DMZ interface to public IPs.

3. Devices on the LAN interface regularly communicate with devices on the DMZ interface.

4. You have an Active Directory domain named corp.example.com your web servers are in the external example.com zone.

In a lot of deployments, it is common to see the internal DNS servers (AD Domain Controllers) hosting an internal copy of the example.com zone with the RFC1918 addresses. Why don't more organizations configure NAT U-turns/hairpins so that you don't need a second copy of this zone with different information? Why don't organizations simply have internal DNS for corp.example.com and external DNS for example.com and call it a day?

---

Yes, in large businesses you would ideally have separate DMZ firewalls and even separate DMZ internet connections. This isn't the case in any SMB that I know.

Yes, the ASA has some crappy licensing regarding this. I don't care about licensing constraints, it's just money. I know they can be configured to allow this with same-security-traffic.

I worked in a Juniper shop for years where this worked fine without any crazy configurations, how is it that Cisco admins seem to have so many problems with this? Is it really much easier to accomplish on Juniper kit? It is a limitation of IOS that makes Cisco network admins not interested in configuring it?

Answer 1

Not everyone's network uses devices that can NAT at LAN speeds. It's not unusual to have devices that can route 100Mb/s but NAT a tenth of that while your LAN is all gigabit.

Often you have servers in the DMZ that you need high-speed access to locally. You want to back up your mail and web servers, right? And do you want your backups in the DMZ?

NAT also breaks long-lived, idle connections because the translation times out. Hairpin obscures the origin IP address, making audit trails useless. NAT, other than 1-to-1, is a painful hack, and you want internal traffic to be reliable.

Attack resistance is another issue. Connection flooding can cause your NAT device to run out of slots and there are companies that reboot their Internet-facing equipment regularly and would prefer not to disturb long-lived internal connections. Even if your equipment is entirely reliable, separating the internal network from the devices that handle the public IP space is just a good idea.

Answer 2

This is how I was taught, so I don't have a better answer... but for me, it eliminates the reliance on the firewall device. In small businesses, the firewalls are typically low-end products (think Linksys/Dlink/Sonicwall). Relying on it to access internal resources from inside the network can create problems. It's a bad dependency.

I have a client now who reboots their Cisco ASA 5510 firewall several times a day to fix a VoIP problem for remote users (probably an xlate issue). For their internal users who use Exchange and the usual public/private services, having internal DNS redirection at least limits the impact of the firewall reboots.

Edit:

But I needed it in a pinch recently...