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.
Best Answer
ASA 8.3 and up pretty much forces the use of objects when configuring NAT. While this can be troubling to those who have been administering PIX/ASA for many years without using objects, over the last 6 or so months I have actually grown to like the new NAT paradigm. Static PAT -- what you will be doing to "port forward" in ports to inside and dmz hosts, does not fit quite as cleanly as I would have liked.
Some may disagree with my object naming scheme -- know that it is in use in over 100 ASA's, a few with over 1500 line configuration files -- and does wonders for keeping things straight on the CLI.
The links posted in the aforementioned answers are a great start.
I highly advise reading the ASA 8.4 CLI configuration guide NAT section first. Even if you do not understand it -- read it first to get the terms.
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_overview.html
Then follow-up with Jay Johnston's video. I found it quite helpful when I was first trying to wrap my head around things.
https://supportforums.cisco.com/docs/DOC-12324
Moving on to your question directly.
Assuming
dmz interface IP: 192.168.20.1/24
Dynamic PAT needed for inside and dmz subnets.
Static PAT (port forwarding) needed for particular inside and dmz hosts defined below
Define the network objects for your networks first, and configure the object NAT for dynamic PAT for both objects. Note that I am using my object naming standard. If you show run you will see the "object network ..." for each object twice. Once for the object definition and then again later on in the configuration with only nat statement.
Define the network objects for your hosts. This is where PAT gets a little hairy in 8.3 and up. We define an object for the host itself (to be used in the ACL to make it easy). Then we define another network object for each port that is needed. With traditional static NAT this is very easy and beautiful -- with static PAT it can get a little a little cumbersome, but is still very descriptive.
Now define object-group service groups for use in ACL.
With objects and object-groups configured, NAT configured (using network object NAT dynamic PAT and static PAT) -- all that is left is the ACL side of things.
This is where this really comes together -- especially traditional static NAT scenarios. In ASA 8.3+ UN-NAT (and NAT) happens before L3/L4/access-group ACL check -- so use real IP's in access-group ACL's -- even when bound to outside interface.
Don't forget to bind your ACL to the interface.
Note that I stay away from "friendly names" in the object identifiers. Makes it a PITA when you are debugging on the CLI. I find the object names I use is very descriptive and handy in real world scenarios.
Additionally, with static NAT permitting additional ports you only have to add a port-object entry to the host's svcgrp object. With static PAT, however, you will have to add a new network object for the static PAT -- only one nat statement permitted per object -- and add the port-object to the host's svcgrp object.
A feature request has been filed with Cisco to allow multiple static PAT statements per network object. This would reduce the number of network objects needed greatly in static PAT scenarios. As of yet, it has not been added.
-Weaver