Global Knowledge Training Blog » ASA Appliance

Another Look at ASDM Demo Mode – Importing Your Configurations

Doug McKillip — Fri, 27 Jan 2012 13:05:21 +0000

Some time back I posted an article regarding the use of ASDM Demo Mode. To briefly summarize, I highlighted two main advantages to its use:

Being able to explore the features of the ASA GUI without involving a real “live” production appliance — and —
Helping the student prepare for a certification exam by practicing the interface.

As is frequently the case these days, a student of mine this past summer pointed out a valuable feature of this demo mode worth sharing, which is the subject of this post.

To recap a previous post, installation of ASDM Demo mode requires the download of the .msi file from the Cisco Software Center with “demo” in the file name. Once I did this, I encountered a “snag” with trying to have multiple versions “coexist”. Somewhere between ASDM Demo versions 6.2 and 6.3, the software execution changed to the point that I was not able to incrementally install new versions without “wiping out” the old. The solution to this was as simple as merely maintaining the folders contained in the path C:\Program Files\Cisco Systems\ASDM\demo; these are labeled as shown in this screenshot:

Within these folders are subfolders containing the individual configuration scenario templates worth examining; for my test implementation I chose SSL_VPN_IPSec, which is the bottom-most folder shown below:

The final “folder” screenshot shows the area of interest, a file with the name config. What I needed to do to make this work was to do a “cut and paste” of an ASA configuration into NotePad and then save the result. Special care needs to be taken to ensure that Windows Explorer does NOT see this file as a Text File (i.e. it should truly be a file named “config” vs “config.txt”)!

If special care was taken to observe the preceding procedure, a working ASDM representation of your configuration should result:

The above screenshot is just a small fraction of what was imported into ASDM; other photos could have been taken of access-lists, object-groups, and other configuration elements, all of which were understood by the ASDM demo software. Not only can this “configuration replacement” be done but also new folders can be created with your own naming conventions. These will appear as additional choices in the ASDM Demo launch screen. The possibilities here should be encouraging to anyone wishing to examine the ASDM GUI representation of their configuration(s) offline.

Related Courses
ASA Training

Some Observations and Opinions on Security Troubleshooting with syslog vs debug

Doug McKillip — Wed, 18 Jan 2012 18:46:15 +0000

Over the years in both the classroom and the customer site I had the “opportunity” to troubleshoot a Cisco security deployment. I put that word in quotes because, let’s face it, troubleshooting is done to solve problems which can be excellent learning opportunities. Two tools which frequently are chosen for this task, which are native to most Cisco devices, are: a) debug and b) syslog. This post offers my personal recommendations as when to choose one versus the other.

Let’s start with the use of debugging. The debug command is supported on both the ASA security appliance and the Cisco IOS^® router. An important and noteworthy implementation difference between the two platforms is that logging must be enabled for debug output to be seen on the router, but not on the ASA. A sample debug output for an IPSec Internet Key Exhange (IKE) Phase I exchange:

Jan 19 21:37:58 [IKEv1]: IP = 200.200.20.2, Error processing payload: Payload ID: 1
Jan 19 21:37:58 [IKEv1 DEBUG]: IP = 200.200.20.2, IKE MM Responder FSM error history (struct &0xc8f8bcc8) , : MM_DONE, EV_ERROR–>MM_START, EV_RCV_MSG–>MM_START, EV_START_MM–>MM_START, EV_START_MM–>MM_START, EV_START_MM–>MM_START, EV_START_MM–>MM_START, EV_START_MM–>MM_START, EV_START_MM
Jan 19 21:37:58 [IKEv1]: IP = 200.200.20.2, Removing peer from peer table failed, no match!
Jan 19 21:37:58 [IKEv1]: IP = 200.200.20.2, Error: Unable to remove PeerTblEntry

Most observers would agree that such output is quite cryptic, and, in most cases, requires a fairly thorough knowledge of the protocol to make sense of the messages. I remember needing a few minutes after observing the cryptic message along the lines of “…packet is malformed and failed sanity check” for me to correctly conclude that this was caused by mismatched VPN preshared keys!

