Try our training for free.

Gain instant access to our entire IT training library for 1 week. Train anytime on your desktop, tablet, or mobile devices.

This Cisco video training with Keith Barker covers network security, including topics such as securing routers, firewalls, cryptography, and more....
This Cisco video training with Keith Barker covers network security, including topics such as securing routers, firewalls, cryptography, and more.

Related area of expertise:
  • Cisco security

This CCNA security training course, produced by Cisco expert Keith Barker, helps prepare you for the new 640-554 Cisco exam, and also prepares you to address many of the real world vulnerabilities you come across today.
Keith dives into the Cisco Configuration Professional (CCP), the latest GUI (Graphical User Interface) software which will help you manage your Cisco routers. Not only does this training focus on switch security and router security, it also explains and demonstrates how to configure the ASA (Adaptive Security Appliance) firewall. Keith, author of the CCNA Security Cert guide, covers the material in a way that is thorough, fun and engaging.

Whether you're fairly new to the network security world, or you've been in it for a while and simply want to fill in the gaps and see how all the pieces can be integrated together to build a fortress of security using a defense in depth approach, this course is for you.
1. Introduction to CCNA Security (7 min)
2. Network Foundation Protection (38 min)
3. Fortifying the Local Router (42 min)
4. AAA, RADIUS and TACACS+ (47 min)
5. Securing the Switched Data-plane (50 min)
6. Tools to Protect the Management-plane (43 min)
7. Controlling the IPv4 Data-plane with ACLs (34 min)
8. Protecting IPv6 Networks (53 min)
9. IOS Firewall Fundamentals (31 min)
10. Zone Based Firewall Implementation (25 min)
11. ASA Firewall (47 min)
12. Intrusion Prevention Systems (IPS) (45 min)
13. IOS-based IPS (48 min)
14. Cryptography Essentials (42 min)
15. IPsec Site to Site VPNs (53 min)
16. SSL VPNs (51 min)
17. Defense in Depth (24 min)

Introduction to CCNA Security

Network Foundation Protection

Fortifying the Local Router


Securing the Switched Data-plane

Tools to Protect the Management-plane

Controlling the IPv4 Data-plane with ACLs

Protecting IPv6 Networks

IOS Firewall Fundamentals

Zone Based Firewall Implementation

ASA Firewall


ASA firewall, the Adaptive Security Appliance from Cisco Systems. In this video, you and I are going to take a look at the thought process of how an ASA acts by default, what the default behaviors are, what flows are allowed. And once we understand the logic of how it thinks, you and I are going to take an ASA with a brand new wiped config and configure it from zero to functioning firewall, including network address translation and policy modification in this Nugget.


We'll get live on the internet. Let's jump in. We should probably begin our journey in the world of the adaptive security appliance by pointing out that that's what ASA stands for. The ASA is the Adaptive Security Appliance, a purpose-built firewall from Cisco.


And it does lots of really amazing things, which we'll talk about. But the most primary functional thing it does is something called stateful filtering. And you're like Keith, you mean stateful filtering, just like a zone-based firewall? That's what I'm talking about.


It does stateful filtering. So as an example, and a quick review, if Bob was right here and Bob wanted to go out to the internet, Bob would send traffic out to the internet. The firewall would do stateful remembering, stateful filtering, put that information in a session table.


Why? So that when the server replied, the ASA could say, oh, this matches correctly. What Bob sent out is the correct return traffic. I will go ahead and dynamically allow that to come back to Bob. That's it in a nutshell, the primary function of the ASA is stateful inspection.


So how does it do it? How does it decide whether or not traffic should be allowed in the first place? So for this ASA right here, let's give it a name. Let's call it ASA-1, make it personal. And ASA-1, when he gets Bob's packet that needs to be forwarded out to, let's consider what's required to make that happen.


The first thing that's overlooked a lot is something called routing. If this ASA gets a packet and the packet is destined to, and the ASA looks at its routing table and say, I have no clue how to forward towards I've got no default route.


I don't have that static route. I haven't learned it dynamically. The packet is going to be dropped. So routing is critical to be in place. So let's assume that routing is in place, that we got an IP address from our DHCP server on the internet from the service provider.


We have a default route to that service provider. How do we decide whether or not Bob's packet is allowed? And the secret to understanding this, I kid you not, is water. I want you to write out with me water. And we're going to a little graphical representation here.


I want you to imagine that there's a river. And this river is going in this direction. So we have a river, it's going in this direction, and it happens to be at 100 feet elevation. So imagine visually, there's water at 100 feet going in this river, slightly downhill, and then there's a cliff.


And I will label that so there's no mistaking that there's a cliff right here. And the cliff actually goes down until it hits some more ground at zero feet. And then the river continues. Now, my question is, what happens to water as it's going down the river and hits this cliff? Does it go down or doesn't it? I want you to think about that with me.


Does the water go down the cliff from 100 feet down to 0 feet, yes or no? And the answer is, without some extraterrestrial, non-gravity, external force scenario, water's going to go from higher to lower. And that, my friends, is how the ASA decides whether or not it is going to forward traffic, assuming there's routing in place.


