DMZ subnet: to NAT or not to NAT?

I'm looking at setting up a DMZ behind a Cisco ASA that will contain a large number of HTTP front-end load balancers and SSL offload services - over 100 IPs, concentrated on a smaller number of hosts.

In the past I've kept all the hosts on RFC1918 private IPs, and added static mappings (IP-by-IP) for each service I'd normally expose in a DMZ. This has gotten annoying as we've started adding additional DMZ IPs at a fast enough rate that it's becoming annoying setting each one up individually. I'd like to change it so that an entire DMZ subnet is setup to allow HTTP and HTTPS from outside --> dmz, so that the load balancers can just grab new IPs as necessary without updating the ASA configuration every time.

What I'm wondering now is whether it makes sense to have the DMZ be on a RFC1918 subnet and use a static NAT across the entire subnet, or whether I should just let the DMZ be my allocation of external IPs directly, and rely solely on access-lists and identity NAT/NAT exemption.

Some crude ASCII artwork:

Example using direct outside IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
                  +-----> DMZ (1.2.3.0/24)

Example using NATed IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
     (1.2.3.0/24) +-----> DMZ (10.99.0.0/24)

The advantage I see for using the NATed address is portability - I don't need to renumber my internal DMZ if my upstream provider and allocation changes. The downside is complexity - now I have to deal with inside vs. outside IP addresses within my own network, etc. In your experience, which setup works better?

Solution 1:

There are reasons to go in either direction that you and others have mentioned.

Having a layer (kind of a pun) of abstraction in the form of static 1:1 NAT is kind of nice as you likely will not have to renumber internal hosts if your WAN IP block changes. However, the complexities and nuances that NAT introduces to packet flow through an ASA can be problematic when compared to simple routing and ACL checks.

My personal point of view is that NAT is here to stay with IPv4. For IPv4 stacks on hosts, I have no qualms with static NATing on the upstream firewall. For IPv6 stacks on hosts however, no NAT. On the ASA both IPv4 and IPv6 can be run side by side, with NAT for IPv4 and traditional routing for IPv6.

There is one other reason why you may want to go with static NAT and it deals with growth. The ASA does not support secondary IP addresses on interfaces. Say your upstream allocates you a /26 routed directly to your ASA's outside interface. You configure your ASA's dmz interface with the first host IP in the IP subnet leaving you 64 - 2 - 1 = 61 valid host IP's in the subnet to be used by your servers.

If you use all 61 remaining host IP's and need more you go to upstream and say hey I need another /26. They give it to you and route it again, directly to the outside IP of your ASA. You cannot assign the first host IP in the second block to your ASA's dmz interface as a secondary IP address like you can with IOS. This leaves you with a few options --

• Create another interface dmz2 on the ASA (not desirable)
• Give back the /26, ask for a /25, and renumber internally (not desirable)
• Perform static NAT (what we are arguing against doing in this example)

Next take the same paradigm -- this time with 1:1 static NAT outside <-> dmz from the beginning. We use all of the available IP's in our first /26 in 1:1 static NATs. We request a second /26 --

• You can request that the upstream route directly to your ASA outside interface IP directly -- saving you a few addresses as the upstream will not have to assign an address in the block as a secondary IP address on their equipment to be used as a gateway even though you won't need it. Note that most providers take the first 3 host IP addresses as part of VRRP/HSRP reducing your usables.
• If you don't request be directly routed the block the upstream will usually perform the latter half of the previous option. The ASA then proxy ARP's (as it likely does with your first block depending on how it is setup) for local-delivered traffic for those IP's on the broadcast domain to which the outside interface is a member.

Lesson: If you already have a public IP block on your outside interface, always request that subsequent blocks be directly routed to your outside interface IP. This will give you additional usable IP's and you can still static NAT just fine.

No matter direct routed or ASA proxy arp -- with 1:1 static NAT you can start using the second /26 without having to muck around with the dmz subnet. Once you outgrow your dmz subnet you will have to make some accommodations -- but again there is a layer of abstraction and you don't have to muck around on the WAN side.

Final Answer: It depends, but with IPv4 I lean toward NAT in your case.

Solution 2:

I'd not NAT. There's no real value to it. The annoying work in renumbering isn't adding/removing addresses, it's in dealing with all the crap that surrounds it, like transitioning DNS.