By contrast, using syslog often provides a “big picture” view instead of getting “lost in the weeds”. Below is a screenshot of a very valuable tool now bundled with the Adaptive Security Device Manager known as the Real Time Syslog Viewer:

Not only does the use of the different colored fonts on the white background present a more appealing and “easier on the eye” format, but the colors were chosen such that the “cooler” colors (blue, purple) represent more trivial messages while the “hotter” colors (yellow and red (not shown)) represent the more serious events. Also, the three tabs at the bottom should not be overlooked as these provide additional event explanations, recommendations, and details for the highlighted row.

In conclusion, I don’t wish to appear too negative toward the use of appropriate “debug” commands. They are well-suited to understanding the operation of a protocol, especially when coupled with a network sniffer application. Secondly, as I told numerous students, verbose output (versus no output) is usually best — an indication of success. However, for quick problem identification, the often unambiguous output of a real time log viewer can’t be beat.

CCNP Security Question of the Week

Dawn Hopper — Thu, 12 Jan 2012 18:19:24 +0000

When setting the name of an interface from the command line, what is the default security level on any interface with a name other than inside?

0
50
100
none

The correct answer is 1.

When working from the command line (CLI) all interfaces other than the inside interface get a default security level of 0 (Most untrusted).

CCNP Security Question of the Week Series

CCNP Security Question of the Week

Dawn Hopper — Fri, 30 Dec 2011 18:52:14 +0000

True or False — The AIP-SSM supports hot swap capabilities.

The answer is False.

The Cisco ASA AIP-SSM does not support hot swap capabilities. To install the module, you must first shut down the Cisco ASA adaptive security appliance. You then power on the appliance after the module has been installed.

CCNP Security Question of the Week Series

CCNP Security Question of the Week

Dawn Hopper — Thu, 15 Dec 2011 18:41:19 +0000

The command that can be used on the standby firewall to force control back, making that firewall become active is?

failover preempt
reset failover
failover primary
failover active

The correct answer is 4.

Use the failover active command when you need to force the current unit into the active state. This need can occur in a situation such as when you want to switch control back from a unit after you have fixed a problem and want to restore service to the current standby unit.

CCNP Security Question of the Week Series

CCNP Security Question of the Week

Dawn Hopper — Thu, 01 Dec 2011 18:38:36 +0000

How many data interfaces are supported by a security appliance running in transparent mode with ASA version 8.2?

The correct answer is 2.

The transparent adaptive security appliance supports only two traffic passing interfaces. If the adaptive security appliance platform supports a dedicated management interface, you can also enable the management interface for management traffic only.

CCNP Security Question of the Week Series

ICMP Error Inspection on the ASA

Doug McKillip — Mon, 21 Nov 2011 13:48:32 +0000

The official Cisco CCNP Security FIREWALL training course (as well as other documentation) recommends enabling the inspection of the Internet Control Message Protocol (ICMP), even though it’s disabled by default. The image below displays the recommended practice as configured in ASDM, but the curious student might wonder what the unchecked “ICMP Error” box is. That’s what I’ll focus on in this post.

The ICMP existed for more than 30 years, having largely been specified in RFC792. Most network engineers are familiar with its diagnostic capabilities via ping and the assorted “unreachable” messages. What’s most likely not as well recognized is that the ICMP message often contains the first 28 bytes of the packet that caused the error. Since the IP header itself is frequently limited to 20 bytes, this ensures that the source and destination addresses will be seen since these are at the end of the header. An excellent graphic of the ICMP error message can be seen below.

With the embedding of IP addresses in this return packet in mind, a network admin is presented with an interesting diagnostic challenge. If the “packet that caused the error” (as often stated in the return message) was translated by a Network Address Translation (NAT) device between its point of origin and the point of error, then the reported source address needs to correlate to the current NAT device translation table — a bothersome task at best.

Cisco Systems provided NAT support for such a scenario in the PIX Operating System version 6.3 with the fixup protocol ICMP error command. As the Configuration Guide for this operating system suggests, the recognition of NAT-relevant IP addresses in diagnostic return messages was implemented before the general inspection capability for ICMP packets introduced in ASA/PIX OS7.0. In addition, the syntax changed with this release to “deprecate” (Cisco lingo for obsolete) the fixup command and replace it with the more general inspect.