Every interface-- and let's take a look at them right now. Every interface has associated with it a security level. The inside interface here, I've named it INSIDE. By the way, on the ASA, we use these really clever names to configure the interfaces. So when we're configuring details for this interface right here, I would refer to its name, which I gave it of INSIDE.


I also gave this interface the name of DMZ, and I gave this interface the name of OUTSIDE. But besides a name, which every good interface is going to have on an ASA that's doing routing, we're also going to have this security level. So security level of 100 is on the inside. A security level of 50 is on the DMZ. And a security level of 0. So let's get back to Bob's packet.


Bob's sending a packet. It goes to the ASA because that's his default gateway very likely in this topology. And the ASA says, oh, I've got to default route. I know how to get to, not a problem. It needs to go out the outside interface to the service provider.


And that's the magic where it gets to compare, am I going to forward this initial traffic? If the traffic is going from 100 and it's going out an interface based on the routing table that has a security level of 0, the answer is yes. I am willing. I am willing to forward the packet, and it will forward the packet.


That's the secret of, does the initial packet, does initial flow go through the ASA if it's coming in on an interface that's higher security level-wise than the exit interface based on the routing table of the ASA, that traffic will be allowed. Higher to lower goes.


So that's the secret of deciding whether the packet's going to flow. Let me do a couple scenarios with you. Let's say I have a user on the inside, and that user wants to ping 172-- left not use ping. Let's use web services. Let's say the user, Bob, wants to open up in a web browser to a DMZ server that's at 0.10. So he puts in his browser The packet goes to the ASA.


The ASA does a route lookup that's directly connected to these two networks. And the ASA says, should I forward this initial frame, yes or no? The source is 100, the destination, based on the routing table of the ASA, is 50. So it's going from 100 to 50. Does the initial packet and subsequent flow of traffic, does it go? And the answer is just like water, higher to lower goes by default.


Isn't that fantastic? Let's do one more. This is a great game. And it's an important game too, because these are the fundamentals that when you get into CCNP security and CCIE security, understanding that basic thought process of the ASA is going to be critical for the real world and for your certification.


So let's do a couple more scenarios. So we have a user here. So we have a user sitting at a web server, for whatever reason, and he wants to open up a web browser out to So he opens up a browser, he forwards the packet, it hits the ASA. The ASA does a route lookup and says, oh, to get to, I don't have a more specific route. I'm going to use my default route, which is the service provider.


It now knows the ingress interface, the DMZ. It knows the egress interface of the OUTSIDE. It compares the security levels and says, this is from 50 going to 0. Does it go, yes or no? And the answer is absolutely yes, higher to lower. It's just like water.


So what have we identified so far? You're doing great, by the way. Fantastic progress. We've identified that these flows will go by default. I'll put them in green. That would work because it's going from 100 to 50. This would work because it's going from 50 to 0. And this would work because it's going from 100 to 0. Are you with me? Those are all the initial flows of traffic that the ASA by default, without any additional changes to the security policy, would allow to happen.


Now, what about the reply traffic? Oh my gosh, with if these users all initiate these connections. How in the world is reply traffic going to get back? And the answer is stateful inspection. Stateful inspection is on by default for TCP and UDP. So a lot of the most common applications that ride on top of those layer 4 protocols, the sessions will be analyzed, inspected, statefully remembered, and return traffic is going to be allowed back in.


Fantastic story, it's just like in zone-based firewalls. By default, the ASA is doing a fantastic job of saying no. 0 to 50 is a no. 0 to 100 is a no. And you know what else is a no? 50 to 100 is a no. So all those reds right there are all no's by default.


So we have a very, very secure security posture right out of the gate with the adaptive security appliance because if these are the security levels we're using, the outside world can't get to us but we can get to the outside world. So the immediate next question normally comes up saying, well, Keith, you've got a couple of web servers here on the DMZ, or email servers, or other public servers.


Don't you want, like Jim on the internet to be able to access your servers? And the answer is yes. So what we could do on an outside interface, as an example, is we could use an ACL. And ACLs will override the default security levels. Meaning if we say on the ACL, permit HTTP traffic TCP port 80 to these two web servers, then Jim on the internet, as he comes into this interface, if the ACL says permit it, even though it's trying to go from a 0 to a 50, the ACL because it says permit, the traffic would be allowed.


So ACLs can be exceptions to the rule. That could also be a bad thing for Bob over here. If we have rules in place where we don't want Bob to be able to go out using certain protocols, we could go ahead and put an access control list inbound on the INSIDE interface and simply tell the ASA, you know what? We're not allowing any kind of telnet.


So even though it would be traffic from higher going to some lower interface, because of the ACL that says no telnet or no other protocol that you want to deny, the ACL would triumph and win over the default security behavior. So what else can this little box do for us? I say little box.


This is a 5505. It has some bigger brothers that are based on the ability to have more capacity. So not every size fits all. If we're in a larger environment, we'd probably buy a bigger model, bigger flavor of the ASA. But the basic functionality is the same in all of them.


