This side is long overdue for an ASA “quick reference guide” for configurations, so here it is!
Before diving head first into brand new studies I wanted to create a bottom up config demo of ASA firewalls for reference when needing to configure or troubleshoot ASA issues, I will give some brief explanations of concepts behind things like Interface Security-Level’s as I configure them.
The WAN is configured to communicate already, otherwise this will be essentially configuring from scratch, to really cover all basic configurations you will see on a Production ASA.
*** I will have a Part 2 that goes into more NAT and VPN Configuration!***
Starting with Site B configuring interfaces, and building from there!
Configuring Physical Interfaces / Security-Levels
Again the WAN Interfaces are already configured, which can be seen in the below output how it is configured with both an IP Address and a “nameif outside” to indicate it is not a trusted interface:
ASAv2# sh run int gi0/1
!
interface GigabitEthernet0/1
description to GigabitEthernet0/1.INET
duplex full
nameif outside
security-level 0
ip address 200.200.200.1 255.255.255.252
ASAv2#
Security-level is ranged from 0 – 100 with 0 being the least “trusted” rating, meaning traffic sourced from “Outside” cannot talk to any interface with a higher Security-Level without a configured ACL allowing it.
On the other hand, there is the “nameif inside” or LAN interface:
ASAv2(config-if)#
ASAv2(config-if)# int gi0/0
ASAv2(config-if)# nameif inside
INFO: Security level for “inside” set to 100 by default.
ASAv2(config-if)# ip add 10.2.2.254 255.255.255.0
ASAv2(config-if)# no shut
ASAv2(config-if)#
ASAv2(config-if)# sh run int gi0/0
!
interface GigabitEthernet0/0
description to GigabitEthernet0/0.IOSSW2
duplex full
nameif inside
security-level 100
ip address 10.2.2.254 255.255.255.0
ASAv2(config-if)#
Using the “nameif inside / outside” command on an interface tells it whether its completely trusted or not trusted at all, meaning that “inside” will be able to send traffic to the lest trusted “outside” interface, but “outside” cannot send traffic to the inside interface because it is less trusted (without an ACL).
Then we have the DMZ interface which requires a custom Security-level:
ASAv2(config-if)#
ASAv2(config-if)# int m0/0
ASAv2(config-if)# nameif DMZ
INFO: Security level for “DMZ” set to 0 by default.
ASAv2(config-if)#
ASAv2(config-if)# security-level 90
ASAv2(config-if)# ip add 10.5.5.254 255.255.255.0
ASAv2(config-if)# no shut
ASAv2(config-if)#
ASAv2(config-if)# sh run int m0/0
!
interface Management0/0
duplex full
nameif DMZ
security-level 90
ip address 10.5.5.254 255.255.255.0
ASAv2(config-if)#
You are seeing that right, the ASAv only has 2 Gig Interfaces, so the Mgmt Int is configured as the DMZ.
We now have 3 different Security “Zones” with different levels of trust:
- Outside – Security-level 0 – Cannot talk into any other zone
- Inside – Security-level 100 – Can talk into any other zone (because its most trusted by default)
- DMZ – Can only talk into the Outside zone, can’t talk to Inside, but Inside can talk into it
If we don’t want ANYONE talking to the DMZ interface, we can configure an ACL on the Inside interface to drop traffic destined to the DMZ interface (most common), or we can adjust the Inside int Security-level:
ASAv2(config-if)#
ASAv2(config-if)# int gi0/0
ASAv2(config-if)# security-level 80
ASAv2(config-if)#
ASAv2(config-if)# sh run int gi0/0
!
interface GigabitEthernet0/0
description to GigabitEthernet0/0.IOSSW2
duplex full
nameif inside
security-level 80
ip address 10.2.2.254 255.255.255.0
ASAv2(config-if)#
Now the DMZ can talk to both the Inside and Outside interfaces, Inside can talk only to the Outside, and Outside interface cannot talk to anyone without an ACL allowing it.
Knowing this concept is key to preventing unintended access to a DMZ, but ACL’s should be configured on every interface to very intentionally allow traffic, for that reason I set Inside back to its default 100.
Next I need DHCP configured for my LAN and DMZ zones
I need 2 DHCP Pools as I want my LAN and DMZ to be provided with DHCP from the ASA:
ASAv2(config)#
ASAv2(config)# dhcpd address 10.5.5.10-10.5.5.20 DMZ
ASAv2(config)# dhcpd dns 8.8.8.8
ASAv2(config)# dhcpd domain loopedback.com
ASAv2(config)# dhcpd option 3 ip 10.5.5.254 int DMZ
ASAv2(config)# dhcpd enable DMZ
ASAv2(config)#
ASAv2(config)#
ASAv2(config)# dhcpd address 10.2.2.10-10.2.2.20 inside
ASAv2(config)# dhcpd option 3 ip 10.2.2.254 int inside
ASAv2(config)# dhcpd enable inside
ASAv2(config)#
ASAv2(config)#
ASAv2(config)# sh run dhcpd
dhcpd dns 8.8.8.8
dhcpd domain loopedback.com
!
dhcpd address 10.2.2.10-10.2.2.20 inside
dhcpd option 3 ip 10.2.2.254 interface inside
dhcpd enable inside
!
dhcpd address 10.5.5.10-10.5.5.20 DMZ
dhcpd option 3 ip 10.5.5.254 interface DMZ
dhcpd enable DMZ
!
ASAv2(config)#
Note that DNS and Domain are lumped together as they apply globally to DHCP Pools, these are both optional configurations, and the required configs are lumped together for both pools.
Now I can turn on my Hosts in the DMZ and Inside zones, and verify they can ping their gateway:
DMZ Host:
LAN Host B:
We are ready to configure ACL’s to the interfaces to manage traffic between interfaces!
ACL configuration for interface communication
I first make an ACL allowing “ip any any” to allow all inbound traffic to traverse the inside interface:
ASAv2(config)# access-list inside_in extended permit ip any any
ASAv2(config)# access-group inside_in in int inside
ASAv2(config)#
Given the Inside interface was the most trusted it could have sent traffic to the DMZ or Outside interface without an ACL, and even though Inside can talk to DMZ zone, the communication would fail because the DMZ zone will require an ACL allowing traffic to talk into the Inside zone because of its Security-level:
To allow this ping to succeed, I create an ACL allowing traffic from DMZ to Inside zone:
ASAv2(config)# access-list DMZ_in extended permit ip any 10.2.2.0 255.255.255.0
ASAv2(config)# access-group DMZ_in in int DMZ
ASAv2(config)#
This perfectly demonstrates the concept of Security-Levels / allowing return traffic via ACL!
For the Outside interface a “deny any any” ACL is made and applied as a place holder for now:
ASAv2(config)#
ASAv2(config)# access-list outside_in extended deny ip any any
ASAv2(config)# access-group outside_in in int outside
ASAv2(config)#
This ACL is not doing anything that isn’t already being done by the Security-level (dropping all inbound traffic), however it will allow for entries to be added later on, and all interfaces SHOULD have an ACL.
Setting up Dynamic NAT / PAT and a Default Route to the Internet
This type of NAT simply performs PAT to the outside interface, and is a pretty simple config:
ASAv2(config)# nat (inside,outside) source dynamic any interface
ASAv2(config)#
This is where I will have to begin adding entries to “outside_in” ACL to allow at least ICMP traffic to test that this NAT statement is working, so I add a rule to line 1 of the ACL to bump the deny statement down:
ASAv2(config)# access-list outside_in line 1 extended permit icmp any any
ASAv2(config)# sh run access-l
access-list inside_in extended permit ip any any
access-list DMZ_in extended permit ip any 10.2.2.0 255.255.255.0
access-list outside_in extended permit icmp any any
access-list outside_in extended deny ip any any
ASAv2(config)#
Then we should be able to ping an INET IP Address, and see it in our NAT Xlate table:
ASAv2(config)#
ASAv2(config)# sh xlate
1 in use, 4 most used
Flags: D – DNS, e – extended, I – identity, i – dynamic, r – portmap,
s – static, T – twice, N – net-to-net
NAT from outside:0.0.0.0/0 to inside:0.0.0.0/0
flags sIT idle 0:01:17 timeout 0:00:00
ASAv2(config)#
“sh xlate” will show all NAT translations the ASA is keeping track of, when troubleshooting a NAT issue I will generally use “sh xlate | i 10.2.2.10” to see if there is an entry for a specific IP for the NAT rule, however because this is NAT Overload to the Outside interface it has no IP Address mapped.
To dynamically NAT just the inside LAN, the NAT config would be inside a LAN network object:
ASAv2(config)#
ASAv2(config)# no nat (inside,outside) source dynamic any interface
ASAv2(config)# object network obj-10.2.2.0
ASAv2(config-network-object)# subnet 10.2.2.0 255.255.255.0
ASAv2(config-network-object)# nat (inside,outside) source dynamic any interface
ASAv2(config)#
ASAv2(config)# clear xlate
INFO: 0 xlate deleted
ASAv2(config)#
ASAv2(config)# sh xlate
2 in use, 4 most used
Flags: D – DNS, e – extended, I – identity, i – dynamic, r – portmap,
s – static, T – twice, N – net-to-net
NAT from outside:0.0.0.0/0 to inside:0.0.0.0/0
flags sIT idle 0:00:09 timeout 0:00:00
ICMP PAT from inside:10.2.2.10/11 to outside:200.200.200.1/11 flags ri idle 0:00:09 timeout 0:00:30
ASAv2(config)#
ASAv2(config)#
The order of how that was removed and reconfigured:
- Remove global Dynamic NAT
- Create network object named “obj-10.2.2.0”
- Defined the LAN Subnet in that object
- Defined a PAT statement in the network object which Dyamically NATs that objects subnet
- Pinged from Host B again on the LAN
- Cleared xlate table
- “sh xlate” and we now see an entry that has a LAN IP mapped to it!
Now that we are Dynamic NAT experts on an ASA, I think its an appropriate time for some more NAT 🙂
Configuring Static NAT / Port Forwarding from Outside Interface
This configuration uses the same network object creation / NAT within it, so with that fresh its a good time to create a Static NAT for Port 80 traffic to the DMZ Host IP address from the Outside interface.
To make this work I went ahead and configured the ASA on Site A with the same configs I went through on Site B, and Host A is now able to ping the Outside IP of Site B ASA interface:
I can now proceed with configuring the Static NAT / Port Forward, I need to use an actual TCP / UDP Port for this (ICMP is a protocol not a service on with a Port #), so I will try for Port 80 HTTP traffic:
ASAv2(config)# object network obj-dmzhost
ASAv2(config-network-object)# host 10.5.5.10
ASAv2(config-network-object)# nat (inside,outside) static interface service tcp www www
ASAv2(config-network-object)# exit
ASAv2(config)# access-list outside_in line 1 extended permit tcp any host 10.5.5.10 www
ASAv2(config)#
The network object with the Static NAT tells it that any WWW traffic that hits the outside interface will be translated to WWW traffic to the host IP in the object, which then allows the ACL Entry to work as once the traffic hits the outside ACL it will detect the NAT / Port Forward configuration.
To test this NAT I browse to the outside IP of the ASA at Site B, then check “sh xlate” :
ASAv2(config)#
ASAv2(config)# sh xlate
2 in use, 4 most used
Flags: D – DNS, e – extended, I – identity, i – dynamic, r – portmap,
s – static, T – twice, N – net-to-net
NAT from outside:0.0.0.0/0 to inside:0.0.0.0/0
flags sIT idle 0:52:34 timeout 0:00:00
TCP PAT from inside:10.5.5.10 80-80 to outside:200.200.200.1 80-80
flags sr idle 0:11:28 timeout 0:00:00
ASAv2(config)#
^^ This is why I mentioned earlier I use “sh xlate” or “sh xlate | i 10.5.5.10” to check for an active NAT translation when troubleshooting a NAT statement, as the Web Browser never connects on Host A because the DMZ Host is not running IIS but the ASA does forward the traffic per the Static NAT.
So easy a cave man can do it! 🙂
With that I will end this configuration post here, and pick up with more NAT and VPN next
I will “wr mem” all devices and make a separate post to get into no-NAT / Site-to-Site VPN / Client VPN configuration, I’ve exhausted my labbing power for the night so I will pick this up over the weekend with Part 2 of ASA labbing to finish up those critical concepts!
Until next time!!!
The DEVNET GRIND! 