This lab deals with a basic configuration of the Cisco ASA, which will include

configuring the hostname, domain name, interfaces, and security levels. The lab
setup in Packet Tracer is as shown below:

Two files are attached to this article:

intro_to_cisco_asa_init.pkt: This Packet Tracer file contains the lab setup with
the Inside User and Web Server configured with IP addresses and default
gateways. The Outside_RTR is configured with an IP address on its Gi0/0
interface.

intro_to_cisco_asa_final.pkt: This Packet Tracer file contains the lab setup with
the ASA fully configured to meet the lab requirements.

The tasks for this lab are as follows:

Configure the Hostname of the ASA as PKT-ASA and the domain name as
example.com.

Modify VLAN 1 settings to the following: IP address of 10.0.0.1, security level

of 100 and name inside.

Modify VLAN 2 settings to the following: IP address of 192.0.2.1, security level

of 0 and name outside.

Create a 3rd VLAN and name it dmz with a security level of 50 and assign an
IP address of 172.16.10.1 to the VLAN interface. This VLAN does not need to
initiate connections to the inside VLAN.

Assign Ethernet0/0 to the outside VLAN, Ethernet0/1 to the inside VLAN

and Ethernet0/2 to the dmz VLAN.

Verify your configuration and make sure you can ping all the connected
devices from the Cisco ASA.

Lab Solutions
Task 1: Hostname and Domain Name

We use the hostname command to configure the hostname on a Cisco ASA just like
we do on the Cisco IOS. However unlike on the Cisco IOS, we use the domainnamecommand to configure a domain name on the Cisco ASA.
Note: On the Cisco IOS, the equivalent command is ip domain-name. Actually,
many of the commands that have ip on the Cisco IOS do not have ip on the
Cisco ASA. Examples include show route as opposed to show ip
route and route as opposed to ip route.
1. hostname PKT-ASA
2. domain-name example.com
Task 2: VLAN 1 Settings
By default, VLAN 1 has already been created on the Cisco ASA 5505 and it has been
named inside with a security level of 100. Therefore, the only change we need to
make here is the IP address. However, if you try to change the IP address of that
VLAN interface, you will get an error message: Interface address is not on same
subnet as DHCP pool. ERROR: ip address command failed.
The problem is that there is a default DHCP configuration on the inside interface as
shown below:
1. dhcpd address 192.168.1.5-192.168.1.35 inside
2. dhcpd enable inside
One way to go about it will be to remove only the DHCP pool or to remove the entire
DHCP configuration since the task doesnt say anything about DHCP. After removing
the configuration, you can then change the IP address.
1. no dhcpd address 192.168.1.5-192.168.1.35 inside
2. no dhcpd enable inside
3. !
4. interface Vlan1
5. ip address 10.0.0.1 255.255.255.0
Task 3: VLAN 2 Settings
VLAN 2 also exists in the default configuration of the Cisco ASA 5505 and it has
been named outside with a security level of 0. However, IP address is enabled via
DHCP so we need to change that to a static configuration.
1. interface Vlan2
2. ip address 192.0.2.1 255.255.255.0
Task 4: Setup VLAN 3

This one is a bit tricky because of the license that comes with the ASA 5505 on
Packet Tracer, i.e. Base License. With the Base License on the ASA 5505, you can
only create two active VLANs and a third restricted VLAN. The third VLAN is
restricted because you can only configure it to initiate traffic to only one other
VLAN. You dont have this restriction with a Security Plus license.
Note: An active VLAN is one configured with the nameif command.
As such, if we try to configure VLAN 3 and add the nameif command, we will get
the following message: ERROR: This license does not allow configuring more than
2 interfaces with nameif and without a no forward command on this interface or
on 1 interface(s) with nameif already configured.
Therefore, like the error message states, we need to use the no forward command
on one of the active interfaces. In our case, the task specifies that the dmz interface
does not need to initiate connections to the inside, therefore our configuration will
be as follows:
1. interface Vlan3
2. no forward interface Vlan1
3. nameif dmz
4. security-level 50
5. ip address 172.16.10.1 255.255.255.0
6. !
Task 5: Interface Assignment
The ASA 5505 comes with switchport (L2) interfaces and the way to assign them to
security zones is to assign them to the corresponding VLAN for that security zone.
By default, Ethernet0/0 is already assigned to VLAN 2 (outside) and all other
interfaces belong to VLAN 1. Therefore, we just need to assign Ethernet0/2 to VLAN
3:
1. interface Ethernet0/2
2. switchport access vlan 3
Task 6: Verification
This last sub-task is about verifying our configuration so far. We can begin by
looking at the VLAN configuration and VLAN assignment for the interfaces using
the show switch vlan command:

We can also check the IP settings on the ASAs interfaces using the show interface
ip brief command (as opposed to show ip interface brief on the Cisco IOS):

Finally, we will ping the following devices connected to the Cisco ASA on its different
interfaces: 10.0.0.100 (Inside User), 172.16.10.100 (Web Server) and
192.168.10.100 (Outside_RTR):

Cool, our configuration works!

Summary
This brings us to the end of this Packet Tracer lab where we have configured basic
settings such as hostname, domain name and interface settings on the Cisco ASA
5505.
In the next article, we will continue with another lab on the Cisco ASA. I hope you
have found this lab insightful
Cisco Adaptive Security Appliance (ASA)
The Cisco ASA is a standalone (or module in 6500 switch) firewall that provides
packet filtering, stateful inspection, VPN functionality and many more in one box.
Ciscos firewall product was formerly the PIX (Private Internet eXchange) but things
have since changed so its now known as the Cisco ASA.
CCNA TRAINING RESOURCES (INTENSE)
As a mainline firewall device, Cisco had to implement a stronger operating system
than the basic Cisco IOS devices and so the Cisco ASA runs off a Linux kernel. It is
good to note this here because to make something secure, you must limit some
functionality. This is the case with the Cisco ASA, especially for those familiar with
the Cisco IOS devices. The Cisco ASA contains only the necessary features that a
firewall needs to do its job, and it is expected that for all your heavy and complex
routing decisions, you will rely on your normal Cisco routers and/or switches. But
dont despair theres enough on the ASA to keep you up at odd hours of the night.
Security Levels
To understand the ASA, you must understand the concept of security levels because
almost everything rises and falls on this concept. So what are security levels? If you

work in a financial institution for example, the level of security in the canteen will be
much lower than that in the vault where the money is. It means the vault is at a
higher security level than the canteen and this is based on the value of what is
being protected. This is how an ASA works: by dividing the network into security
levels, it is able to make decisions based on the level of trust. The higher the
security level, the higher the trust.
The ASA uses security levels between 0 and 100, with 100 being the most trusted
portion of the network (usually the inside, LAN) and 0 being the least trusted
(usually the Internet). Interfaces can be assigned any value in this range.
Default Traffic Flow
Now that we have seen what security levels are, lets look at another important
thing to know about the ASA. By default, traffic will flow from an interface on a
higher security level to an interface on a lower security level without restriction. The
reverse is not the case. So it means a user on the Internet (interface with security
level of 0) cannot connect to a user on the inside network (interface with security
level 100). Lets drive this home with a diagram.

Understanding this foundation of the ASA is very important for almost all other
features of the device. Now remember that this is the default flow of traffic and
more often than not, this default policy may need to be overridden. Consider the
scenario in the diagram below:

Imagine you have some servers in the DMZ as shown above and these servers
should be accessible from the Internet. With your configuration and the DMZ servers