So on the 5505, we've got the front here. And this was built for a small office/home office. And it's got a built-in switch. Somebody said, I don't want to have to buy a physical switch and a router and a firewall. Can I just get all that functionality built into one? And Cisco said, absolutely, yes.


So here's the features that are supported. We have stateful inspection for Bob's traffic as it goes out to the internet, so the return traffic can come back in. We have access lists that we can use on the interfaces for overriding that policy if we need to let-- for example, Jim go to a server.


We have application inspection. So if Bob agrees, if Bob says, yes, I won't use any peer-to-peer networking software ever, I promise. The ASA can analyze all the traffic going through it. If it sees peer-to-peer, it can drop it based on policy. See, people can hide peer-to-peer in different protocols.


They can hide it under, maybe port 80 or other ports that maybe are trying to hide their HTTP, but they're really not. With protocol and application inspection, the ASA can figure that out. It can say, oh my goodness, this is not valid HTTP traffic. I'm going to go ahead and drop it.


It also supports a little solution for this problem. This is a private IP address space. This is a private IP address space. The internet doesn't route private IP addresses. So we can't use these addresses on the internet, so it also supports NAT and PAT and all of its flavors.


So if we had one IP address here from a DHCP server, we could do port address translation and translate, maybe not the DMZ devices but our internal users to that one address. And then we could NAT the servers to other globally-reachable addresses so that they could be accessed.


Or, we could actually do port address translation just for port 80, and have port 80 redirected to one or both of these servers. There's also VPN support. So Jill, out on the internet, wants to get to the home office and she can build a virtual private network from her computer on the internet all the way to the ASA.


Could it use SSL? Could it use IPsec? And the answer is yes, it supports both of those. Even the little 5505, you get two licenses for VPNs. And you can purchase additional licensing for additional users if you need to. What else does it do? It supports object groups.


Very similar to what we have on the router as far as object groups. So if you wanted to have an access list that identified an object group and the object group could then reference 10 or 20 different servers as far as IP addresses go, very capable of doing that right here on the ASA.


It also has the ability to do something called botnet filtering. Now, what is a botnet? I am a robot. I am at your command. What if we had 10,000 machines that we had comp-- not we, but somebody had compromised, and any time that attacker wanted to use those 10,000 machines to launch an attack, it could. That would be an example of a botnet.


There's botnet support. And it can even leverage external services. So you can actually subscribe and actually get information on botnets that are out there, and that way the ASA can self-defend your network and say, oh my goodness, there's a botnet. It's well defined.


It's attacking across the internet. And we can learn that information from an external trusted source, like Cisco, and then the botnet filtering could protect against that specific type of traffic and those addresses that are involved in the botnet. A few other features that are also supported for example, if we wanted to administer this box and not have to keep all our user names and passwords on the ASA itself, we can use AAA.


Very similar to how we did it with our routers, by setting up authentication, proving who people are, authorization-- what are they allowed to do-- and accounting records being sent back to a AAA server. And finally, we also have high availability. High availability means buying two.


That's what that means. Why buy one when you can buy two at twice the price? For companies that can't afford to be down, by having two adaptive security appliances side by side forwarding traffic. If one goes belly up, the other keeps going. That's an important feature for most commerce and real-time network applications because they can't tolerate failure.


It's too expensive or too painful to have the network go Down, so they buy two. They put them in a fault-tolerant or high availability failover situation so that they can support each other in the event of a failure. So let's say we have the ASA up and running, which we will here in a moment.


Together, you and I will configure it from scratch. We'll do the whole thing together. And it's up for a couple weeks and the boss comes to us and says, hey guys, what we want to do is, can we do deep packet inspection on HTTP to really analyze whether or not valid HTTP commands are being forwarded or not? And we look at each other and say, yes, we can do it.


As soon as the boss leaves, we talk to each other and we say, how would we do that? Now, the answer to that question, which we're going to discover right now, is knowing how the ASA implements its policies regarding inspection or policing of traffic or any type of data manipulation.


It does this, I think you'll enjoy it. It uses something called a class map. Now, what does a class map do for a living? Well, Keith, it does the same thing it did for quality of service, which is to identify traffic. It does the same thing it did in the zone-based firewall in IOS, and that is to identify traffic.


Guess what it's going to do here on the ASA? We use it to identify traffic based on IP addresses or layer 4 protocols or application layer services. So class maps identify the traffic that we want to manipulate. Then, as we want to manipulate that traffic, maybe we want to turn on inspection for our specific application.


Or maybe we want to drop traffic. Or maybe we want to prioritize traffic. How do we specify the action? And the action is identified by using something called a policy map. And here's how they flow together. And it's not a coincidence, this is exactly how it functions with modular quality of service command line interface for QoS on routers.


This is how it works with zone-based firewalls. The class map identifies the traffic. The policy map says, hey, if this class map's traffic is matched, I want to take an action. And that action could be policing the traffic, prioritizing the traffic, inspecting the traffic.


