The first portion of INE's new CCIE Security Advanced Technologies Class for the 3.0 blueprint is now available in both streaming and download formats.  Subscribers to the All Access Pass already have access to this new course, and can upgrade to the download version for $159.  Non-subscribers can purchase the standalone download for $299, or subscribe to the AAP for just $159 per month.  Customers who have access to previous versions of the CCIE Security ATC will get access to the new streaming version at no extra charge.

The current release of the class contains the first 18 hours of videos.  New videos will be posted incrementally over the next few weeks, to bring the final runtime somewhere between 40 and 60 hours.  Specifically the following topics are covered in this first portion of the release:

  • Introduction 0h 37m
  • CCIE Security Preparation Resources 0h 50m
  • ASA Overview 0h 37m
  • Basic ASA Initialization 1h 02m
  • ASA Routing 0h 37m
  • ASA Reliable Static Routing
  • ASA Access Control Lists (ACLs) 0h 41m
  • ASA Modular Policy Framework (MPF) Overview 0h 53m
  • ASA Modular Policy Framework (MPF) Configuration 0h 51m
  • ASA Advanced TCP Inspection with MPF 0h 40m
  • ASA Advanced Application Inspection with MPF 0h 36m
  • ASA Quality of Service (QoS) 0h 30m
  • ASA Network Address Translation (NAT) Part 1 0h 50m
  • ASA Network Address Translation (NAT) Part 2 0h 30m
  • ASA Transparent Firewall Overview 0h 25m
  • ASA Transparent Firewall Configuration 0h 43m
  • ASA ARP Inspection with Transparent Firewall 0h 21m
  • ASA Multiple Context Mode Overview 0h 42m
  • ASA Multiple Context Mode Configuration 0h 59m
  • ASA Redundant Interfaces 0h 22m
  • ASA Failover Overview 0h 19m
  • ASA Active/Standby Failover Routed Firewall Configuration 0h 29m
  • ASA Active/Standby Failover Transparent Firewall Configuration 0h 17m
  • ASA Active/Active Failover Routed Firewall Configuration
  • ASA Multiple Context Transparent Firewall Configuration 0h 29m
  • ASA Active/Active Failover Transparent Firewall Configuration 0h 29m
  • IOS Access Control Lists (ACLs) 0h 23m
  • IOS Time Based ACLs 0h 13m
  • IOS Lock & Key Security with Dynamic ACLs 0h 24m
  • IOS Reflexive ACLs 0h 44m
  • IOS TCP Intercept and Content Based Access Control (CBAC) 0h 39m

INE is proud to announce the upcoming release of our new CCIE Security Advanced Technologies Class and CCIE Security 5-Day Bootcamp. The 5-Day Bootcamp will be available in streaming and download format starting this weekend, followed shortly by the Advanced Technologies class. Both of these video series are included with the All Access Pass subscriptions, or can be purchased as standalone downloads.  Samples of both classes are available below.

CCIE Security 5-Day Bootcamp
IOS Zone Based Policy  Firewall (ZBPF)

CCIE Security Advanced Technologies Class
ASA Active/Active Failover


INE is proud to announce the upcoming release of the following new additions to our All Access Pass Video-on-Demand library:

  • CCNA Security - Implementing Cisco IOS Network Security (640-553 IINS)
  • CCNP Security - Securing Networks with Cisco Routers and Switches (642-637 SECURE v1.0)
  • CCNP Security - Deploying Cisco ASA Firewall Solutions (642-617 FIREWALL v1.0)
  • CCNP Security - Deploying Cisco ASA VPN Solutions (642-647 VPN v1.0)
  • CCNP Security - Implementing Cisco Intrusion Prevention System v7.0 (642-627 IPS v7.0)
  • CCIE Security Advanced Technologies Class for Blueprint v3.0
  • CCIE Service Provider Advanced Technologies Class for Blueprint v3.0

All of these classes will be delivered by me, Brian McGahan - 3 x CCIE #8593.  Release dates for the CCNA Security and CCNP Security videos will be early and late July 2011 respectively.  The CCIE Security Advanced Technologies Class will be running as a live online class from July 25th – July 29th 2011, with an estimated release date of August 5th 2011 for the videos.  The CCIE Service Provider Advanced Technologies Class will be running as a live online class from August 29th – September 2nd 2011, with an estimated release date of September 9th 2011.

Subscribers to the All Access Pass will have immediate access to the streaming videos as they become available, and can attend the live online sessions of CCIE Security ATC and CCIE Service Provider ATC at no additional charge.  Seating is limited for the live class sessions, so contact as soon as possible if you are interested in attending.  Download versions of each of the classes will be available for purchase as a standalone product, or as a discounted upgrade for AAP subscribers.

