Cisco ASA 5505 DMZ Setup Issue
I have an ASA 5505 running v8.4. I have one static IP that my ISP gives me and I need to use that for my INSIDE network as well as my DMZ. This becomes a PAT issue as I need some ports to terminate in the DMZ, and some to terminate in the INSIDE interface. This would be simple if I had multiple IPs but I don't.
I'm wondering if anyone can help me with the proper NAT statements. 8.4 is very different than what I'm used to, so I'm at a loss on how to get this all to work.
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
- outside interface IP: 1.1.1.2/30
- inside interface IP: 192.168.10.1/24
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
- inside 192.168.10.10 needs TCP/22
- dmz 192.168.20.20 needs TCP/53, TCP/80, TCP/443, and UDP/53
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.
object network net-192.168.10.0-24
description inside Network
subnet 192.168.10.0 255.255.255.0
nat (inside,outside) dynamic interface
object network net-192.168.20.0-24
description dmz Network
subnet 192.168.20.0 255.255.255.0
nat (dmz,outside) dynamic interface
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.
object network hst-192.168.10.10
description My inside Host
host 192.168.10.10
object network hst-192.168.10.10-tcp22
description My inside Host NAT SSH
host 192.168.10.10
nat (inside,outside) static interface service tcp 22 22
object network hst-192.168.20.20
description My dmz Host
host 192.168.20.20
object network hst-192.168.20.20-udp53
description My dmz Host DNS
host 192.168.20.20
nat (dmz,outside) static interface service udp 53 53
object network hst-192.168.20.20-tcp80
description My dmz Host HTTP
host 192.168.20.20
nat (dmz,outside) static interface service tcp 80 80
object network hst-192.168.20.20-tcp443
description My dmz Host HTTPS
host 192.168.20.20
nat (dmz,outside) static interface service tcp 443 443
Now define object-group service groups for use in ACL.
object-group service svcgrp-192.168.10.10-tcp tcp
port-object eq 22
object-group service svcgrp-192.168.20.20-udp udp
port-object eq 53
object-group service svcgrp-192.168.20.20-tcp tcp
port-object eq 80
port-object eq 443
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.
access-list outside_access_in extended permit tcp any object hst-192.168.10.10 object-group svcgrp-192.168.10.10-tcp
access-list outside_access_in extended permit udp any object hst-192.168.20.20 object-group svcgrp-192.168.20.20-udp
access-list outside_access_in extended permit tcp any object hst-192.168.20.20 object-group svcgrp-192.168.20.20-tcp
Don't forget to bind your ACL to the interface.
access-group outside_access_in in interface outside
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