And how do we apply the policy? The way we apply a policy is something called a service policy. And we can apply the service policy globally, which means traffic on all interfaces, or we can apply a policy to a specific interface in a specific direction, if we only want to have the policy based on traffic on that single interface.


So class maps identify traffic. Policy maps specify the action to take, and service policy is how we apply it. We'll take a look at modifying the default policy here as we bring up the system. Having said that, let's bring up this device from scratch. I just wiped this guy out.


This is in my home office. It's a 5505. I just erased the configuration, the whole thing, and I've got console access. So I've got a PC that has a console connection right there. And what we're going to do is this. Here's our game plan. These are ports. They call them ethernet.


They're really fast ethernet, but they're labeled E0/-- this is 0/0, 0/1, 2, 3, 4, 5, 6, and 7. These two here have power over ethernet. So if you had a webcam or access point, or something else that needs power over ethernet, you got those two ports. It's great.


My PC has an ethernet cable connected right here. So our mission, should we choose to accept it, is to take this completely default configuration ASA and get it up and working. So the first things-- and this is true with a lot of devices. The very first thing we need to do is make sure we give it enough information, so that we can manage it with our management tools, such as SSH.


Or, we could ASDM. What is ASDM? Glad you asked. ASDM, the ASA Security Device Manager. So ASDM. It's the GUI. What the Cisco configuration professional is to a router, the ASDM is to the firewall. And it's a great tool. There's a lot of really cool things that we could do with it.


However, I also encourage you, if you're going to practice with this, is to also use the option to see the commands at the CLI before it pushes them out. That way you can see the commands that from the CLI perspective as well as knowing how to navigate the graphical user interface.


So to get ASDM from my PC working, and I'm connected to this port right here, we need to first of all enable this port. Now, these are all switch ports. And by default, all those ports are members of VLAN 1 from a Layer 2 perspective. So we're going to need to take this port, and that's port 0/5. We're going to need to do a no shut on it.


We would want to assign it to VLAN 1, which is a default. You don't have to do that, but I wanted to show it to you. And I will because I want you to be aware of what's happening. And then once we no shut that interface and make sure it's an access port in VLAN 1, we're then going to go to interface VLAN 1. Now, interface VLAN 1, this is just like an SVI on a switch. On a switch, a Layer 2 switch that's manageable, if you want to manage it, it has to have an IP address.


So where do you get an IP address? You pop in a switched virtual interface, interface VLAN 1. Enter. You're now in interface configuration mode. And then you can give it an IP address. On the ASA, we're going to do three basic things. Besides just giving it an IP address, which is one of the things.


So we'll give an IP address. We're also going to give it a name and we're going to call ours INSIDE, because on the ASA, all the interfaces like to have names. And we refer to those names for the interface. And then the last thing we're going to do is set up a security level.


Now, these elements are just to bootstrap the device so that we can connect to it with either SSH or a graphical tool, like ASDM so we can manage it. If we do want to manage it, we also need to enable HTTP so the box will respond when we make our HTTP request.


And on an ASA, even though it says HTTP when we configure it, it's really referring to HTTPS. It's not going to allow HTTP connections to the box, even though the command to enable HTTP is HTTP. So we'll enable it, and we're also going to set up an ACL that tells me the ASA, hey, listen.


It's OK if anybody on the 10 network, at least initially, go ahead and connects to you. And then we can lock it down after that point. So that's the bootstrap process of the ASA. Let's just make sure we have our quick checklist, and then we'll do it together.


Number one, we're going to take that port out of shutdown state. We're going to make sure it's in VLAN 1. We're going to go to the logical interface for VLAN 1. We're going to give it a name. We're going to give it an IP. We're going to give it a security level.


And we're going to enable HTTP globally on the box so it will respond to our HTTPS request. And we're going to set the ACL that allows people to connect. So that's the bootstrapping we're going to do. Let's bring in the interface and we'll do it all from scratch.


So let's bring in the ASA. It's been recently rebooted, less than three minutes old. It just finished on powering up. It asked me if I wanted to run the setup script. I said no. I pressed Enter a few times to clear the screen. Let's go ahead and do our basic bootstrap right here.


The very first thing we're going to do is going to go into privilege mode, just like on an IOS router by typing in Enable. The tricky part is there's no password by default. But you do have to press Enter. So when it asks you your password, press Enter, and you're good to go.


Next, we're going to go into configuration mode, very much on like an IOS router. And from configuration mode, we can then configure the device. Let's go into interface e0/5. Tell it that we want it to be assigned to VLAN 1, just like a normal switch port layer 2. And we'll also do a no shut.


Now, that's a little bit different. On traditional 3560s and so forth, and switches, they are up by default-- the interfaces. On the ASA, the switch ports are shut down by default. So it's up. It's assigned to VLAN 1. And now, let's carve out the logical VLAN 1 interface. This is the interface that's going to get the name command, the security level, and also the IP address.


So we're going to call it INSIDE. I'm going to use uppercase. It doesn't have to be. But you want to make sure you follow the same case sensitivity throughout the config because the interface name is going to be used to refer to that interface. So security level's 100, name if INSIDE and the IP address. So again, we're just bootstrapping this router with enough information so we can communicate with it.