We will also releasing a new CCNA course delivered by Brian Dennis - 5 x CCIE #2210, and both CCNA Voice & CCNP Voice courses delivered by Mark Snow - 2 x CCIE #14073.  More details about these releases will be available soon.



After returning from vacation, Bob (the optimistic firewall technician) decided that he wanted to take some time and get a little bit more familiar with firewall configuration. He was able to get permission to use some spare equipment for practice.



He started with a basic configuration on the firewall:

hostname INEASA1
password cisco
enable password cisco

interface e0/1
nameif inside
no shut
ip address
security-level 90

interface e0/0
nameif outside
ip address
security-level 10
no shut

Bob verified that he could ping both R1 and his PC from the Firewall. Now, he wants to configure the firewall to allow telnet from his PC. He remembers that there was some additional configuration that needed to be done on the firewall to allow this to work, but doesn't remember exactly what is needed. Since his PC isn't connected to the internet, he is not able to access the online documentation.

What additional configuration will allow Bob to telnet to the firewall from his PC?

There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn't spoiled for others.


OK, so let's look at the problem here. The PC is on the outside of the firewall, and according to multiple responses, you can't telnet to the outside interface. (or can you?)

A few helpful hints when studying for the CCIE lab.

1. Don't be afraid to go to the documentation, even for topics you think you know.
2 Re-read the question, to see just what you are asked to do and what your restrictions are.

So, where does the confusion about being able to telnet to the firewall come from? Perhaps it comes from trying in earlier versions, perhaps some confusion about what the documentation says, or perhaps someone read somewhere in the past that it just wouldn't work.

Let's start by carefully re-reading the documentation. ASA - Config guide - system administration - managing system access - allowing telnet

This section states:

"...The security appliance allows Telnet connections to the security appliance for management purposes. You cannot use Telnet to the lowest security interface unless you use Telnet inside an IPSec tunnel. ..."

So, it doesn't explicitly mention the outside, it mentions the "lowest security interface". In most cases that is the outside, but not always.

A few "solutions"

1. Configure the switch so that Bob's PC is on VLAN 121 instead of VLAN 122, configure the firewall to allow telnet on the inside interface. (Technically would meet requirements, but not much of a challenge.)

2. Change the security levels for the interfaces, making them the same or making the outside higher.

3. Add another interface with a lower security level

int eth0/1.1
vlan 123
nameif DMZ
sec 9

4. Configure a VPN for the firewall, so that the telnet traffic to the lower security (outside) interface is encrypted and therefore allowed.

5. Configure the firewall to allow transit traffic through to R1. Telnet to R1, and then Telnet to the ASA from R1, after configuring the ASA to allow telnet on the inside interface.


Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does not go over all firewall features in depth.

Traffic Flow through the Firewall

ASA is a complicated piece of hardware and software, just like any stateful firewall. However, for the purpose of understanding the MPF it is enough to use the following simplified packet flow checklist:

  1. See if packet matches a flow in the connection table if so, skip to (4). This means packets matching existing states bypass the ACL checks
  2. Find egress interface, drop packet if egress interface cannot be found. Two options:
    1. Packet’s destination address matches existing XLATE state or STATIC NAT statement. This is common when you use outside NAT. Egress interface is determined from the NAT entry.
    2. Perform route lookup on the destination IP address to find egress interface
  3. Match input access-list on the ingress interface. Use the ORIGINAL destination IP address, not the untranslated IP for matching
  4. Match flow against input QoS policy (interface or global policy, where interface policy takes precedence)
  5. Apply source NAT if XLATE state does not exist and there is matching NAT rule. Use the following order of operations:
    1. NAT exemption, configuration using the command nat (interface) 0 access-list
    2. First matching STATIC NAT or PAT, with NAT taking precedence. If multiple entries match the packet, select the first one.
    3. Dynamic NAT entries configured using the command nat (interface) [ID] access-list
    4. Dynamic NAT entries configured using the command nat (interface) [ID] [network] [mask]. If [ID]=0 then identity XLATEs are created
  6. Apply egress QoS policy (output policing, interface or global)
  7. Create or update flow information
  8. Lookup output egress interface in routing table based on destination IP. Find out the next-hop, which should be on the SAME interface as XLATE points to, if XLATE/STATIC was used at step (2). This route should not necessarily be the LONGEST match, just any matching route out of selected interface.

