This article will describe how to configure a basic ASA appliance using current best practices and latest software versions. I recently found myself having to create a standardized configuration for some ASA 5505 devices that would be used in small, remote offices. When researching for current configuration/best practices, I found information from all ends of the spectrum – old pix configs, ASA version 8.2, ASA version 8.3, etc… Some of the examples proved to still be relative, but most was dated and should not be used with modern software versions.

This article will start like most others I found and mentioned previously, with the intention of being current and somewhat future proof, since it is based on latest versions of software to date. However, as we all know, when the next major version appears – this article will also become dated, just as the others are. Maybe, just maybe, I can come back and revisit this article for a refresh from time to time – so that it can retain its usefulness.

If your ASA does not have the latest software, the first thing I would recommend is to go and get it. This is of course, assuming you have access to the Cisco software center via a valid SmartNet contract. If not, hopefully it shipped with something fairly current. Cisco will offer updates that anyone can obtain to fix a security flaw, so check to make sure it is at least the current revision.

The software version this device used to write the article is: ASA Version 8.4(3)

Let’s jump into the initial configuration:

Configure hostname of the device

hostname my-asa-01

Next, we will configure two of the available switchports on the 5505. The model I am using has a total of 8 switchports, with the last two ports able to provide Power Over Ethernet. The Layer3 configuration does not go on the port configuration, we will assign the switchports to a Vlan and then configure the vlan interface (SVC) seperately.

interface Ethernet0/0
switchport access vlan 100
!
interface Ethernet0/1
switchport access vlan 5

As you can see from the previous port configuration, we are using two vlans – 5 and 100. The vlan configuration comes next and is where we assign interface names, security levels, and IP information.

interface Vlan5
 nameif inside
 security-level 100
 ip address 10.1.100.1 255.255.255.0
!
interface Vlan100
 nameif Outside
 security-level 0
 ip address 122.163.21.121 255.255.255.248

Using the interface names ‘inside’ and ‘Outside’ tells the ASA the function of each interface. It knows that when an interface name is called ‘outside‘ that it is directly connected to the (untrusted) Internet. The same thing goes with the name ‘inside‘, the ASA knows this interface will be where all internal hosts will be and automatically makes it the most secure (using security-level command).

The only important thing to know about security levels is that by default, an interface can’t communicate with another interface if it has a higher security level. So, an interface with a security level of 0 (most un-trusted interface out there) can’t communicate with hosts behind an interface with a security level of 100 (most trusted interface out there). Now, in my opinion, the security-level thing is a little dated – but still very much in use. The reason I say this is because the security level doesn’t mean much if you have an explicit (user defined) firewall policy installed. More on that later…

The next thing we need is a NAT statement, because we are using private (RFC-1918) addresses on the internal network and want to communicate with other hosts on the Internet. To do this, we must translate a private, non-internet-routable address into a valid public address (which is assigned to the outside interface).

First the specific information, with the explanation to follow:

object network obj_net_Inside
 subnet 10.1.100.0 255.255.255.0
!
nat (inside,outside) source dynamic obj_net_Inside interface

The first thing in the block of configuration above (object definition) is not NAT specific, but is being used in the NAT configuration. I must say, even though the ‘object’ concept has been in the ASA software for some time now – it has probably been slow to adopt with people who stick to command line only configuration. This is kind of like telling a C programmer that it is time to switch to something more object oriented, like C++ – old habits die hard.

A nice thing with objects is it gives you a opportunity to name all the subnets defined in the ASA, where traditionally when using only access-lists, it did not provide the same capability. So, we have defined a network object named obj_net_Inside and told it the associated subnet is 10.189.87.0/24, which is the network associated with the inside interface.