on an interface with security level of 50, the external users traffic to the DMZ will
be denied by default because it is coming from a lower security level. This is an
example of a situation where the default policy has to be changed and we do this by
applying access-lists. We will see this configuration soon.
Firewall modes
The firewall can be configured in two different firewall
modes: Routed andTransparent. In Routed mode, the ASA is a router hop on the
network. In Transparent mode, the ASA acts in stealth mode, like a bump in the
wire, connecting the same network on its inside and outside interfaces. The Routed
mode supports more features than the transparent mode. Transparent mode also
makes you more prone to anger. Lol.
Security Contexts
An ASA can also function in two context modes: Single and Multiple. Multiple
context mode allows you to partition the ASA into multiple virtual devices known as
security contexts. Each context can be seen as a standalone device with its
interfaces, configuration, etc. Before version 9.0 of the ASA image, some features
like VPN and dynamic routing were not supported in multiple context mode. Some of
these features are now supported (some with limited capability).
If you are a network manager, a suitable punishment for any erring member of your
network team is to ask the person to configure an ASA in transparent, multiple
mode context.
Configuring the ASA
Now let the fun begin. In this article, we will focus on configuration through the CLI.
We will see how to configure the ASA using the ASDM (Adaptive Security Device
Manager) in the next article. The network diagram we will be using is shown below.

The routers have been configured with basic settings: IP addresses and default
routes pointing to the ASA IP address for the respective interface.
On the ASA, lets begin by configuring a hostname and domain-name for the ASA.
The command to set the hostname is the same command that you use on the Cisco
IOS devices: hostname<name>. The command to set the domain name is quite
similar to the IOS but without the ip so it is only: domain-name<domain>. As we
continue, you will notice a trend with the ASA CLI commands that they usually dont
include the ip part that the Cisco IOS has. For example instead of show ip route,
the ASA uses show route.

There is no default enable password so just hitting the Enter key again will place
you in enable mode. Now we can configure the interface settings. To enable an

interface for use, four things need to be done: Enter a name for the interface using
the nameifcommand, assign the interface a security level using the securitylevel command, assign an IP address to it using the ip address command, and
bring the interface up using the no shutdown command.

NOTE: Things are a bit different on the ASA 5505 which has 8 Fast Ethernet Layer 2
switchports. These ports can be used to connect directly to hosts. The name,
security-level and IP addressing are configured on the interface vlan<vlan>.
Notice from the above that by default, if you assign a name of inside to an
interface, that interface is automatically assigned a security level of 100. Any other
name on an interface assigns a security level of zero to it.
Basic configuration is done so lets test. Keep in mind those security levels because
we will begin to see their application.

As you can see, the Inside_Rtr can ping the inside interface of the ASA. Next, I try to
ping the DMZ_Rtr. Since the Inside_Rtr is on a higher security level interface, this
connection should go through, so whats wrong? Lets check on the ASA. One of the
easiest ways is to enable logging on the console at level 7 (on a non-production
network). I enable logging and initiate the ping again and this is what I see:

Heres a brief explanation of what is happening. We mentioned that the ASA is a

stateful firewall but state information is mostly useful for TCP and UDP traffic, not
ICMP. Therefore by default, the ASA does not inspect ICMP. It means if I open a
Telnet connection from Inside_Rtr to DMZ_Rtr, it should be allowed through since
Telnet is TCP.

So before you start panicking that your configuration is wrong or that the ASA has
turned to a cyborg that has a mind of its own, you need to know how the ASA
operates. For the purposes of this article, I want ICMP to be one of the protocols to
be inspected so I will add it. I know its beyond the scope of this article to show you

how but Im in a happy mood.

Theres a default class-map (called inspection_default) and policy-map (called
global_policy) in the configuration of the ASA. Under the policy-map, you will see
several inspect statements. Just add inspect icmp there and you are good to go, as
we will see.

If you are using GNS3 to practice, you may not see this default policy-map in the
configuration. There is a way to make it magically appear. You can change the
mode of the firewall to multiple context, save the configuration, stop the ASA, start
it again and change it back to single mode, save again and stop and start. If that
process is too long, just go to the Cisco site and the ASA configuration guide to copy
the default class-map and policy-map.
That was a necessary detour. Now that we are back on track and are inspecting
ICMP, lets ping from Inside_Rtr to DMZ_Rtr again:

Aha! Now we are good. Likewise, I can ping the outside router.

Lets move to the DMZ_Rtr. Will the DMZ_Rtr be able to ping the Inside_Rtr? And will
the DMZ_Rtr be able to ping the Outside_Rtr? Remember your security-levels and
then see the result below.

So the answer is No to the 1st question and then Yes to the second one. 50 cannot
ping 100 by default but 50 can ping 0. You will get a log such as the one shown
below when the ASA denies such traffic.

Finally, what do you think the Outside_Rtr can ping?

You are right. The Outside_Rtr wont be able to ping anyone because its on the
lowest security level among the three. There you have seen the default traffic flow
of the ASA. But I want to take you a step further.
We have said that, by default, traffic will only flow from a higher security level to a

lower security level. What if they are on the same level?

Lets briefly
change the security level of the DMZ interface to zero and then ping between the
DMZ_Rtr and the Outside_Rtr.

Now it fails. It means by default traffic between two interfaces on the same security
level is not permitted. We can change this default setting with the same-securitytraffic permit inter-interface command.

Thats my first hint for you. I will now return the DMZ interface to a security level of
50 as we had before. For my second hint, lets ping from the Inside_Rtr to
the outside interface of the ASA itself.

You will wonder why it isnt working since the Inside_Rtr is on a higher security
interface. This is the answer: The ASA will NOT allow a host to connect to its (the
ASAs) interface other than the interface on which that host is connected. You need
to keep this in mind and not be tempted to do this during a troubleshooting session
and conclude that you found the problem.
Cool! Its not even Christmas yet and you get all these hints and tips. Okay, moving
on. Lets configure one more thing before we call it a day on this article. Lets
assume theres an HTTP server on the DMZ that we want to be accessed from the
outside network. As we know, this traffic is not currently being permitted. So how do
we override it? By using access control lists. Yes, these ACLs are everywhere.
Luckily, the concept is the same.
Configuring an ACL on the ASA is similar to configuring it on an IOS device. You still
use the access-list command to configure the ACL and the accessgroup command to attach it to an interface. But we will see the difference soon.

On the IOS device, you attach the ACL under the interface configuration mode but
not so with the ASA. You can read the access-group outside_in in interface outside
as: Apply the ACL called outside_in to the outside interface in the inbound direction.
So lets test. We can simulate an HTTP connection to the DMZ_Rtr by opening a
Telnet connection to port 80 from the Outside_Rtr.

If we check the ASA, we will see the traffic hit on the ACL.

Oh and I hope you noticed the cool thing about the ASA: You can issue a show
command from anywhere!
A note of warning though: Ensure you understand where you apply your ACLs. Lets
assume my ACL had a permit tcp any anyeq 80 statement and I attached it to
the outside interface, I have effectively allowed any source IP address from the
outside to access not just the DMZ server but also any inside device that will
respond on the port 80.
One last thing: lets ping from the DMZ_Rtr to Outside_Rtr.

As you can see, the ping succeeds. The default deny any any at the end of the
outside_in ACL did not affect this traffic. Why is that? This is because of the stateful
nature of the ASA (and the fact that we are inspecting ICMP). Now if you are running
a dynamic routing protocol with a device on the other side of your firewall, you want
to explicitly permit the routing protocol traffic in the ACL attached on the interface
because that traffic is not inspected. These are just a few things for you to consider.
Lets stop here for now.
Summary
In this post we have been introduced to the Cisco ASA. The ASA operates on the
concept of security levels and by default, traffic flows from a higher security level to
a lower security level and not vice versa. To change this default behaviour, access
control lists (ACLs) can be used. In the next post, we will see how to manage the
ASA remotely (and theres a shocker for you if you are not previously familiar with

the ASA). We will also see how to use the ASDM for basic configuration. Till then,
success in your studies.