It is important to notice two important things: firstly, the addresses you should use in the access-lists are supposed to be pre-NAT addresses or in other words just as the packet originator sees them. Secondly, pay attention to the concept of XLATE-based routing that ASA uses. This concept requires special attention.
What is the point of pinning an egress interface to a NAT entry? The reason being the fact that if there exists an XLATE entry, then more likely there are traffic flows using it. Therefore it is desirable pinning traffic to the same interface that was used for XLATE creation – otherwise traffic may match different NAT rule and the connection will be broken. This is why the firewall attempts finding the egress interface using the XLATE first. However, what happens if the route has flapped and the untranslated address is now reachable via a different interface? The firewall will still perform a route lookup using all routes that are bound to the original interface and try finding a match. If a match is found, it is used to find out the next-hop and route packet out. If not, the packet is dropped. Look at the following configuration sample:

static (outside,inside)
route outside 1
route DMZ

Here packets going from “inside” to “outside” toward the IP address are destination untranslated to the IP address This IP is statically routed over the DMZ interface, but the firewall will only check the routes bound to the “outside” interface and use the default route to route the packet to In this situation, even though the specific static route is not correct, the NAT-bound egress interface decision allows traffic to flow correctly.

Traffic Classification

Every MPF rule has a scope - subset of traffic that the rule applies to - and action - feature or a set of features triggered by this rule. In ASA firewall, L3/L4 class-maps are used to specify the traffic for a rule. The following is the list of the mot common classification criteria:

  • Access-List. Most typical and very flexible criterion, allows matching based source/destination IP addresses, port numbers, protocols and so on – everything you can put in an ACL. Example:
    access-list BGP permit tcp host any eq bgp
    access-list BGP permit tcp any eq bgp host
    class-map BGP
    match access-group BGP
  • Port numbers/range. Without configuring an access-list, you can specify TCP/UDP port numbers to be matched by the class map, such as follows:
    class-map PORTS
    match port tcp range 100 200
  • Tunnel Group name. Allows matching the traffic for a particular tunnel group in the firewall. The firewall will dynamically track VPN tunnels created for this group and classify traffic accordingly.
    class-map TUNNEL_GROUP
    match tunnel-group TEST

    In addition to specifying the match tunnel-group criterion, you can also configure one additional match statement. You are allowed any additional criterion with except to match any or match access-list or match default-inspection-traffic. For example the following configuration is supposed to matchVoIP traffic within the VPN tunnel, provided that VoIP packets are marked with DSCP value of EF.

    class-map VPN_VOICE
    match tunnel-group TEST
    match dscp ef
  • Per-flow classification criterion configured using the match flow ip destination-address. This one could be used only along with the match tunnel-group command. When configured, it tracks every VPN connection separately and applies the configured action per-flow, not to all VPN traffic at the same time. This is particularly useful for Remote-Access VPN connections, where multiple users connection to the firewall unit. Notice that you can apply the QoS policing feature only per-flow, when classifying based on tunnel group names. Example:
    class-map VPN_FLOWS
    match tunnel-group TEST
    match flow ip destination-address
  • Matching the default classification traffic. This is special “intelligent” type of classification used exclusively with inspect action. It matches traffic on the default port numbers for ALL available inspection engines. For example it will match FTP traffic on port 21, HTTP on port 80, DNS on port 53 and so on. As mentioned, the only supported feature with this classification type is traffic inspection.
  • Other classification criteria such as match dscp and match rtp. Those allow matching based on the DSCP value in IP packet headers and matching based on RTP port range.

    As you noticed, a typical class map will only support ONE match command. The only exception is the use of match tunnel-group along with some other match commands.

Applying Features in Policy Maps
After you defined traffic classes, you may configure MPF rules using regular policy-map. We call them regular, as there are special inspection policy maps, used to define inspection settings and parameers. Regular policy maps attach actions to L3/L4 classes using the following syntax:

policy-map <NAME>
class <CLASS1>
class <CLASS2>

The list of the applicable firewall features follows:

  1. QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
  2. TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Configured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
  3. CSC (if installed). Content security.
  4. Application inspection (multiple types). The core of the stateful firewall. Parses traffic streams and detects application protocols and their commands. Allows enforcing per-application security policies. The command to apply inspection is inspect {protocol-name}. Could be fine-tuned using inspection policy-maps.
  5. IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
  6. QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
  7. QoS interface priority queue. Services traffic using the interface-level low-latency queue. Configured using the command priority. Could not be applied along with policing feature.
  8. QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default

There could be a situation when a packet/flow matches multiple classes within the same policy-map. For example, with the following configuration

class-map FTP
match port tcp eq 21
access-list TCP permit tcp any any
class TCP
match access-list TCP
class default-inspection-traffic
inspect ftp
class FTP
set connection conn-max 100
class TCP
set connection conn-max 200
police input 150000