We also need to enable HTTPS, so we'll use the HTTP server enable command. And we're going to specify where HTTPS sessions are allowed to come in from. And that's going to be, I'm going to say, anywhere on the 10 network. Wild card masks are a thing of the past with ASA.


There's no such thing as a wild card mask. So access lists or network statements or anything else, if you ever need to identify an IP subnet, you're going to using a normal mask. No wild card masks anywhere. So the HTTP is allowed from the 10.0.0 network if it's coming in from the INSIDE, and then we have a show command for IP-- show interface IP brief.


And I wanted to point out here that we can use our show commands right from configuration mode. You don't have to put a do in there. You can just stay in configuration and do your show commands as much as you'd like. Also, they couldn't use this-- they could of, but they didn't.


They didn't use the same exact command set. So on a Cisco router to show IP interface brief, on an ASA you can do show interface IP brief. We can also do a show IP and it's going to show us some details regarding the address. So here it's showing us the VLAN 1 interface. The name is INSIDE.


It's IP address is this. The mask is that. And we can also see that we have these other interfaces that are all switch ports. This is the one port that's up, and it's currently assigned to VLAN 1, which they're all assigned to VLAN 1 by default. So now it's strapped.


What do we do next? Well, the next thing is to get ourselves an IP address on that 10 network. So I'm going to move this out of way. And let's say that this PC here is one of those PCs is ours. And let's give ourselves the address of I'm going to have to manually configure that because right now I'm on a different network.


So I'm going to physically take my PC. I'm going to plug it into this port right here, so it'll look like that. I'll be at, and then we can open up ASDM to go ahead and manage this through a graphical user interface. So let's take a look at my IP address, make sure I got that right.


You can be the eyes over my shoulder here as we do it together. If we go to Properties of that interface and TCP/IP, there's My default gate was And I'm using DNS of So right now, the ASA doesn't have access out to the internet yet because we don't have the OUTSIDE interface configured.


And certainly, the DMZ isn't up yet either. So from our PC perspective though, I'll click OK. Click OK. Close that. And let's just verify that we can ping the device before we try to open an HTTPS session. So bring up command and ping it from here. And OK, that looks promising.


That means at leas we have on the same broadcast domain and our IP addresses are responding to each other. So let's open up the ASDM. Now, how would we do this in a brand new environment? We would launch a browser, HTTPS to the IP address of the ASA at and it would prompt us to download the adaptive security device manager ASDM.


We could actually run it right there through Java, or we could download the app, install it locally, and run it from our computer. Either way, we're conversing and communicating with the actual ASA. I've already installed the software ASDM, so I don't need to go through the install process again.


It's asking me, who do I want to connect to? Now, this is challenging. We just configured this ASA together. We didn't configure any user name. We didn't configure any passwords. So how do we log in with ASDM? The answer is you simply click on OK. That's definitely something we'd want to fix by setting up authentication for people trying to access via HTTPS.


But for now, we can say, yeah, sure. I'll accept the certificate. It's not signed by a CA server that my browser trusts, and that would be expected because it's a self-signed certificate that the ASA just generated for the SSL session. So we'll click on Yes.


It's going to open up ASDM. I'll size it, and then we can take a look at it together. There's the dashboard of everything that's going on here. We have the host name, which is Cisco ASA by default. The version of software it's running. So how do we configure this? Really simple.


There's a Configuration tab. And if we want to start with interfaces that would be a good thing to do. And it's saying, OK, you've got one interface named INSIDE and all the switchports are currently assigned to that same VLAN. So let's create a second interface.


If we take a look at our topology here, we've got the OUTSIDE interface that we need. And it's going to be security level 0 and it's going to DHCP assigned IP address. Now, what VLAN should we use for this? Now by default, all these ports are currently in VLAN 1. So it doesn't really matter what VLAN we use, as long as we use a different VLAN for the connection going to the outside.


So what we could do is we could take this port here, which is physically connected to the outside world going to a cable modem in my home office here, and we can make that port a member of VLAN 2. We create a VLAN 2 interface. We name it OUTSIDE. We give it a security level of 0, and we tell it we want it to have a DHCP-assigned IP address.


So let's do that right now. We'll bring our GUI interface back in, ASDM. There it is in all it's wonder. We'll click on Add. And let me get this so it's readable by everybody. And let's go ahead and click on that we want the interface named OUTSIDE. We want the security level to be 0. Now, the 0 is just subjective. If we had two interfaces, the INSIDE had 100 and the OUTSIDE at 99, with just two interfaces, the security policy would be the same.


Traffic would flow from higher to lower. Return traffic would make it-- if it was inspected on the way out, the reply traffic would be allowed. Initial traffic coming from the outside, if it started at 99, wouldn't make it to interface of 100. We often use 0 for the OUTSIDE and 100 for the INSDIE, but they're just numbers for a comparison purpose for the initial policy.