One of the implied fringe benefits of the switchover to the inspect syntax is to use this as part of the overall Modular Policy Framework capability of OS7.0 and beyond. A network administrator could configure the ASA for the inspection of ICMP error packets to occur only for specific flows (from the out-of-band IT management network, for example). This would avoid a potentially unnecessary saturation of the NAT table.

CCNP Security Question of the Week

Dawn Hopper — Thu, 17 Nov 2011 18:29:02 +0000

Which ASA feature can be used to automatically prevent the spoofing of internal source addresses from outside networks?

ACLs
uRPF
AIP-SSM
Shunning

The answer is 2.

Specifying Cisco ASA adaptive security appliance per-interface access rules to protect against source-spoofed packets can be a labor-intensive task. As the adaptive security appliance can refer to its routing table to determine which networks are reachable through which interface, it can also use its routing table to validate source addresses of incoming packets. The technique is called Unicast Reverse Path Forwarding (uRPF), and the Cisco ASA adaptive security appliance supports the strict uRPF usage, where packets must arrive over the correct interface in order to be accepted.

CCNP Security Question of the Week Series

Benefit from Using Failover MAC Address

Doug McKillip — Fri, 04 Nov 2011 12:18:15 +0000

In this post I’ll focus on a topic that’s mentioned in the Cisco FIREWALL training class but isn’t emphasized there or in the online Cisco ASA documentation. When configuring failover on a pair of ASA security appliances, a situation can arise in which network disruption occurs due to the secondary ASA in a failover pair becoming active first and then the primary comes online second. Both the documentation and the courseware point out that this causes the secondary (and active ASA) to swap its interface MAC addresses with those of the primary. Being naturally skeptical about this behavior, I decided to investigate. The rest of this post illustrates my confirmation of this phenomenon.

Using a pair of configured ASA 5520 security appliances, I deliberately powered off the primary ASA and rebooted the secondary ASA. As shown below, the secondary ASA was configured to display its hostname, designation (primary or secondary), and role (active or standby). Not surprisingly, as the only powered-on ASA, it became active with the following MAC addresses (superfluous output has been omitted here):

ASA/sec/act(config)# show int
Interface GigabitEthernet0/0 “outside”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.e054, MTU 1500
IP address 200.200.1.2, subnet mask 255.255.255.0

Interface GigabitEthernet0/1 “inside”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.e055, MTU 1500
IP address 10.10.0.1, subnet mask 255.255.255.0

Interface GigabitEthernet0/2 “dmz”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.e056, MTU 1500
IP address 172.16.1.1, subnet mask 255.255.255.0

Interface GigabitEthernet0/3 “lanfail”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.e057, MTU 1500
IP address 192.168.25.4, subnet mask 255.255.255.0

The output below shows what happened after the primary ASA was powered up:

ASA/sec/act(config)# show int
Interface GigabitEthernet0/0 “outside”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.df18, MTU 1500
IP address 200.200.1.2, subnet mask 255.255.255.0

Interface GigabitEthernet0/1 “inside”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.df19, MTU 1500
IP address 10.10.0.1, subnet mask 255.255.255.0

Interface GigabitEthernet0/2 “dmz”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.df1a, MTU 1500
IP address 172.16.1.1, subnet mask 255.255.255.0

Interface GigabitEthernet0/3 “lanfail”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

MAC address 0019.5517.e057, MTU 1500
IP address 192.168.25.4, subnet mask 255.255.255.0

As you can see, the MAC addresses for each of the three traffic passing interfaces changed, but the IP addresses didn’t. This could clearly cause problems with the ARP (Address Resolution Protocol) caches of neighboring devices. To prevent this infrequently observed scenario (or “corner case”), a simple fix is to statically configure a MAC address pair for each traffic passing interface using the actual “burned in” addresses for each ASA. You can do this using either the CLI or the ASDM GUI.

CCNP Security Question of the Week

Dawn Hopper — Thu, 03 Nov 2011 17:25:04 +0000

On which operating systems is ASDM supported? Choose 3.

Windows
Linux
Mac OS X
Solaris

The answers are 1, 2, and 3.

ASDM is supported on Windows, Linux and Mac OS X.