FTP packets would match all three classes at the same time. The question is: what action should the firewall apply to this flow? The rule of thumb to resolve conflicts in situations like that is as follows:

  1. For a given feature type, the flow can match only one class, based on the order the classes are configure in the policy map. In our example, the TCP connection limits are set for classes “FTP” and “TCP”, both matched by the flow in question. Since “FTP” precedes “TCP” the TCP connection limit is set based on “FTP” class.
  2. If the packet flow matches multiple classes with different feature types (e.g. QoS and inspection), then feature actions from all classes are combined provided that they are not conflicting. In our example, FTP flow will be inspected, limited to 100 connections and policed ingress to 150Kbps.

The next question is: if the multiple features are combined together, what is the order they are applied to the flow? It does not depend on the order of the class-map within the policy-map. The actions are applied in sequence, in the same order they are presented in the list above. In our example, the flow is first policed, then normalized and then inspected. Notice that some features may drop packets (such as policing) or modify the traffic contents (e.g. TCP normalization or inspection).

Levels and Directions

Policy map could be applied globally or per interface. There could be only one global policy map and one policy-map applied per interface. The question is: how those maps are combined to build the resulting set of MPF rules? When traffic goes across the firewall, the system determines the ingress and egress interfaces for the flow based on the routing table and xlate entries. The system builds the list of classes matched by the flow based on the feature direction for every class configured under the policy-maps. Here is the table from the Doc CD:

Feature Interface-Level Direction Global Policy Direction
Inspection Bidirectional Ingress
CSC Bidirectional Ingress
IPS Bidirectional Ingress
QoS Input Policing Ingress Ingress
QoS Output Policing Egress Egress
QoS Interface-Level PQ Egress Egress
QoS Shaping, Hierarchical PQ Egress N/A
TCP Normalization, Connection Limits, ISN randomization Bidirectional Ingress

How to read this table? Let’s take the TCP Normalization feature for example. Suppose it is configured at the interface level. Then, based on its bi-directional behavior, packets entering and leaving the interface will be subject to normalization process, provided that they match the respective class-map. Take another example. If you have configured FTP traffic inspection at the interface level like this:

access-list FTP_FROM_INSIDE
permit tcp any eq 21
match access-list FTP
policy-map INSPECTION
set connection max-conn 100
inspect ftp

Then both features apply only to FTP traffic going from the inside network to the outside on port 21. The traffic to the inside network on port 21 is not inspected nor limited, even though features are bi-directional, as it does not match the access-list. To inspect traffic bi-directionally you need the access-list

access-list FTP_FROM_INSIDE
permit tcp any eq 21
permit tcp any 255.255.255 eq 21

OK, that looks reasonable enough. Now what should the firewall do if a packet/flow matches multiple classes in level policy maps applied at different levels (i.e. interface and global)? Here is how the conflicts are resolved:

  1. If there is a feature defined in the interface-level policy map and global policy map, and the flow matches both classes, the interface-level settings take precedence. For example, if the interface-level class-map FTP sets connection-limit to 100 and the global policy set the limit to 200, the resulting limit for FTP traffic is 100.
  2. If the flow matches classes at the interface-level and global policy-maps and the classes have different features configured (e.g. inspect and policing) then actions are combined. The order that the features are applied is per the list provided above.
  3. If the flow matches classes both at ingress and egress interfaces, the resulting effect depends on the type of traffic. Traffic classified “statefully”, such as TCP and UDP flows and ICMP, when ICMP inspection is enabled, triggers the same feature in different policy-maps only once. For example, if the flow enters the firewall and triggers the inspection feature in the ingress interface-level policy-map, the firewall will store this event in the state table. No further attempts to perform traffic inspection or normalization are made for this flow, even if it matches the egress interface policy. Moreover, the returning packets for the flow are not matched against the “flow-aware” features ingress on the returning interface. This is the direct consequence of the firewall stateful behavior. The list of “flow-aware” features includes: application inspection, CSC/IPS, TCP normalization and connection limiting.

What if the packet stream is not treated by the firewall as a single flow? For example, imagine a stream of ICMP packets when ICMP inspection is disabled. In this case, bidirectional features on ingress and egress interfaces will apply twice. Moreover, the returning packets will also be subject to feature actions, such as IPS checks. This behavior is also true with any flow unaware feature, such as QoS policing.

Feature Incompatibilities

As you remember, you can apply multiple actions under the same class. Some actions just can’t go together. Here is the list of the limitations:

  1. You can’t combine policing and interface-level priority queuing for the same class.
  2. You can’t configure shaping in global policy map.
  3. You can only shape ALL traffic leaving the interface, i.e. you can only shape under class-default.
  4. You cannot configure two inspect actions under the same class with except to default-inspection-traffic class.