So we say it's 0. It's outside. The IP address is going to be via DHCP. And we want to add this interface 0/0, which currently is associated with VLAN 1 on the INSIDE. And if we go to Advanced, we can actually choose our VLAN number. So we're going to use VLAN 2, just because we can. And in the background, it's assigning that port as an access port for VLAN 2. It will also create a new logical VLAN 2 interface and name it OUTSIDE and try to get an IP address via DHCP.


So if that looks OK, which it does. I'll click on Okey-doke and apply it. So there's the actual syntax that it's going to push out. It's going to Interface Configuration Mode and it's saying, OK, switch port access VLAN 2. You're in access port VLAN 2. For the logical interface VLAN 2, it's going to bring it out of shut down.


It's going to go ahead and give it a security level of 0, name it OUTSIDE, and do an IP address via DHCP. And we'll set our default route based on what we learned from DHCP. Check this out, though. You know what's missing here? I'm looking at this syntax. That interface is currently shut down.


Ethernet 0/0 is currently shut down. And as a result, just assigning it to access VLAN 2 is not going to cut it. But we can fix that. Let's apply this. We'll send it out. And it's pushing the configuration, that's fantastic. And it says it's enabled. Let's go to switchports 0/0. It says No here.


So the logical interface is enabled, the OUTSIDE interface, the interface VLAN 2. However, the physical switchport is not enabled. It says so right there. So let's edit that, and let's go ahead and say Enable SwitchPort and apply it. And we're good to go. So no shut down.


That's going to be really important for that to work. OK, so now having done that, what should happen is, if my connection is in place, which I believe it is, going out to the internet on this port right here, the pieces in place are that port is an access port on VLAN 2. We have a logical VLAN 2 interface that wants to be a DHCP client, and that goes out to the internet via cable modem who should be supplying an IP address via DHCP.


That's the theory, anyway. Let's see if that all works out. So we'll bring back this guy right here. And let's refresh this with the big Refresh button. Oh, look at that. Perfect. So under Configuration Interfaces, this is showing me the DHCP-assigned IP address-- temporarily, I might add.


So please don't attack this IP address in the near future because it won't be mine after this demonstration is done. So that's the IP address on the OUTSIDE interface. Now, can my customers get out to the internet? Let's take a look at this together. This is real world here.


I've got my PC literally right here. I'm on the 10 network. My IP address is 0.2. My default gateway is 0.1. It's the ASA. And the IP address has been assigned on the OUTSIDE interface. Can I get out to the internet, yes or no? We could try it. But the answer is it's not going to be too happy yet.


Because there's no network address translation involved. NAT has to be put in place because my ASA has a valid IP address on the internet, but my PC doesn't. So I need to do network address translation to-- and we could do PAT on this interface so that my client could go out to the internet.


So how do you configure the basics? And again, in CCNA my friend, we're talking about just some basic foundation components here. Basic IP addressing, getting the ASA bootstrapped and getting a NAT configured so that we can have a client go out to the internet.


So to configure the ASA for network address translation, where would we do that? Well, under Interfaces there's no options here. But if we go down to-- under configuration, if we go down to Firewall, most of the policies that we can implement on the ASA are done right here.


So Access Rules. I'm going to go ahead and say take off the IPv6 just to clean it up a little bit. The access rules apply to access control lists. The NAT rules applies to NAT, and that's what we need to do. So let's go ahead and set up a NAT rule that says taking all the clients on the INSIDE and allowing to be translated to the global address that the ASA has on the outside.


So to do that, it's really simple to set up a NAT role. You simply click on Add. You specify the details for you NAT. You say, well if any traffic is coming in on the INSIDE interface, regardless of its source address, we could also limit it to one subnet that we want to do translation for.


And the destination interface is the OUTSIDE. Regardless of destination IP address we're going to, we want to go ahead and do dynamic translation. We're going to do PAT where we're going to overload on the interface. And we're going to specify the new source address should be whatever the IP address is on the OUTSIDE interface.


That's it. That's NAT in a nutshell. So we'll click on OK. And then we'll click on-- actually, let's look at it first, then we'll click on Apply. So this is saying traffic from the inside going to the outside from any IP address going to any IP address, regardless of service, we want the translated packet to have the OUTSIDE IP address.


And the destination we're not changing that. If you're going to Google, you're still going to Google. And we're set, so apply it. And it's showing us the syntax that we could use at the command line to implement this network address translation. We'll send that off on its way, and now our NAT is in place.


So the question now is, should we be able to go out to the internet as a client? Let's go back and take a peek. So here's our PC. We haven't changed. We're at Our default gateway is We have DNS of and we have NAT going on. So any traffic source from the inside going to be outside should be NATed and it should be allowed because we're going from higher to lower security levels.


And because of the stateful inspection that happens by default, return traffic should be allowed back in. So I'm thinking we have a strong possibility of it working. So let's go ahead and test it. Let's bring up a command prompt. And here's a command prompt.


And let's do an nslookup for Well, that's a very good sign. That means that UDP is working because we just got a response regarding the IP addresses we can use to reach And we could probably ping I guess as well to That's an IP address of a DNS server provided.