Now, on to the actual NAT statement that says – perform a network address translation when traffic sources from the inside interface and is destined to the outside interface AND the source IP address matches the object called obj_net_Inside. When the match is made a dynamic translation is performed (PAT) using the IP address assigned to the outside interface of the ASA. This means any traffic from a machine on the internal network will look to a website on the Internet as if the source address is (in this case) 122.163.21.121. Multiple addresses on the inside network can all be translated to the same 122.163.21.121 IP address, because the source port for each request will be made unique (handled by the ASA). By having a unique source address for each request, the reply traffic from the Internet will have a destination port of the random source port used when the request originated. This port number will allow the ASA to lookup in the translation table which inside host the traffic belongs to.

Last, but not least, the ASA needs a default route for access to the Internet. The next hop defined in the route statement is the IP address of the ISP’s interface.

route outside 0.0.0.0 0.0.0.0 122.163.21.126 1

Let’s see what we have with all the previously mentioned bits combined

hostname my-asa-01
!
interface Ethernet0/0
switchport access vlan 100
!
interface Ethernet0/1
switchport access vlan 5
!
interface Vlan5
 nameif inside
 security-level 100
 ip address 10.1.100.1 255.255.255.0
!
interface Vlan100
 nameif Outside
 security-level 0
 ip address 122.163.21.121 255.255.255.248
!
object network obj_net_Inside
 subnet 10.1.100.0 255.255.255.0
!
nat (inside,outside) source dynamic obj_net_Inside interface
route outside 0.0.0.0 0.0.0.0 122.163.21.126 1

That is the basic configuration required to give a machine on the inside network internet access. However, it is far from complete. One of the very next things we need to do is define some actual firewall rules, that provides much finer control than just having security levels assigned to interfaces. By looking at the article size so far, I will leave that for part two of the series.

So, that’s about it for Part 1 – we should have subtitled it: Minimal ASA configuration for basic internet access.

With that being said, what do we need for internet access at this point? Let’s cover that real quick:

I will plug a laptop’s Ethernet interface into port 0/1 on the ASA. In the Ethernet adapter properties, we will assign a static IP, since so far we have nothing that will automatically assign it an IP address. My interface configuration is:

IP address: 10.1.100.100
Subnet mask: 255.255.255.0
Default Gateway: 10.1.100.1

For the DNS server, I will use Google’s public DNS, which is:

DNS1: 8.8.8.8

After configuring my laptop and then opening a command prompt, the first thing I try is to ping the default gateway:

#ping 10.1.100.1
!!!!! 5/5 successful
#

Next thing is let’s make sure I’ll be able to communicate with something on the internet. How about we try and ping the DNS server from the laptop (warning home made ping prompt):

#ping 8.8.8.8
..... 0/5 successful
#

Why doesn’t this work? I can ping 8.8.8.8 successfully from the console of the ASA, assuming all my configuration is correct, why can’t I ping from the laptop? Well, let’s try accessing the internet anyway: Opening a browser and typing in www.cisco.com displays Cisco’s website – success!!

How was my laptop able to resolve www.cisco.com if it couldn’t ping the address? Well, that was because the DNS traffic was ‘inspected’ by the ASA and was allowed in both directions. With the ping (ICMP) traffic, the request is allowed outbound to the internet, but the reply is denied by default, thus causing the ping timeout condition.

One way to fix is to add ICMP to the default ‘global inspection policy’. The protocols defined in this policy allows the ASA to ‘inspect’ all traffic leaving and will ‘keep track’ of it – so when the ICMP reply traffic comes back to the ASA, it will be (dynamically) allowed back in. The default policy does not inspect ICMP, so we will add it:

policy-map global_policy
 class inspection_default
  inspect icmp
  ...
  ...

Now, the ASA will know we initiated the ping from inside the network and will dynamically allow the reply back in from the internet:

#ping 8.8.8.8
!!!!! 5/5 successful
#

Was ICMP/ping required for internet access? No. Is it nice to have available in most environments? Absolutely.

We will pick up in the second article discussing firewalling and creating rules to control communications, which will include more information regarding the security level command mentioned previously.

Continue to Part II