What if traffic flow matches multiple classes and those classes define different protocol inspection actions? For example, what if the interface policy has two classes configured like the following:

class-map FTP
match port tcp eq 21
class-map HTTP
match port tcp eq 21
policy-map TEST
class FTP
inspect ftp
class HTTP
inspect http

Then the FTP flow will match both classes. However, one applies FTP inspection and another HTTP inspection. To resolve such conflicts, the firewall uses the list of application priorities (from the DocCD):

  2. DNS
  3. FTP
  4. GTP
  5. H323
  6. HTTP
  7. ICMP
  8. ICMP error
  9. ILS
  10. MGCP
  11. NetBIOS
  12. PPTP
  13. Sun RPC
  14. RSH
  15. RTSP
  16. SIP
  17. Skinny
  18. SMTP
  19. SNMP
  20. SQL*Net
  21. TFTP
  22. XDMCP
  23. DCERPC
  24. Instant Messaging

Application priority decreases in descending order, with CTIQBE inspection having highest priority. The inspection action with higher priority will be preferred in case of conflict. In the example described above, FTP is more preferred than HTTP, and thus traffic is inspected for FTP protocol.


As you can see, ASA firewall system implements sophisticated logic for traffic matching and feature application. This is the direct result of combining multiple features for the same set of traffic using the class->action based syntax. Right now the semantic is not very transparent, and it might take time to understand a particular configuration. Here is the list of basic points about MPF:

  1. Service policies could be applied globally or per-interface.
  2. A packet flow can match multiple classes.
  3. In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
  4. In the classes specify different features, they are combined, provided that the features could be used together.
  5. Many firewall features are aware of stateful traffic flows.
  6. The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.

I. Security Fundamentals

a. Why Needed?

i. A closed network allows no connection to a public network; although security is still an issue due to a majority of attacks coming from inside networks today

ii. Open networks - these are very common and feature multiple connections to public networks - now two major threats - inside and outside

iii. The sophistication of tools for compromising security have increased and the knowledge required to use them has decreased

iv. E-business and more open networks increase the challenges

v. New laws require security - growing levels of terrorist and criminal activities

vi. Information Assurance - availability and protection of information - organizations can classify information and decide on access levels and levels of protection; a typical diagram would show what types of information are going to be accessible to the public, versus what types of information will be available to all employees versus what types of information will be available to specific groups

vii. Organizations should define threats in three terms:

1. Adversaries - terrorists, disgruntled employees, competitors

2. Motivations - DOS, theft, challenges , etc

3. Classes of attacks

a. Passive - these attacks include monitoring of communications and passwords

b. Active - these attacks attempt to steal or modify information, or introduce malicious code

c. Close-in - regular individuals gaining close physical proximity to networks or systems for the purpose of gaining information

d. Insider - attacks from internal employees can be malicious or non-malicious in nature

e. Distribution - the malicious modification of hardware or software at the factory or during distribution

viii. Defense-in-depth strategy to information assurance requires a balanced focus on People, Technology, and Operations

1. People - Training and awareness, physical security, personnel security, policies and procedures

2. Technology - use of evaluated products and solutions, use of a layered defense strategy

3. Operations - enforcement of security policies, quick response and restoration of critical service disruptions

ix. Defense-in-Depth recommends:

1. Defense in multiple areas

2. Layered defenses

3. Use of robust equipment

4. Robust key management

5. Deployment of IDS and IPS

x. Corporations should consider the Security Wheel - a continuous process of:

1. Secure - authentication, encryption, firewalls, vulnerability patching

2. Monitor - detect violations, auditing

3. Test - vulnerability scanning, auditing

4. Improve - adjust the policy as issues are found

xi. Companies should consider the use of:

1. Security policy

2. Security architecture

3. Security technologies

b. Network Attack Mitigation Techniques

i. Before you begin - recognize the low risk devices from the high risk devices

ii. Physical Installation Threats

1. Hardware Threat Mitigation - lock up equipment and prevent physical access; monitor entry with logs; use security cameras

2. Environmental Threat Mitigation - temperature and humidity controls; positive air flow; remove electrostatic and magnetic issues; remotely monitor and alarm

3. Electrical Threat Mitigation - UPS; backup generator; test UPS/generator regularly; redundant power supplies; monitors and alarms

4. Maintenance-related Threat Mitigation - cable labels; neat cable runs; electrostatic discharge procedures; replacement stock; disconnect console ports; do not rely on locked room alone

iii. Reconnaissance Attacks and Mitigation

1. Packet sniffers

a. Authentication