Oh, and ping is not working. I wonder why that is. UDP works, but ICMP doesn't work. What could that be? Well, let's go ahead and look at the policy to understand why that's not working and how to change the policy if we wanted to. So to take a look at why that might not be working, let's take a look at our access rules.


And by default, we have the implicit rules where traffic from higher security interfaces is allowed to be initiated to lower security interfaces. And we know that UDP works, so that isn't the issue here. And there's no manual access list configured by default.


So let's go ahead and take a look at service policy rules. Service policy is all about the class maps and policy maps being applied by a service policy to the traffic. And here's our default global policy that's in place. And it's saying that it wants to go ahead and do inspection of these protocols.


Take a look. We have DNS. And also what it doesn't mention here is we also have TCP and UDP generic inspection happening. But if you'll notice if we take a look at this list, it does not include any ICMP inspection. So ICMP, because it's not being inspected, that's the reason it's not being allowed.


We could also use another tool to verify it. This is really an awesome tool as well. It's called Packet Tracer. And we could actually do the Packet Tracer from right here. They have an icon for it. You can launch it from the menu. You can launch it from an icon.


And we could say, well, let's see why a ping doesn't work. So with Packet Tracer, if we wanted to simulate what the firewall would do with a specific packet, we could say, we want to take traffic from the inside. If it's coming from IP address going to and it's an echo request.


And we could go ahead and Start and it would run that cycle and say, you know what? This packet would make it or it wouldn't make it. Now, for marketing purposes perhaps, they actually show it to you in slow motion with every step along the way the process it's going through.


But we could also de-select Show Animation and it would just show us the final result without the fanfare. So this implies that from route lookups, checking access lists, checking NAT all the way through, that this packet is allowed. So the ASA is saying, I've got no problem forwarding this ping request from the client out to Well, why didn't it work? The reason it didn't work is because by default, the ASA doesn't inspect ICMP.


It inspects TCP generic, UDP generic. It inspects these applications that I have right here, but it doesn't inspect ICMP. If we wanted to change that behavior, or any of the other inspections that are on or off, or we want to manipulate it, here's how we do.


We'd go to Service Policy Rules. On the Default Policy, click on Edit. And here we have the rule actions. And this is specifying the applications that we're going to inspect. And check it out, ICMP is not inspected by default. That's why the ping didn't work.


So if we did this side by side, we bring over the PC that didn't work. So we'll try our ping again. It's not flying. We go back here to the policy. We say, yep, I want to inspect ICMP as well. Click OK. Apply it. It's going to modify the policy map to say for class inspection default, we want to go ahead and inspect the ICMP.


So that when the return traffic comes back, the echo replies. Because there's going to be a session entry for that session, the reply will be allowed. So we'll send that over. We'll go back to the command prompt. We'll try our ping again. And now the ping's working.


Why is it working? It's because we're doing inspection. And one step further if we wanted to, if we wanted to go take a look at deeper packet inspection, for many of these applications we can actually configure specific application policy maps to get very deep into application layer protocols looking for specific protocol compliance or other details up in the application layer.


That's why each of these have the additional Configure option next to them. So one more thing I wanted to discuss with you before we close on the ASA is the concept of access control list and how they override policy. Currently as we have it configured, our customer is allowed to go out to the internet with TCP and UDP and a whole bunch of other applications.


And it can do ICMP. Why is that? Because the inspection rule said inspect ICMP so that reply traffic could come back. And that's still working. We could verify that real quick that's nothing's changed by doing the ping we did just a few moments ago to And it indeed, is working.


Fantastic. If we wanted to override the policy of traffic being able to go out, we could implement an access list. And access lists are important to see at least once. So let's take a look at the ASA and how an access list could be applied. From a planning perspective, let's apply the access list to block ICMP traffic if it's destined to and if it's sourced from the 10.0.0 subnet. Now, here's a big difference.


On the IOS routers, we use wild card masks to indicate we don't care about the last octet. We could use On the ASA, there's never, ever, ever, never, never, ever the use of a wild card mask. It's always just normal masks. So we can have standard ACLs, which filter only on the source IP address, both in the router and on the ASA.


We can have extended access lists, which can filter on virtually anything at layer 3 or 4, source or destination. But the difference is when we apply an access list or create one, we don't use the wild card masks. So let's go ahead and create one. Let me clear off the screen.


Let's bring in Cisco Configuration Professional. Here it is. And to get to the access lists, we go to Configuration, click on Firewall, and then go to Access Rules. That's just the fancy way of saying here's where the ACLs are if you want to configure them.


So to create one, we'll simply click on Add. And we're going to have this apply it on the INSIDE. You can apply it the INSIDE or the OUTSIDE. Apply it on the INSIDE. We're going to say Deny, and we want to deny traffic if it's from anywhere on the INSIDE.


So I'm going to go ahead and pick this. There's an object group already created for the INSIDE network. So I'm going to create that one by double clicking. It puts it down here. I'm going to click OK. So that's the 10.0.0/24. And I'm going to say if the destination is a specific host.


So I'm actually going to type in right here That's the host we want to try to reach. And the service is ICMP. We just want to block ICMP. So we can pick that. Green is TCP and the blue is UDP. And then we have ICMP. I'm going to say echo. Great, no echo requests being sent out.


So the echo request will never make it. And I can do a description if we wanted to. So I'm going to go ahead and click on OK. And now I've got this really cool access list entry. Now, what's the problem with this? It's on the INSIDE interface. It's inbound on that interface.


And check it out, it's denying-- anything else? If the answer is no, we just killed all of our traffic because an access list, just like in an IOS router, has a default implicit deny at the end. So we would be well to highlight this access list. So we're going to insert after.


And we're going to say, I want to go ahead and add a permit for IP any, any for all the rest of the traffic. So now we have two rules in place in our INSIDE access list. We have a deny of the traffic from 10.0.0 if it's going to and it's an echo. And we're going to allow everything else.


So Apply that and take a look at the syntax here. Look at this IP address. We have 10.0.0 for the network, and I want you to pay attention to that mask. It's just a normal mask, So anything weird, like wouldn't be a valid syntax on as ASA as part of an access list.


So having said that, it's going to create the access list, two entries. It's going to apply it inbound on the INSIDE interface. We'll send it over, and let's go try our test one more time. So we'll bring back our command prompt. This ping worked a moment ago.


Now it's not working, and that's good. That means we're applied correctly. But let's make sure that we can still get out with other protocols. So let's do-- I think we have still on the-- there we go. We'll do our nslookup. That's still working. So UDP works.


And if we wanted to open up a browser, let's go ahead and bring in Google. It's already open. I clicked on it to launch it and it went. So if we went to another site such as, it comes right up. We're good to go. So everything is working except for the pings out to The DNS work out that works out there, which is UDP but not the pings.


If we wanted to troubleshoot that and we say, well, why isn't ping working? Let's say we didn't realize or understand why. We could go back to our good friend the Packet Tracer and say, why isn't the ping working from out to It's ICMP. It's an echo request.


And let's say 1 there and 1 there. And then we'll say Start. And it's going to send it out and it's going to go-- I should have clicked on don't show the animation. But it's going for the route lookup. It then goes to the access list. It stops. The little x there says it never made it.


And it actually tells us, the flow is denied by a configured rule. The access list killed the packet. So there's the details of it right there, access list INSIDE and it denied ICMP coming from the 10.0.0 network going to So that's a great method of verifying.


Another tool, while I have you, is we could go ahead and look at logging. This is also amazing. Under monitoring, if we go down to logging and enable it-- we'll say, yeah, I want to enable logging. And we could launch this real-time logging viewer. So let me bring back our command prompt and let's go try the ping that failed there.


This one. And it's going to show us exactly what happened. So here we have the entry. We have a deny. The details are all down here. So it says deny ICMP source INSIDE, destination OUTSIDE, ICMP type 8 by access group called INSIDE access in. So it's a great way to visually see.


This is just syslog messages that we can see right here in the graphical user interface. So in this video, we've taken a look at the ASA, the Adaptive Security Appliance. How to bootstrap it so we can get basic connectivity to it, how we can use ASDM to manage it.


And it once it's in place, it's doing stateful inspection for traffic as well as NAT if we configure it, so that when users go out to the internet they're [INAUDIBLE] to the OUTSIDE interface address. That's based on what we configured. And because of the stateful inspection, return traffic is allowed for TCP, for UDP, and there's a host of application-layer inspections as well.


But what isn't inspected by default as ICMP. We turned on ICMP inspection, and then all of a sudden we could send ICMP out and get our replies back as well. What else does ASA support? It can support DHCP. It can be a client and a server. A client here and a server here to its devices.


It can provide botnet support. It can do application-layer inspection. it can use object groups. It can support VPNs. And by the way, VPNs we'll cover in a complete separate Nugget just on IPsec and SSL VPNs in the latter part of this Nugget series. So that's coming up.


Hang onto that one. It also has support for AAA, the Authentication, Authorization, and Accounting. So if this is an ASA inside of your enterprise, you don't have to create all your local users on that ASA. You can have them on a AAA server. And then when Jill VPNs in and wants to authenticate, the ASA can check with the AAA server and say, hey, it's Jill.


Here's her credentials. Is she valid? And if so, provide access into the network. I have had a lot of fun taking this little ASA with you and bringing it all way from a default config into a working config that involved stateful inspection, network address translation, and even customizing the policy to tell it to inspect ICMP as well.

Intrusion Prevention Systems (IPS)

IOS-based IPS

Cryptography Essentials

IPsec Site to Site VPNs


Defense in Depth

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Intermediate 11 hrs 17 videos


Basic Plan Features

Speed Control
Included in this course
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Included in this course
Follow what the trainers are saying with ease.

Included in this course
Files/materials that supplement the video training

Premium Plan Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Included in this course
Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Included in this course
Develop and maintain a study plan with assistance from coaches.
Keith Barker
Nugget trainer since 2012