b. Switched Infrastructure

c. Antisniffer tools

d. Cryptography - the best method

2. Port Scans and Ping Sweeps

a. IPS at the network and host levels

3. Internet Information Queries

iv. Access Attacks

1. Password Attacks

a. No same password across systems

b. Disable accounts after incorrect guesses

c. No plain text passwords

d. Strong passwords

2. Trust Exploitation

a. Systems inside the firewall should never assume absolute trust of systems outside the firewall

3. Port Redirection

a. Attacker uses host to get traffic through a firewall that would normally be dropped

b. Host based intrusion prevention and proper trust models

4. Buffer Overflow

a. IPS and IDS

b. Stack smashing protection

c. Executable space protection

d. Safe libraries

v. Spoofing Attacks

1. IP Spoofing

a. Blind - calculates sequence numbers

b. Nonblind - sniffs information

c. Mitigate - ACLS, Encryption, Authentication

2. Man-in-the-Middle

a. Encryption

vi. DoS

1. SYN Flooding

2. ACLS, Antivirus, Anti-DoS features, traffic rate limiting

vii. Worm, Virus, Trojan Horse

1. Containment, Inoculation, Quarantine, Treatment

2. Antivirus, Keep up to Date

viii. Application Layer

1. Log files, mailing lists, latest patches, IDS/IPS

ix. Management Protocols

1. Do not use Telnet

a. SSH

b. ACLs for Telnet

c. RFC 3704 filtering


a. Version 3

b. ACLs

c. Read only

3. Logging

a. Encrypt

b. RFC 3704 filtering

c. Access control


a. Encrypt

5. NTP

a. Private master clock

b. NTP v 3

c. ACLs and authentication

x. Determining Vulnerabilities

1. GNU Netcat

2. Blues Port Scan

3. Ethereal



As I am sure you have already seen from the blog on setting up the security device as a Layer 2 device, there are many interesting changes that occur on a PIX or ASA when configured for transparent operations. This blog highlights the major changes and guidelines that you should keep in mind when you opt for this special mode of operation.

  • Number of interfaces - perhaps on of the biggest things you will want to keep in mind is the fact that you are going to be limited on the number of traffic forwarding interfaces you can use when in Layer 2 mode. When you switch to transparent mode, you are limited to the use of two traffic forwarding interfaces. On some ASA models, you may also use your dedicated management interface, but of course, the use of this port is limited for management traffic. Remember also, when in multiple context mode, you cannot share interfaces between contexts like you can when in routed mode.
  • IP addressing - here is another major difference of course. In Layer 2 mode, you will assign a single IP address to the device in Global Configuration mode. This address is for remote management purposes and is required before the device will forward traffic. Once the address is assigned, all interfaces start "listening" on this address to ensure the device is responsive to its administrator. This global IP addressed assigned to the device must be in the same subnet that the forwarding interfaces are participating in. Remember, the transparent firewall is not adding a new network (subnet) to your topology.
  • Default gateway - for traffic sourced from the security device itself, you can configure a default gateway on the transparent device. You can do this with the route 0 0 command.
  • IPv6 support - the transparent firewall does not support IPv6.
  • Non-IP traffic - you can pass non-IP traffic through the Layer 2 Mode device. Note that this is not possible on a security appliance in its default Layer 3 mode.
  • More unsupported features - the Layer 2 mode device does not support - Quality of Service (QoS) or Network Address Translation (NAT).
  • Multicast - the transparent mode device does not offer multicast support, but you can configure Access Control Lists (ACLs) in order to pass multicast traffic through the device.
  • Inspection - with the Layer 2 mode device you can inspect traffic at Layer 2 and above. With the classic routed mode configuration, you can only inspect at Layer 3 and above.
  • VPN support - the transparent mode device does support a site to site VPN configuration, but only for its management traffic.

This blog will examine the basic setup of the transparent firewall feature available with the PIX and the ASA. This blog was based on the PIX-525 running 7.2(4) code with a Restricted license in GNS3. Here is the topology that was used:

Remember, that a transparent firewall resides WITHIN a subnet and is easy to implement in an existing network where re-addressing to introduce a firewall might be difficult. This configuration is sometimes known as a "stealth" firewall or a "bump on the wire". Thanks to the fact that the firewall lives within the subnet, instead of between it, the device has the ability to filter traffic between hosts within the subnet. Note that the traditional Layer 3 firewall can only filter traffic moving between subnets. This should remind you of the difference between a VLAN Access Control List versus a Router-based Access Control List.
Well, with the introductions out of the way, let's do what we love best, let's get to the command line.
The first thing I will do is configure and verify the transparent firewall feature and then name our PIX:

pixfirewall> en
pixfirewall# conf t
pixfirewall(config)#  firewall transparent
pixfirewall(config)# show firewall
Firewall mode: Transparent
pixfirewall(config)# hostname LAYER2FIREWALL

Excellent, now that the firewall is in transparent mode, let's take care of the inside and outside interfaces. When in transparent mode, you are limited to the use of two interfaces for passing traffic. Notice how the interfaces are not configured with IP addresses.

LAYER2FIREWALL(config)# int e1
LAYER2FIREWALL(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
LAYER2FIREWALL(config-if)# no shut
LAYER2FIREWALL(config-if)# exit
LAYER2FIREWALL(config)# int e0
LAYER2FIREWALL(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
LAYER2FIREWALL(config-if)# no shut
LAYER2FIREWALL(config-if)# sh int ip brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0                  unassigned      YES unset  up                    up
Ethernet1                  unassigned      YES unset  up                    up
Ethernet2                  unassigned      YES unset  administratively down up
Ethernet3                  unassigned      YES unset  administratively down up
Ethernet4                  unassigned      YES unset  administratively down up

I am sure this output looks a little strange for those of you that have not played with this feature. Just as unusual is the fact that all of the interfaces facing this device are addressed in the subnet.

A requirement of the transparent firewall is that it must have an IP address assigned in global configuration mode for management access.  Notice for verification we can see that our traffic forwarding interfaces are now "listening" on that IP address:

LAYER2FIREWALL(config)# ip address
LAYER2FIREWALL(config)# sh int ip brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0               YES unset  up                    up 
Ethernet1               YES unset  up                    up 
Ethernet2                  unassigned      YES unset  administratively down up 
Ethernet3                  unassigned      YES unset  administratively down up 
Ethernet4                  unassigned      YES unset  administratively down up

Let us now test the "out of the box" functionality of the security device. I will initiate a Telnet session from the Inside interface to a device located on the Outside interface. This communication should be permitted due to the Adaptive Security Algorithm and the default security levels on our interfaces. Notice how we can easily verify the connection of the appliance.

Trying ... Open
User Access Verification
LAYER2FIREWALL(config)# show conn
1 in use, 1 most used
TCP outside inside, idle 0:00:03, bytes 102, flags UIO

Let's now permit Telnet connections from our management workstation (played by R2) and ensure we have connectivity to the PIX.

LAYER2FIREWALL(config)# telnet Inside
Trying ... Open
User Access Verification
Type help or '?' for a list of available commands.

Well, I am sure I will blog more on this Layer 2 firewall at a later point, but I sure do thank you for stopping by to read this initial post.


Thanks to Anisha with Cisco Systems for this idea. We were in Brian McGahan's CCIE Security 5 Day Bootcamp, and she realized it would be nice to have a Quick Ref of his troubleshooting/verification commands. There is a bazillion shows and debugs it seems, but you only need a subset to be successful in the lab. Here is the first part of the "cheat sheet". The rest will follow in the respective categories in the blog. Please let me know via comment if you see errors or have additions. I added to Brian's classroom commands with some of my own. I also took a few from the Cisco Press ASA All-In-One Guide. It is an excellent text for your Kindle!



debug radius
debug tacacs
show aaa-server protocol PROTOCOL_NAME
test aaa-server

Access Control Lists

show access-list
show run | include ACCESS_LIST_NAME
show run object-group
show run time-range

Application Inspection

show conn state STATE_TYPE detail
show service-policy

Configuring Interfaces

show firewall
show int
show int ip brief
show ip
show mode
show nameif
show run interface INTERFACE_NAME
show version

Connections and Translations

clear xlate
show conn
show conn detail
show local-host all
clear local-host all (clears all connections)
show log
show run | begin policy-map
show run global
show run nat
show xlate
test regex


debug fo rxip
debug fo txip
show failover
show ip

IP Routing

deug ospf event
debug rip
show ospf database
show ospf interface
show ospf neighbor
show ospf PROCESS_ID
show ospf virtual-links
show route


show igmp interface
show mroute
show pim interface
show pim neighbor


debug crypto ca messages
debug crypto ca transactions
show crypto ca certificates
show crypto ca crls
show crypto key mypubkey rsa

Quality of Service

show priority-queue statistics
show run class-map
show run policy-map
show service-policy global
show service-policy interface INTERFACE_NAME
show service-policy priority
show service-policy shape

Security Contexts

show admin-context
show context
show mode

System Management

show clock
show crypto key mypubkey rsa
show logging
show ntp status
show running-config
show snmp-server statistics
show ssh sessions
show startup-config

Transparent Firewall

debug arp-inspection
debug l2-indication
debug mac-address-table
show access-list
show arp-inspection
show conn
show firewall
show mac-address-table


debug crypto ipsec
debug crypto isakmp
show crypto ipsec sa
show crypto isakmp sa detail
show route


debug menu wbvpn
debug ssl cipher
show vpn-sessiondb summary
show vpn-sessiondb webvpn


This post was created using GNS3 and follows what I thought was some of the most lab and real-world relevant content from the Cisco ASA documentation in the area of IP Routing:


Here is the topology used:

 The Topology


Initial Setup

First, we place the necessary IP configurations on the devices for our initial connectivity:

conf t
host R0
line con 0
exec-time 0 0
logg synch
int fa0/0
no shut
ip address
conf t
host R1
line con 0
exec-time 0 0
logg synch
int fa0/0
no shut
ip address
interface loopback 20
ip address
conf t
host R2
line con 0
exec-time 0 0
logg synch
int fa0/0
no shut
ip address
conf t
host FW0
int e0
ip address
nameif outside
no shut
int e1
ip address
nameif inside
no shut
int e2
ip address
nameif DMZ
security-level 50
no shut

At this point, I will be sure to ping each connected router from the PIX to ensure IP connectivity. Remember, by default you can ping from the PIX and to the PIX, but you cannot ping through the PIX.

Static Routing

First, I will create a simple static route to the "remote" loopback network that I have created on R1. Notice that to create a static route we simply use the route command, followed by the interface name, then the network and mask, and finally the next hop. Notice how similar this is to the syntax for a static route on a router, although one major difference is the command does not begin with ip.

conf t
route inside

Verification of this static route can be accomplished with a show route and a ping of the remote destination address

Default Static Routing

In order to configure a default static route, use the route command but with an all 0's network prefix and mask. The PIX/ASA allow a shortcut of 0 and 0 to represent and Here I configure a default static route pointing to our outside router.

conf t
route outside 0 0

Verification for this configuration is a quick show route. The PIX/ASA should now show a gateway of last resort and the static route should be marked as a candidate default.

Static Route Tracking

An issue with the static route we just configured is the fact that if the destination gateway of last resort is down, the route is not removed from the routing table. This issue can be circumvented with the static route tracking capability.

First, I use the Cisco IOS IP Service Level Agreements (SLAs) monitor feature to track the availability of the gateway. This is done with the following commands:

conf t
sla monitor 1
type echo protocol ipIcmpEcho interface outside
sla monitor schedule 1 life forever start-time now

Notice these commands instruct the SLA monitor to ping the gateway starting now and to do this forever. I picked an SLA_ID of 1 to bind these commands together.

Next, I will associate a tracked static route with the SLA monitoring process using the following commands. Notice here that I have used a Track_ID of 20 and I have recreated our default static route so that it includes the Track_ID. Notice also here that the track command is tied to the SLA monitor with the SLA_ID of 1.

conf t
20 rtr 1 reachability
route outside 0 0 track 20

A nifty verification at this point is to move to R0 (the gateway of last resort) and run debug ip icmp. You will find that this router is being pinged every minute by the firewall now as a reachability test.

Next, I create a backup default static route. This is simply another default static route entry that possesses a higher administrative distance than the original static default route:

conf t
route outside 0 0 22

For verification, you can shut the interface on the default gateway and run a show route on the PIX/ASA to ensure the backup is installed.

Dynamic Routing - OSPF

Now it is time to tackle a dynamic routing protocol configuration. Here I configure an MD5 authenticated neighborship between R2 and FW0. Notice that the network command on the PIX/ASA requires a subnet mask as opposed to a wildcard mask.

conf t
router ospf 1
network area 0
interface fastethernet 0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco
conf t
router ospf 1
network area 0
interface e2
ospf authentication message-digest
ospf message-digest-key 1 md5 cisco

For verification, simply run show ospf neighbor on FW0.

Dynamic Routing - RIP version 2

Next, we will run RIP version 2 on the PIX/ASA and advertise the DMZ subnet to the internal router R1. Here are the configurations:

conf t
router rip
version 2
no auto-summary
passive-interface default
no passive-interface fa0/0
conf t
router rip
version 2
no auto-summary

 Verification for RIP in this example would include show ip route on R1 and debug rip on FW0.  


I certainly hope you have enjoyed this blog on IP routing with the PIX/ASA. While my goal was to hit the highlights, please keep in mind the fact that there are many features of the dynamic routing protocols that are available and not covered here. In fact, there are even some static routing features that were omitted in this discussion. Just remember that these features should be very easy to find in the documentation link when you are in the heat of battle.

Subscribe to INE Blog Updates