Firewall

Here are the individual steps in detail:
1. Packet is reached at the ingress interface.

2. Once the packet reaches the internal buffer of the interface, the input counter of the interface is
incremented by one.
3. Cisco ASA will first verify if this is an existing connection by looking at its internal connection table
details. If the packet flow matches an existing connection, then the access-control list (ACL) check is
bypassed, and the packet is moved forward.
If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or
UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check.
If it is not a SYN packet, the packet is dropped and the event is logged.
4.) The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL
entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and
the information is logged. The ACL hit count will be incremented by one when the packet matches the
ACL entry.
5.) The packet is verified for the translation rules. If a packet passes through this check, then a
connection entry is created for this flow, and the packet moves forward. Otherwise, the packet is dropped
and the information is logged.
6.)The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific
packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects
each connection as per its pre-defined set of application-level functionalities. If it passed the inspection, it
is moved forward. Otherwise, the packet is dropped and the information is logged.
Additional Security-Checks will be implemented if a CSC module is involved.
7)The IP header information is translated as per the NAT/PAT rule and checksums are updated
accordingly. The packet is forwarded to AIP-SSM for IPS related security checks, when the AIP module
is involved.
8.)The packet is forwarded to the egress interface based on the translation rules. If no egress interface is
specified in the translation rule, then the destination interface is decided based on global route lookup.
9.)On the egress interface, the interface route lookup is performed. Remember, the egress interface is
determined by the translation rule that will take the priority.
10.)Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed.
Layer 2 rewrite of MAC header happens at this stage.
11)The packet is transmitted on wire, and Interface counters increment on the egress interface.
Capture Command at ASA

ciscoasa(config)#access-list inside_test permit ip 10.91.101.0 255.255.255.0 host 172.17.181.100 any
ciscoasa(config)#access-list inside_test permit ip host 172.17.181.100 any 10.91.101.0 255.255.255.0
ciscoasa(config)#capture inside_interface access-list inside_test interface outside
ciscoasa#show capture inside_interface
What is TCP/IP?
TCP/IP is the communication protocol for communication between computers on the Internet.
TCP/IP stands for Transmission Control Protocol / Internet Protocol.
TCP/IP defines how electronic devices (like computers) should be connected to the Internet, and how data
should be transmitted between them.
Inside TCP/IP
Inside the TCP/IP standard there are several protocols for handling data communication:
TCP (Transmission Control Protocol) communication between applications

UDP (User Datagram Protocol) simple communication between applications
IP (Internet Protocol) communication between computers
ICMP (Internet Control Message Protocol) for errors and statistics
DHCP (Dynamic Host Configuration Protocol) for dynamic addressing
TCP Uses a Fixed Connection

TCP is for communication between applications. If one application wants to communicate with another via TCP, it
sends a communication request. This request must be sent to an exact address. After a "handshake" between the two
applications, TCP will set up a "full-duplex" communication between the two applications.
The "full-duplex" communication will occupy the communication line between the two computers until it is closed
by one of the two applications.
UDP is very similar to TCP, but simpler and less reliable.
IP is Connection-Less
IP is for communication between computers.

IP is a "connection-less" communication protocol.
IP does not occupy the communication line between two computers. IP reduces the need for network lines.
Each line can be used for communication between many different computers at the same time.
With IP, messages (or other data) are broken up into small independent "packets" and sent between
computers via the Internet.
IP is responsible for "routing" each packet to the correct destination.
IP Routers
When an IP packet is sent from a computer, it arrives at an IP router.
The IP router is responsible for "routing" the packet to the correct destination, directly or via another router.
The path the packet will follow might be different from other packets of the same communication. The router is
responsible for the right addressing, depending on traffic volume, errors in the network, or other parameters.
Connection-Less Analogy
Communicating via IP is like sending a long letter as a large number of small postcards, each finding its own (often
different) way to the receiver.
TCP/IP
TCP/IP is TCP and IP working together.

TCP takes care of the communication between your application software (i.e. your browser) and your
network software.
IP takes care of the communication with other computers.
TCP is responsible for breaking data down into IP packets before they are sent, and for assembling the
packets when they arrive.
IP is responsible for sending the packets to the correct destination.
Name two network commands which uses ICMP at the network layer
Ping and Tracert
Which port number does ICMP use
ICMP does not use any port number as it does not use any transport layer protocols.
Which port does TFTP server works on
UDP port 69
Is TFTP a secure protocol
TFTP does not encrypt nor authenticate. It is not a secure protocol.

Which port does a DNS Server Use
UDP port 53
Name two fields which are available in TCP header but not in UDP header
Sequence and acknowledgement number.
Does UDP based applications have port numbers
UDP has source and destination port numbers available in the header.
Name one application which uses UDP on the internet
DNS
How does a UDP based application know that a packet has been lost in transit
UDP based applications uses a time out mechanism. They would wait for a specific time and then triggers a timeout
if the response has not been received.
Does ARP contain an IP header
ARP is a layer 2 protocol. It does not use IP header
Which feature can be used on a router to create back up links for path to the same networks
Floating static route
If a computer has two internet connections, one through the LAN and the other through a wireless USB card,
which would it take for sending the packets to the internet
It would take the connection with the lower metric value
C:\Documents and Settings\tabrez.ahmad>nbtstat -a 57.5.196.222
57 network:
Node IpAddress: [57.5.196.222] Scope Id: []
NetBIOS Remote Machine Name Table

Name
Type
Status
--------------------------------------------2159A-H7-SITA <00> UNIQUE
Registered
2159A-H7-SITA <20> UNIQUE
Registered
INNIIT-TECH
<00> GROUP
Registered
INNIIT-TECH
<1E> GROUP
Registered
MAC Address = 00-1A-A0-C2-9B-01
pdel1347#sh ip accounting
Source Destination Packets Bytes
57.5.209.56 57.5.178.180 3358 3811507 <<<< 3.6mb
57.5.208.217 57.5.178.79 67413 3070463 <<<< 2.9mb
57.5.209.13 57.5.178.180 3957 3017559
57.5.208.224 57.5.179.12 4815 2176410
57.5.209.22 57.5.178.79 46225 2073058
57.5.209.25 57.5.178.79 48522 2047308
How to Force a Manual Failover on a Cisco ASA via Command Line
Forcing a manual failover via command line can be done in two different ways.
######################################
On the active firewall you can do the following:
CiscoASA# no failover active
On the standby firewall you can do the following:
CiscoASA# failover active
Personally I prefer force the failover from the standby unit.
Active/Standby Failover in Single Mode

In the first deployment scenario, SecureMe, Inc. is looking to implement failover at its Chicago location. It has
purchased two Cisco ASA 5540 Cisco ASA for this purpose. The company requires implementation of the stateful
failover feature to ensure that all the active connections (excluding the HTTP connections) are replicated to the
standby unit in case there is a failure on the primary unit. Additionally, SecureMe requires the standby Cisco ASA
to become active if the primary Cisco ASA does not acknowledge the keepalive packets for 3 seconds. Figure
11-4 illustrates a proposed design for Active/Standby failover.
Figure 11-4. Deployment Scenario Using Active/Standby Failover
Example 11-29 shows relevant configuration of the primary Cisco ASA and the bootstrap configuration of the
secondary Cisco ASA. The primary Cisco ASA, being the active unit, synchronizes the entire running configuration
to the secondary Cisco ASA. The connection and translation tables are constantly replicated to the secondary Cisco
ASA over a dedicated interface.
Example 11-29. Cisco ASA Full Configuration Using Active/Standby Failover
Configuration of Primary Cisco ASA
Chicago# show run

!outside interface with security level set to 0. The system IP address is
! 209.165.200.225 and the Standby IP address is 209.165.200.226
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 209.165.200.225 255.255.255.224 standby 209.165.200.226
!inside interface with security level set to 100. The system IP address is
! 192.168.10.1 and the Standby IP address is 192.168.10.2
nameif inside
security-level 100
ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
! Interface used as a failover control interface
description LAN Failover Interface
! Interface used as a Stateful link
description STATE Failover Interface
<snip>
! Failover is enabled and the unit is acting as a Primary device

failover
failover lan unit primary
! Failover control interface is GigabitEthernet0/2
failover lan interface FOCtrlIntf GigabitEthernet0/2
! Cisco ASA will send periodic hellos every 500 milliseconds, and initiate a
! failover if hellos are not acknowledged for 3 seconds
failover polltime unit msec 500 holdtime 3
! Failover key to encrypt the control messages. This keys will be X'ed out
! in the configuration
failover key cisco123
! Stateful interface
failover link statefullink GigabitEthernet0/3
! IP address assignment on the failover control interface
failover interface ip FOCtrlIntf 10.10.10.1 255.255.255.252 standby 10.10.10.2
! IP address assignment on the stateful failover interface
failover interface ip statefullink 10.10.10.5 255.255.255.252 standby 10.10.10.6
! interfaces to be monitored for failover
monitor-interface outside
monitor-interface inside
! Address translation for the inside hosts to get Internet Access
global (outside) 1 interface
nat (inside) 1 192.168.10.0 255.255.255.0
<snip>
______________________________________________________________________________
Configuration of Secondary Cisco ASA
! The unit is acting as a Secondary device
failover lan unit secondary

! Failover control interface is GigabitEthernet0/2
failover lan interface FOCtrlIntf GigabitEthernet0/2
! Failover key to encrypt the control messages. This keys will be X'ed out in the
configuration
failover key cisco123
! IP address assignment on the failover control interface
failover interface ip FOCtrlIntf 10.10.10.1 255.255.255.252 standby 10.10.10.2
! Failover is enabled
failover
Monitoring and Troubleshooting Failovers

The Cisco ASA has a rich set of show and debug commands that are useful to monitor the status of the standby
Cisco ASA. These commands are particularly important in isolating a problem if something behaves unexpectedly.
The necessary show and debug commands that are used to manage Active/Standby and Active/Active failover in
the Cisco ASA are discussed in this section. Deployment Scenario 1 is used for references in this section.
Monitoring
Once the primary Cisco ASA is configured for failover, the first thing to check is to verify that the Cisco ASA is
recognizing failover as enabled. The status of an Cisco ASA's failover can be checked by using the show failover
command, as shown in Example 11-31.
Example 11-31. Output of show failover to Check if Failover Is Enabled
Chicago(config)# show failover

Failover On
Failover unit Primary
Failover LAN Interface: FOCtrlIntf GigabitEthernet0/2 (up)
Unit Poll frequency 500 milliseconds, holdtime 3 seconds<snip>
After the secondary Cisco ASA is configured for bootstrap configuration, the primary Cisco ASA synchronizes the
running configuration to the secondary Cisco ASA, as shown in Example 11-32.
Example 11-32. Configuration Replication
Beginning configuration replication: Sending to mate.

End Configuration Replication to mate
The secondary Cisco ASA loads the running configuration and becomes standby to monitor the status of the primary
Cisco ASA. In Example 11-33, the secondary Cisco ASA is in standby with its current IP addresses set as the
standby addresses.
Example 11-33. Output of show ip
Chicago# show ip
System IP Addresses:
Interface
Name
IP address
Subnet mask
Method
GigabitEthernet0/0 outside
209.165.200.225 255.255.255.224 CONFIG
GigabitEthernet0/1 inside
192.168.10.1
255.255.255.0 CONFIG
GigabitEthernet0/2 FOCtrlIntf
10.10.10.1
255.255.255.252 CONFIG
GigabitEthernet0/3 statefullink
10.10.10.5
255.255.255.252 CONFIG
Current IP Addresses:
Interface
Name
IP address
Subnet mask
Method
GigabitEthernet0/0 outside
209.165.200.226 255.255.255.224 CONFIG
GigabitEthernet0/1 inside
192.168.10.2
255.255.255.0 CONFIG
GigabitEthernet0/2 FOCtrlIntf
10.10.10.2
255.255.255.252 CONFIG
GigabitEthernet0/3 statefullink
10.10.10.6
255.255.255.252 CONFIG
The failover or standby IP addresses can also be checked by using the show failover command. If stateful failover is
set up, show failover also displays the stateful failover statistics along with the number of updates it has received
and transmitted. Example 11-34 shows the output of show failover with the system and standby IP addresses and
information about stateful failover.
Example 11-34. Output of show failover in Active/Standby Deployment
Chicago# show failover

Failover On
Failover unit Secondary
Failover LAN Interface: FOCtrlIntf GigabitEthernet0/2 (up)
Unit Poll frequency 500 milliseconds, holdtime 3 seconds
Interface Poll frequency 3 seconds
Interface Policy 1
Monitored Interfaces 2 of 250 maximum
Last Failover at: 16:50:50 UTC Jul 13 2005
This host: Secondary - Standby Ready

Active time: 4903 (sec)
slot 0: ASA5520 hw/sw rev (1.0/7.0(1)5) status (Up Sys)
slot 1: ASA-SSM-10 hw/sw rev (1.0/5.0(2)S152.0) status (Up)
Interface outside (209.165.200.226): Normal
Interface inside (192.168.10.2): Normal
Other host: Primary - Active
slot 0: ASA5520 hw/sw rev (1.0/7.0(1)5) status (Up Sys)
slot 1: ASA-SSM-10 hw/sw rev (1.0/5.0(2)S152.0) status (Up)

Interface outside (209.165.200.225): Normal
Stateful Failover Logical Update Statistics
Link : statefullink GigabitEthernet0/3 (up)
Stateful Obj
xmit
xerr
rcv
rerr
General
7509
23239 0
sys cmd
4009
4009
up time
RPC services
0
0
0
0
TCP conn
55001
43023 0
UDP conn
3300
3205
ARP tbl
3500
Xlate_Timeout 0
VPN IKE upd
19230 0
0
14
13
VPN IPSEC upd 30
28
VPN CTCP upd
VPN SDI upd

VPN DHCP upd
0
0
0
0
0
0
Recv Q:
Max
0
Total
110826
0
0
0
0
Logical Update Queue Information

Cur
Xmit Q:
12417
Note
The xerr and rerr are transmit and receive errors that occur when Cisco ASA send stateful information to each other.
Stateful failover is best effort and there will be times when errors increment because of congestion and other
reasons.
Cisco PIX ASA failover troubleshooting Tips
* Type sh fail command to check if any configured interface is in waiting or failed state.
* Try to ping the interface IPs, both devices must be able to ping each other.
* Type sh run | inc fail to make sure the configuration is correct.
* If there is a switch between them, make sure the interfaces are on the right VLAN
* Try using another FE port on the switch if still an issue or change the network cable.
* Make sure port fast is enabled on the switch port and both trunking and channeling is disabled on those
ports.
* Type sh log | inc fail command to see if there are any failover related messages in the logs.
Q. Will IPSEC make firewalls obsolete (no longer In use / bekar) ?
A.IPSEC (IP SECurity) refers to a set of standards developed by the Internet Engineering Task Force (IETF). There
are many documents that collectively define what is known as ``IPSEC'' [4]. IPSEC solves two problems which
have plagued the IP protocol suite for years: host-to-host authentication (which will let hosts know that they're
talking to the hosts they think they are) and encryption (which will prevent attackers from being able to watch the
traffic going between machines).
Q. What is the difference between gateway and firewall?

A. A network gateway joins two networks together through a combination of hardware and software. A network
firewall guards a computer network against unauthorized incoming or outgoing access. Network firewalls may be
hardware devices or software programs. .... ...
Q. A traceout command work across the firewall? why?

A. Traceroute is based on ICMP type 30 under Windows and UDP under NIX; traceroute packets that would hit
the firewall should be dropped similarly any echo replay coming from inside the firewall should be restricted
outbound.
Q.Define the term DMZ as it pertains to network security, and name three different common network devices that
are typically found there?
A.Its easy to think of your network as the inside, and everything else as outside. However, weve got a third
area when it comes to firewalls - the DMZ.
From an IT standpoint, the DMZ is the part of our network that is exposed to outside networks. Its common to
find the following devices in a DMZ:
1.FTP server
2.Email server
3.E-commerce server
4.DNS servers
5.Web servers
Q.Identify the true statements in below

A.
1.Stateless packet filtering considers the TCP connection state.
2.Stateful packet filtering considers the TCP connection state.
3.Neither stateless nor stateful packet filtering monitor the TCP connection state.
4.Both stateless and stateful packet filtering monitor the TCP connection state, and keep a state table containing that
information.
Stateful packet filtering does monitor the connection state, and thats particularly important when it comes to
preventing TCP attacks. A stateful firewall will not only monitor the state of the TCP connection, but also the
sequence numbers. Stateful firewalls accomplish this by keeping a session table, or state table.
Q.Does the Cisco IOS Firewall feature set act as a stateful or stateless packet filter?
A.The Cisco IOS Firewall is a stateful filter.
Q.What are considered parts of the IOS Firewall feature set?

A.
1.IOS Firewall
2.Intrusion Prevention System
4.Authentication Proxy
There are three major components to the IOS Firewall feature set - the IOS Firewall, the Intrusion Prevention
System (IPS), and the Authentication Proxy.
Q.What is Authentication Proxy.

A.
1.Its part of the IOS Firewall Feature Set.
2.It allows creation of per-user security profiles, rather than more general profiles.
3.Profiles can be stored on a RADIUS server.
4.Profiles can be stored on a TACACS+ server.
The Authentication Proxy allows us to create security profiles that will be applied on a per-user basis, rather than a
per-subnet or per-address basis. These profiles can be kept on either of the following:
1.RADIUS server
2.ACACS+ server
Upon successful authentication, that particular users security policy is downloaded from the RADIUS or
TACACS+ server and applied by the IOS Firewall router.
Q. Configuring ACLs is an important part of working with the IOS Firewall. What wildcard masks are
replaced in ACLs by the words host and any?
We have the option of using the word host to represent a wildcard mask of 0.0.0.0.
Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied.
The following ACLs both do that.
A.
R3#conf t
R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)#access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255. Both of the following lines permit
all traffic.
R3(config)#access-list 15 permit any
R3(config)#access-list 15 permit 0.0.0.0 255.255.255.255
Theres no right or wrong decision to make when youre configuring ACLs in the real world. For your exam,
though, Id be very familiar with the proper use of host and any.
Firewall Services Module (FWSM) is a firewall module integrated by Cisco into its Catalyst 6500 Switches and
7600 Series Routers.
Installed inside a Cisco Catalyst 6500 Series Switch or Cisco 7600 Internet Router, the FWSM allows any VLAN on
the switch to be passed through to the device to operate as a firewall port and integrates firewall security inside the
network infrastructure.
The FWSM is based on Cisco PIX technology and uses the same Cisco PIX Operating System, a secure, real-time
operating system. The Cisco FWSM enables organizations to manage multiple firewalls from the same management
platform.
Question: What command will show you if packets are being dropped by one of the Inspection engines?
Answer: show service-policy
Question: What type of connection is not replicated by default when stateful failover is configured?
Answer: HTTP connections. Use optional failover replication http command to enable replication of HTTP connections.
What Triggers a Failover?

Power loss/reload (this includes crashes) on the Active firewall
SSM interface/module failure
The Standby becoming healthier than the Active firewall
What Triggers a Failover?
Two consecutive hello messages missed on any monitored interface forces the interface into testing mode.
Both units first verify the link status on the interface.
Next, both units execute the following tests Network activity test ARP test Broadcast ping test
The first test passed causes the interface on that unit to be marked healthy; only if all tests fail will the interface be
marked failed
ASA Syslog Level vs. Number of Messages
Show Nat
The show nat command displays information about the nat table of the firewall
TCP Connection Termination Reasons
If a TCP connection is built through the firewall, it will always have a teardown reason.
The TCP teardown syslog is logged at level six.
Question: What other command can one run to see the information provided by show service-policy flow in an ASA?
Answer: packet-tracer
Ip verify reverse-path command is used to stop ip spoofing.
In computer networking, an embryonic connection refers to a TCP connection which is in the process of being established
Introduction
This document provides troubleshooting ideas and suggestions for when you use the Cisco ASA 5500 Series
Adaptive Security Appliance (ASA) and the Cisco PIX 500 Series Security Appliance. More often than not, when
applications or network sources break or are not available, firewalls (PIX or ASA) tend to be a primary target and
blamed as the cause of outages. With some testing on the ASA or PIX, an administrator can determine whether or
not the ASA/PIX causes the problem.
Refer to PIX/ASA: Establish and Troubleshoot Connectivity through the Cisco Security Appliance in order to learn
more about the interface related troubleshooting on the Cisco security appliances.
Note: This document focuses on the ASA and PIX. Once troubleshooting is complete on the ASA or PIX, it is likely
that additional troubleshooting might be necessary with other devices (routers, switches, servers, and so forth).
Components Used
The information in this document is based on Cisco ASA 5510 with OS 7.2.1 and 8.3.
The information in this document was created from the devices in a specific lab environment. All of the devices
used in this document started with a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Related Products
This document can also be used with these hardware and software versions:
ASA and PIX OS 7.0, 7.1, 8.3, and later
Firewall Services Module (FWSM) 2.2, 2.3, and 3.1
Note: Specific commands and syntax can vary between software versions.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Background Information
The example assumes the ASA or PIX is in production. The ASA/PIX configuration can be relatively simple (only
50 lines of configuration) or complex (hundreds to thousands of configuration lines). Users (clients) or servers can
either be on a secure network (inside) or an unsecure network (DMZ or outside).
The ASA starts with this configuration. The configuration is intended to give the lab a reference point.
ASA Initial Configuration
ciscoasa#show running-config
: Saved
:
ASA Version 7.2(1)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Ethernet0/0
nameif outside
security-level 0
ip address 172.22.1.160 255.255.255.0
!
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
nameif dmz
security-level 50
ip address 10.1.1.1 255.255.255.0
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
access-list outside_acl extended permit tcp any host 172.22.1.254 eq
www
access-list inside_acl extended permit icmp 192.168.1.0
255.255.255.0 any
access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0
any eq www
access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0
any eq telnet
pager lines 24
mtu outside 1500
mtu inside 1500
mtu dmz 1500
no asdm history enable
arp timeout 14400
global (outside) 1 172.22.1.253
nat (inside) 1 192.168.1.0 255.255.255.0
!--- The above NAT statements are replaced by the following

statements
!--- for ASA 8.3 and later.
object network obj-192.168.1.0

subnet 192.168.1.0 255.255.255.0
nat (inside,outside) dynamic 172.22.1.253
static (inside,outside) 192.168.1.100 172.22.1.254 netmask

255.255.255.255
!--- The above Static NAT statement is replaced by the following
statements
!--- for ASA 8.3 and later.

host 172.22.1.254
nat (inside,outside) static 192.168.1.100
access-group outside_acl in interface outside
access-group inside_acl in interface inside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sipdisconnect 0:02:00
timeout uauth 0:05:00 absolute
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown
coldstart
telnet timeout 5
ssh timeout 5
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:d41d8cd98f00b204e9800998ecf8427e
: end
Problem
A user contacts the IT department and reports that application X no longer works. The incident escalates to the
ASA/PIX administrator. The administrator has little knowledge of this particular application. With the use of the
ASA/PIX, the administrator discovers what ports and protocols application X uses as well as what might be the
cause of the problem.
Solution
The ASA/PIX administrator needs to gather as much information from the user as possible. Helpful information
includes:
Source IP addressThis is typically the work station or computer of the user.

Destination IP addressThe server IP address that the user or application tries to connect.
Ports and protocols the application uses
Often the administrator is fortunate if able to get an answer to one of these questions. For this example, the
administrator is not able to gather any information. A review of ASA/PIX syslog messages is ideal but it is difficult
to locate the problem if the administrator does not know what to look for.
Step 1 - Discover the IP Address of the User
There are many ways to discover the IP address of the user. This document is about the ASA and PIX, so this
example uses the ASA and PIX to discover the IP address.
The user attempts to communicate to the ASA/PIX. This communication can be ICMP, Telnet, SSH, or HTTP. The
protocol chosen should have limited activity on the ASA/PIX. In this specific example, the user pings the inside
interface of the ASA.
The administrator needs to set up one or more of these options and then have the user ping the inside interface of the
ASA.
Syslog
Make sure logging is enabled. The logging level needs to be set to debug. Logging can be sent to various
locations. This example uses the ASA log buffer. You might need an external logging server in production
environments.
ciscoasa(config)#logging enable
ciscoasa(config)#logging buffered debugging
The user pings the inside interface of the ASA (ping 192.168.1.1). This output is displayed.
ciscoasa#show logging
!--- Output is suppressed.
%ASA-6-302020: Built ICMP connection for faddr 192.168.1.50/512

gaddr 192.168.1.1/0 laddr 192.168.1.1/0
%ASA-6-302021: Teardown ICMP connection for faddr 192.168.1.50/512
gaddr 192.168.1.1/0 laddr 192.168.1.1/0
!--- The user IP address is 192.168.1.50.
ASA Capture Feature

The administrator needs to create an access-list that defines what traffic the ASA needs to capture. After
the access-list is defined, the capture command incorporates the access-list and applies it to an interface.
ciscoasa(config)#access-list inside_test permit icmp any host 192.168.1.1

ciscoasa(config)#capture inside_interface access-list inside_test interface inside
The user pings the inside interface of the ASA (ping 192.168.1.1). This output is displayed.
1: 13:04:06.284897 192.168.1.50 > 192.168.1.1: icmp: echo request
Note: In order to download the capture file to a system such as ethereal, you can do it as this output shows.
!--- Open an Internet Explorer and browse with this https link format:
https://[<pix_ip>/<asa_ip>]/capture/<capture name>/pcap
Refer to ASA/PIX: Packet Capturing using CLI and ASDM Configuration Example in order to know more
about Packet Capturing in ASA.
Debug
The debug icmp trace command is used to capture the ICMP traffic of the user.
ciscoasa#debug icmp trace
The user pings the inside interface of the ASA (ping 192.168.1.1). This output is displayed on the console.
ciscoasa#
ICMP echo request from 192.168.1.50 to 192.168.1.1 ID=512 seq=5120 len=32

ICMP echo reply from 192.168.1.1 to 192.168.1.50 ID=512 seq=5120 len=32
In order to disable debug icmp trace, use one of these commands:

no debug icmp trace
undebug icmp trace

undebug all, Undebug all, or un all
Each of these three options helps the administrator to determine the source IP address. In this example, the source IP
address of the user is 192.168.1.50. The administrator is ready to learn more about application X and determine the
cause of the problem.
Step 2 - Locate the Cause of the Problem
With reference to the information listed in the Step 1 section of this document, the administrator now knows the
source of an application X session. The administrator is ready to learn more about application X and to begin to
locate where the issues might be.
The ASA/PIX administrator needs to prepare the ASA for at least one of these listed suggestions. Once the
administrator is ready, the user initiates application X and limits all other activity since additional user activity might
cause confusion or mislead the ASA/PIX administrator.
Monitor syslog messages.
Search for the source IP address of the user that you located in Step 1. The user initiates application X. The
ASA administrator issues the show logging command and views the output.
%ASA-7-609001: Built local-host inside:192.168.1.50

%ASA-6-305011: Built dynamic TCP translation from inside:192.168.1.50/1107
to outside:172.22.1.254/1025
%ASA-6-302013: Built outbound TCP connection 90 for outside:172.22.1.1/80
(172.22.1.1/80) to inside:192.168.1.50/1107 (172.22.1.254/1025)
The logs reveal that the destination IP address is 172.22.1.1, the protocol is TCP, the destination port is
HTTP/80, and that traffic is sent to the outside interface.
Modify the capture filters.
The access-list inside_test command was previously used and is used here.
ciscoasa(config)#access-list inside_test permit ip host 192.168.1.50 any
!--- This ACL line captures all traffic from 192.168.1.50

!--- that goes to or through the ASA.
ciscoasa(config)#access-list inside_test permit ip any host 192.168.1.50 any
!--- This ACL line captures all traffic that leaves

!--- the ASA and goes to 192.168.1.50.
ciscoasa(config)#no access-list inside_test permit icmp any host 192.168.1.1

ciscoasa(config)#clear capture inside_interface
!--- Clears the previously logged data.

!--- The no capture inside_interface removes/deletes the capture.
The user initiates application X. The ASA administrator then issues the show capture inside_interface
command and views the output.
ciscoasa(config)#show capture inside_interface
1: 15:59:42.749152 192.168.1.50.1107 > 172.22.1.1.80:
S 3820777746:3820777746(0) win 65535 <mss 1460,nop,nop,sackOK>
2: 15:59:45.659145 192.168.1.50.1107 > 172.22.1.1.80:
3: 15:59:51.668742 192.168.1.50.1107 > 172.22.1.1.80:
The captured traffic provides the administrator with several pieces of valuable information:
Destination address172.22.1.1
Port number80/http
ProtocolTCP (notice the "S" or syn flag)
In addition, the administrator also knows that the data traffic for application X does arrive at the ASA.
If the output had been this show capture inside_interface command output, then the application traffic
either never reached the ASA or the capture filter was not set to capture the traffic:
0 packet captured
0 packet shown
In this case, the administrator should consider investigating the user's computer and any router or other
network devices in the path between the user computer and the ASA.
Note: When traffic arrives at an interface, the capture command records the data before any ASA security
policies analyze the traffic. For example, an access-list denies all incoming traffic on an interface. The
capture command still records the traffic. The ASA security policy then analyzes the traffic.
Debug
The administrator is not familiar with application X and therefore does not know which of the debug
services to enable for application X investigation. Debug might not be the best troubleshooting option at
this point.
With the information collected in Step 2, the ASA administrator gains several bits of valuable information. The
administrator knows the traffic arrives at the inside interface of the ASA, source IP address, destination IP address
and the service application X uses (TCP/80). From the syslogs, the administrator also knows that the communication
was initially permitted.
Step 3 - Confirm and Monitor Application Traffic
The ASA administrator wants to confirm that application X traffic has left the ASA as well as monitor any return
traffic from the application X server.
Monitor syslog messages.
Filter syslog messages for the source IP address (192.168.1.50) or the destination IP address (172.22.1.1).
From the command line, filtering syslog messages look like show logging | include 192.168.1.50 or show
logging | include 172.22.1.1. In this example, the show logging command is used without filters. The
output is suppressed in order to make reading easy.
%ASA-7-609001: Built local-host inside:192.168.1.50

%ASA-7-609001: Built local-host outside:172.22.1.1
%ASA-6-305011: Built dynamic TCP translation from inside:192.168.1.50/1107
to outside:172.22.1.254/1025
%ASA-6-302013: Built outbound TCP connection 90 for outside:172.22.1.1/80
(172.22.1.1/80) to inside:192.168.1.50/1107 (172.22.1.254/1025)
%ASA-6-302014: Teardown TCP connection 90 for outside:172.22.1.1/80
to inside:192.168.1.50/1107 duration 0:00:30 bytes 0 SYN Timeout
%ASA-7-609002: Teardown local-host outside:172.22.1.1 duration 0:00:30
%ASA-6-305012: Teardown dynamic TCP translation from inside:192.168.1.50/1107
to outside:172.22.1.254/1025 duration 0:01:00
%ASA-7-609002: Teardown local-host inside:192.168.1.50 duration 0:01:00
The syslog message indicates the connection closed because the of SYN timeout. This tells the
administrator that no application X server responses were received by the ASA. Syslog message
termination reasons can vary.
The SYN timeout gets logged because of a forced connection termination after 30 seconds that occurs after
the three-way handshake completion. This issue usually occurs if the server fails to respond to a connection
request, and, in most cases, is not related to the configuration on PIX/ASA.
In order to resolve this issue, refer to this checklist:
1.
Make sure the static command is entered correctly and that it does not overlap with other static commands,
for example,
static (inside,outside) x.x.x.x y.y.y.y netmask 255.255.255.255
The static NAT in ASA 8.3 and later can be configured as shown here:
object network obj-y.y.y.y
host y.y.y.y
nat (inside,outside) static x.x.x.x
2.
Make sure that an access list exists in order to permit access to the global IP address from the outside and
that it is bound to the interface:
access-list OUTSIDE_IN extended permit tcp any host x.x.x.x eq www
access-group OUTSIDE_IN in interface outside
3.
For a successful connection with the server, the default gateway on the server must point towards the DMZ
interface of PIX/ASA.
Refer to ASA System Messages for more information on the syslog messages.
Create a new capture filter.

From earlier captured traffic and syslog messages, the administrator knows that application X should leave
the ASA through the outside interface.
ciscoasa(config)#access-list outside_test permit tcp any host 172.22.1.1 eq 80
!--- When you leave the source as 'any', it allows

!--- the administrator to monitor any network address translation (NAT).
ciscoasa(config)#access-list outside_test permit tcp host 172.22.1.1 eq 80 any
!--- When you reverse the source and destination information,

!--- it allows return traffic to be captured.
ciscoasa(config)#capture outside_interface access-list outside_test interface outside

The user needs to initiate a new session with application X. After the user has initiated a new application X
session, the ASA administrator needs to issue the show capture outside_interface command on the ASA.
ciscoasa(config)#show capture outside_interface
3 packets captured
1: 16:15:34.278870 172.22.1.254.1026 > 172.22.1.1.80:
2: 16:15:44.969630 172.22.1.254.1027 > 172.22.1.1.80:
3: 16:15:47.898619 172.22.1.254.1027 > 172.22.1.1.80:
3 packets shown
The capture shows traffic leaving the outside interface but does not show any reply traffic from the
172.22.1.1 server. This capture shows the data as it leaves the ASA.
Use the packet-tracer option.
From previous sections, the ASA administrator has learned enough information to use the packet-tracer
option in the ASA.
Note: The ASA supports the packet-tracer command starting in version 7.2.
ciscoasa#packet-tracer input inside tcp 192.168.1.50 1025 172.22.1.1 http
!--- This line indicates a source port of 1025. If the source

!--- port is not known, any number can be used.
!--- More common source ports typically range
!--- between 1025 and 65535.
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
MAC Access list
Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Found no matching flow, creating a new flow
Phase: 4
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
in 172.22.1.0
Phase: 5
255.255.255.0 outside
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_acl in interface inside
access-list inside_acl extended permit tcp 192.168.1.0 255.255.255.0 any eq www
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Phase: 7
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 192.168.1.0 255.255.255.0
match ip inside 192.168.1.0 255.255.255.0 outside any

dynamic translation to pool 1 (172.22.1.254)
translate_hits = 6, untranslate_hits = 0
Dynamic translate 192.168.1.50/1025 to 172.22.1.254/1028
using netmask 255.255.255.255
Phase: 9
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 192.168.1.0 255.255.255.0
match ip inside 192.168.1.0 255.255.255.0 outside any
dynamic translation to pool 1 (172.22.1.254)
translate_hits = 6, untranslate_hits = 0
Phase: 10
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Phase: 11
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Phase: 13
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Phase: 14
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
New flow created with id 94, packet dispatched to next module
Phase: 15
Type: ROUTE-LOOKUP
Subtype: output and adjacency

Result: ALLOW
Config:
found next-hop 172.22.1.1 using egress ifc outside
adjacency Active
next-hop mac address 0030.a377.f854 hits 11
!--- The MAC address is at Layer 2 of the OSI model.

!--- This tells the administrator the next host
!--- that should receive the data packet.
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
The most important output of the packet-tracer command is the last line, which is Action: allow.
The three options in Step 3 each show the administrator that the ASA is not responsible for the application X issues.
The application X traffic leaves the ASA and the ASA does not receive a reply from the application X server.
What is Next?
There are many components that allow application X to work correctly for users. The components include the user's
computer, the application X client, routing, access policies, and the application X server. In the previous example,
we proved that the ASA receives and forwards the application X traffic. The server and application X administrators
should now get involved. Administrators should verify that the application services are running, review any logs on
the server, and verify that the user's traffic is received by the server and application X.
Problem: Terminating TCP-Proxy Connection Error Message
You receive this error message:
%PIX|ASA-5-507001: Terminating TCP-Proxy connection from

interface_inside:source_address/source_port to interface_outside:dest_address/dest_port reassembly limit of limit bytes exceeded
Solution
Explanation: This message displays when the reassembly buffer limit is exceeded during assembling TCP
segments.
source_address/source_port - The source IP address and the source port of the packet initiating the connection.
dest_address/dest_port - The destination IP address and the destination port of the packet initiating the
connection.
interface_inside - The name of the interface on which the packet which initiated the connection arrives.
interface_outside - The name of the interface on which the packet which initiated the connection exits.
limit - The configured embryonic connection limit for the traffic class.
The resolution for this issue is to disable the RTSP inspection in the security appliance as shown.
class inspection_default
inspect dns migrated_dns_map_1
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
no inspect rtsp
Refer to Cisco bug ID CSCsl15229 (registered customers only) for more details.
Problem: "%ASA-6-110003: Routing failed to locate next-hop for protocol from src interface" Error
Message
ASA drops traffic with the error:%ASA-6-110003: Routing failed to locate next-hop for protocol from src
interface:src IP/src port to dest interface:dest IP/dest port error message.
Solution
This error occurs when the ASA tries to find the next hop on an interface routing table. Typically, this message is
received when ASA has a translation (xlate) built to one interface and a route pointing out a different interface.
Check for a misconfiguration on the NAT statements. Resolution of the misconfiguration may resolve the error.
Problem: Connection Blocked by ASA with the " %ASA-5-305013: Asymmetric NAT rules matched for
forward and reverse flows" Error Message
The connection is blocked by ASA, and this error message is received:
%ASA-5-305013: Asymmetric NAT rules matched for forward
and reverse flows; Connection protocol src
interface_name:source_address/source_port dest
interface_name:dest_address/dest_port denied due to NAT reverse path
failure.
Solution
When the NAT is performed, ASA also tries to reverse the packet and checks if this hits any translation. If it does
not hit any or a different NAT translation, then there is a mismatch. You most commonly see this error message
when there are different NAT rules configured for outbound and incoming traffic with same source and destination.
Check the NAT statement for the concerned traffic.
Problem: Receive error - %ASA-5-321001: Resource 'conns' limit of 10000 reached for system
Solution
This error signifies that the connections for a server located across an ASA have reached their maximum limit. This
could be an indication of a DoS attack to a server in your network. Use MPF on the ASA and reduce the embryonic
connections limit. Also, enable Dead Connection Detection (DCD). Refer to this configuration snippet:
class-map limit
match access-list limit
!
class limit
set connection embryonic-conn-max 50
set connection timeout embryonic 0:00:10 dcd
!
access-list limit line 1 extended permit tcp any host x.x.x.x
Problem: Receive error %PIX-1-106021: Deny TCP/UDP reverse path check from src_addr to dest_addr on
interface int_name
Solution
This log message is received when the reverse path check is enabled. Issue this command in order to resolve the
problem and disable the reverse path check:
no ip verify reverse-path interface <interface name>
Problem: Interruption of Internet Connectivity due to Threat Detection

This error message is received on the ASA:
%ASA-4-733100: [Miralix Licen 3000] drop rate-1 exceeded. Current burst
rate is 100 per second, max configured rate is 10; Current average rate is 4
per second, max configured rate is 5; Cumulative total count is 2526

Solution
This message is generated by threat detection due to the default configuration when an anomalous traffic behavior is
detected. The message focuses on Miralix Licen 3000 which is a TCP/UDP port. Locate the device which is using
port 3000. Check on the ASDM graphical statistics for threat detection and verify the top attacks to see if it shows
port 3000 and the source IP address. If it is a legitimate device, you can increment the basic threat detection rate on
ASA in order to resolve this error message.
Port
Application
21,20
FTP (File Transfer Protocol)
22
SSH (Secure Shell)
23
Telnet
25
SMTP ( Simple Mail Transfer Protocol)
42
Wins Replication Portt
43
Whois Port :- Port used for whois request (For the retrieval fo domain name information) to
whois servers
53
DNS (This port is used by client and servers when exchanging domain name information and
routing (DNS= Domain Name Server)
67
DHCP Port for dhcp request and replies
80
HTTP port for Internet Traffic
110
POP3 This is a port normally called the incoming mail port in email programs
115
Secure FTP Port used for ftp file transfers and modifications over a secure shell connections
(SSH)
119
News group port :- Port used for newsgroup access
123
Network Time Protocol (NTP):- Port used for checking and syncronizing time with another
computer (Time Server)
137
Netbios name service port :- This port used by the netbios protocol to find other computers
on a workgroup network
143
IMAP4 ( Internet Message Access Protocol)
161
SNMP(Simple Network Management Protocol): UDP port used to manage configure and
gather information about network devices like routers firewall etc
179
BGP (Border Gateway Protocol). It is a routing protocol used to exchange routing

information between routers in autonomous networks
379
Site Replication Services :- TCP Port used by microsoft site replication services
389
LDAP:- TCP port used to find and manage network resources on an hierarchical network
systems like Microsoft active directory service domain
443
Secure HTTP:-
465
Google mail outgoing mail server
636
LDAP over SSL
993
Secure Internet message access protocol (SIMAP 4)
995
Google incoming mail server
1533
Sametime server
1352
Lotus notes mail access
3389
Remote Desktop port and Terminal services port
Introduction
This guide has been prepared for Medco Health to help them troubleshoot PIX Firewall issues in their network. The
document is broken down into three main sections: Connection Issues (User A cannot talk to Server B through the
PIX), Performance Issues (Slow connectivity through the PIX), and Failover Issues. I hope you find it useful.
The show conn Command
When troubleshooting connection issues through the PIX (you can't get to a web site, or you can't telnet to a device),
it is most helpful to examine the status of the connection through the PIX. Since the PIX is a "stateful" firewall, it
must see the complete 3-way handshake (SYN, SYN+ACK, ACK) - in order - before the connection is considered
"up". Many times the PIX will receive the SYN packet, and maybe even the SYN+ACK packet, but not the final
ACK. When this occurs, the connection is considered to be in the embryonic state, and data will not flow until the
connection completes and moves out of the embryonic state.
The easiest way to view the connections - and their state - on the PIX is to issue the command show conn. The
show conn command will display all the active connections through the PIX, along with the state the connection is
in. The connection's state is represented by the "flags" field. The "flags" field is displayed at the very end of the
connection line. See example below.
Example: show conn
TCP out 199.244.222.174:62112 in 54.26.166.67:4092 idle 0:02:01 Bytes 6563 flags UIOB
One can also use modifiers to the show conn command to limit the output. Most frequently, one will want to find
all the connections from a given source IP address. If the source address is on the outside use the foreign modifier.
If the source address is on the inside, use the local modifier. Below is the command syntax for the show conn
command.
usage: show conn [count] | [protocol <tcp|udp>] [foreign|local <ip1[-ip2]> [netmask <mask>]]
[lport|fport <port1[-port2>] [state
<up[,finin][,finout][,http_get][,smtp_data][,data_in][,data_out][,...]>]
For further information on the show conn command see the PIX 5.3 Command Reference.
Connection Flags
+------+-------------------------------------------------------+
| Flag | Description
|
+------+-------------------------------------------------------+
| U | up
|
| f | inside FIN
|
| F | outside FIN
|
| r | inside acknowledged FIN
|
| R | outside acknowledged FIN
|
| s | awaiting outside SYN
|
| S | awaiting inside SYN
|
| M | SMTP data
|
| I | inbound data
|
| O | outbound data
|
| q | SQL*Net data
|
| d | dump
|
| P | inside back connection
|
| E | outside back connection

|
| G | group
|
| a | awaiting outside ACK to SYN
|
| A | awaiting inside ACK to SYN
|
| B | initial SYN from outside
|
| R | RPC
|
| H | H.323
|
| D | DNS
|
+--------------------------------------------------------------+ Definition: "inside back connection" - The secondary
data connection must come
from the inside host. For instance with the FTP protocol, after the inside client
issues the PORT command and the outside server accepted, the PIX will pre-allocate a back connection with this
flag set.
If the *outside* server attempts to connect back to the PIX, then the PIX will deny this session. Only the *inside*
client can use this back connection.
Example: Connection through the PIX
Below is a sample table that shows what the Connection Flag field will show for a given state of a TCP connection.
In line 1, the PIX receives an initial SYN packet from the Inside. The SYN is permitted by the access-list, a
translation (xlate) is built up, and the connection is also created with the flags "saA". In line 2, the Outside device
responds to the SYN packet with a SYN+ACK. The connection flags are updated to reflect this, and the flags now
show "A". In line 3, the Inside device responds to the SYN+ACK with an ACK and this completes the TCP 3-way
handshake, and the connection is now considered "up" (U flag). In line 4, the Outside device sends the first data
packet. The connection is updated and an "I" is added to the flags to indicate the PIX received Inbound data on that
connection. Finally, in line 5, the Inside device has sent a data packet and the connection is updated to include the
"O" flag.
Inside
Outside
Flags
+---+----------------------------+--------+
| 1 | SYN -->
| saA |
|2|
<-- SYN + ACK | A |
| 3 | ACK -->
| U |
|4|
<-- Data
| UI |
| 5 | Data -->
| UIO |
+---+-------------------------------------+
By using the example above, along with the Connection Flags table, one can determine the state of every connection
that is currently passing through the PIX.
For TCP connections that have already terminated, one can look in the syslogs and search for message ID 302002
(Teardown TCP connection). At the end of this message is the TCP termination reason. The table below lists the
possible reasons, along with their description.
Note: This syslog message is logged at level 6 (Informational), if you are logging at level 5 or lower, you will not
see this message.
Example: TCP connection termination

The following syslog indicates that host 172.16.1.92 on the Inside, sent a Reset packet to host
209.165.202.130 on the Outside, causing the connection to be torn down.
302002: Teardown TCP connection 968 faddr 209.165.202.130/80 gaddr 209.165.200.241/1988
laddr 172.16.1.92/1988 duration 0:00:01 bytes 231 (TCP Reset-I)
TCP Termination Reasons
+--------------+---------------------------------------------+
| Reason
| Description
|
+--------------+---------------------------------------------+
| Reset-I
| Reset was from the inside.
|
| Reset-O
| Reset was from the outside.
|
| TCP FINs | Normal close down sequence.
|
| FIN Timeout | Force termination after 15 seconds
|
|
| awaiting for last ack
|
| SYN Timeout | Force termination after 2 minutes awaiting |
|
| three way handshake completion.
|
| Xlate Clear | Command line removal
|
| Deny
| Terminate by application inspection.
|
| SYN Control | Back channel initiation from wrong side. |
| Uauth Deny | Deny by URL filter.
|
| Unknown
| Catch all error.
|
+--------------+---------------------------------------------+
The show conn count Command

The show conn count command shows the current and maximum numbers of connections through the PIX. A
connection is a mapping of Layer 4 information from an internal address to an external one. Connections are built
up when the PIX receives a SYN packet for TCP sessions, or the first packet in a UDP session arrives. Connections
are torn down when the PIX receives the FIN ACK packet in the TCP session, or when the timeout expires in the
UDP session. Extremely high connection counts (50-100 times normal) may indicate that you are under attack.
Issue the command show memory to make sure the high connection count is not causing the PIX to run out of
memory. If you find that you are under attack, you can limit the maximum number of connections per static entry
and also limit the maximum number of embryonic connections. This will protect your internal servers from being
overwhelmed. Please see the PIX Command Reference for further information.
Client-PIX# sho xlate count

8 in use, 13 most used
Client-PIX#
The show xlate count Command
The show xlate count command shows the current and maximum number of translations through the PIX. A
translation is a mapping of an internal address to an external address. It can be a one-to-one mapping (as is the case
with NAT) or a many-to-one mapping (as is the case with PAT). It is a subset of the command show xlate which
outputs each translation through the PIX.
Client-PIX# sho xlate

Global 167.211.241.8 Local 54.26.191.12
Global 167.211.241.18 Local 54.25.20.9
Global 167.211.241.10 Local 54.25.207.204
Global 167.211.241.19 Local 54.26.166.67
Global 167.211.241.14 Local 54.25.7.92
Global 54.26.96.131 Local 54.25.16.50
Global 167.211.241.20 Local 54.26.166.70
Client-PIX# sho xlate count
Client-PIX#
The show cpu usage Command
The show cpu usage command was first introduced in PIX OS 6.0(1). It is used to determine how much load the
PIX's CPU is under. During normal network conditions, it is recommended that the CPU load stay below 30%. But,
during peak traffic times, network surges, or attacks, one may see the CPU spike higher. If, during normal network
traffic load periods, the CPU stays above 30%, it is recommended that the PIX be upgraded to a more powerful one
to handle the network traffic load at that location.
The PIX has a single CPU which is used for everything from packet processing to printing out debug messages on
the console. Each process has its own purpose, and some need more CPU time to execute their function than
others. The process that is probably the most CPU intensive is Encryption. Therefore, if your PIX will be passing a
lot of traffic through encrypted tunnels, it might be a good idea to consider a faster PIX, a VPN Accelerator Card
(Part # PIX-VPN-ACCEL) for the PIX, or a dedicated VPN Concentrator (like the VPN 3000). The PIX's VPN
accelerator card offloads the encryption and decryption from the PIX's CPU and performs it in hardware on the
card. This allows the PIX to encrypt/decrypt 100 Mbps of traffic using 3DES (168 bit encryption).
PIX Device Manager (PDM) also provides a graph on the Monitoring tab that allows one to graph the CPU usage of
the PIX over time. This can be useful in determining the load on your PIX.
The show cpu usage command can be used to display CPU utilization statistics. Here is an example of the output:
Client-PIX# sho cpu usage
CPU utilization for 5 seconds = 0%; 1 minute: 0%; 5 minutes: 0%

Client-PIX#
The following table lists and describes the fields in the show cpu usage output:
Field
Description
CPU utilization for five

seconds
CPU utilization for the last five seconds.
one minute
Average of 5 second samples of CPU utilization over the last minute
five minutes
Average of 5 second samples of CPU utilization over the last five minutes
The show traffic Command

The show traffic command will show you how much traffic is passing through the PIX over a given period of time.
Its results are based upon the previous time the show traffic command was issued, so for accurate results it is
suggested that you first issue the clear traffic command and then wait one to three minutes and then issue the show
traffic command. Alternatively, you could issue the show traffic command, and then wait one to three minutes and
issue the show traffic command again. But only the output from the second instance would be valid (because the
results are based on difference between the current issuing of the command, and the previous issuing of it).
The show traffic command is useful when you are trying to determine how much traffic is passing through your
PIX. Or, if you have multiple interfaces, it helps to determine which interfaces are sending and receiving the most
data. For 2 interface PIXes, the sum of the inbound and outbound traffic on the Outside interface should equal the
sum of the inbound and outbound traffic on the Inside interface.
Example:
Client-PIX# sho traff
outside:
received (in 3716258.469 secs):
0 packets
0 bytes
0 pkts/sec
0 bytes/sec
transmitted (in 3716258.469 secs):

0 packets
0 bytes
0 pkts/sec
0 bytes/sec
inside:
26496476 packets
0 pkts/sec
3045395087 bytes
0 bytes/sec

7685374 packets 677935315 bytes
0 pkts/sec
0 bytes/sec
B2B:
7440766 packets 519398369 bytes
0 pkts/sec
1 bytes/sec

7965553 packets 2293422939 bytes
0 pkts/sec
1 bytes/sec
intf3:
301759 packets 28607868 bytes
0 pkts/sec
0 bytes/sec

0 pkts/sec
0 bytes/sec
Client-access:
18335582 packets
0 pkts/sec
701805637 bytes
0 bytes/sec

0 packets
0 bytes
0 pkts/sec
0 bytes/sec
PixState:
0 pkts/sec
1 bytes/sec

1644013 packets 998955972 bytes
0 pkts/sec
0 bytes/sec
Client-PIX#
If you are coming close - or reaching - the rated throughput on one of your interfaces, it is highly suggested that you
think about upgrading to a faster interface, or limit the amount of traffic going into or out of that interface. Failure
to do so will result in packets getting dropped. This is most observable by examining the interface counters. See
more information on this under the show interface command below.
The show blocks Command

The show blocks command, along with the show cpu usage command, are useful commands in determining
whether the PIX is being overloaded.
Packet Processing Blocks (1550 and 16384)
When a packet comes into a PIX's interface, it is placed on the input interface queue, and then it is passed up to the
OS and the PIX places it in a block. For Ethernet packets, the 1550 byte blocks are used (unless the packet comes in
on a 66 MHz Gigabit Ethernet card then the 16384 byte blocks are used). The PIX then determines whether the
packet should be permitted or denied based on the Adaptive Security Algorithm (ASA) and processes the packet
through to the output queue on the outbound interface. If the PIX is having trouble keeping up with the traffic load,
then one will see the CNT column for the 1550 byte blocks (or 16384 byte blocks for 66 MHz GE) hover close to
zero. When the CNT column hits zero, the PIX will attempt to allocate more blocks - up to a maximum of 8192. If
no more blocks are available, the PIX will drop the packet.
Failover and Syslog Blocks (256)

The 256 byte blocks are mainly used for Stateful failover messages. The Active PIX generates and sends packets to
the Standby PIX to update the translation and connection table. During periods of bursty traffic where high rates of
connections are created or torn down, the 256 byte blocks may go to zero. This indicates that one or more
connections were not updated to the Standby PIX. This is generally ok, because the stateful failover protocol will
catch the missing xlate or connection the next time around. If the CNT column for 256 bytes stays at or near zero
for extended periods of time, then the PIX is having trouble keeping the translation and connection tables synched
up. This is do to the number of connections per second that the PIX is processing. If you are seeing this
consistently, then you should look into upgrading the PIX to a faster model.
Syslog messages sent out from the PIX also use the 256 byte blocks, but they are generally not released in such
quantity to cause a depletion of the 256 byte block pool. However, if you are experiencing the CNT column of the
256 byte blocks hovering near zero check to make sure you are not logging at debugging level to the syslog server.
This is indicated by the logging trap line in the PIX config. It is recommended to log at Notification Level (level 5)
or lower, unless you require additional information for debugging purposes.
Client-PIX# show blocks

SIZE
MAX
LOW
CNT
1600
1560 1599
80
400
356
398
256
500
400
500
1550
2212 1252 1441
Client-PIX#
The following table lists and describes the columns in the show blocks command output:
Column
Description
SIZE
The Size, in Bytes, of that block pool.
MAX
The Maximum number of blocks available for that specific Byte block pool.
Note: The Maximum number of blocks are carved out of Memory at bootup.
Typically, the Maximum number of blocks does not change. The exception is
for the 256 and 1550 byte blocks, where the PIX can dynamically create more
when needed, up to a maximum of 8192.
LOW
The Low water mark. This is the lowest number of this size blocks available
since the PIX was powered up, or since the last clearing of the blocks "clear
blocks".
CNT
The Current number of blocks available for that specific size block pool.
The following table lists and describes the rows in the show blocks command output:
Size
4
Description
Used to duplicate existing blocks in DNS, isakmp, url-filtering, uauth, h323,
tftp, and TCP modules.

80
Used in TCP Intercept to generate an ACK packets, used for failover hello
messages.
256
Used for Stateful Failover updates, Syslogging, and other TCP functions.
1550
Used to store Ethernet packets for processing through the PIX.
16384
Only used for the 64-bit, 66 MHz Gigabit Ethernet cards (i82543) in the PIX
535.
The show memory Command

The show memory command displays the total physical memory (or RAM) the PIX has, along with the number of
bytes currently available. Before one can use this information for anything meaningful, one must first understand
what the memory is used for on the PIX. To start with, when the PIX boots, it copies the operating system from
Flash into RAM. Then the PIX will run the OS from RAM (just like the routers do). Next, the PIX copies the PIX's
startup configuration from Flash and also places it into RAM. Finally, the PIX will carve out RAM to create the
block pools we spoke about above. Once this is completed, the PIX is up and running. At this point, the only thing
the PIX uses additional RAM for is if the configuration increases in size it will use up more RAM. The second, and
probably most important thing that the PIX uses RAM for is to store the translation and connection entries.
During normal operation, the free memory on the PIX should change very little, if at all. Typically, the only time
one will run low on memory is when they are under attack and there are hundreds of thousands of connections going
through their PIX. This is observed by issuing the command show conn count - which will display the current and
maximum number of connections through the PIX. If the PIX runs out of memory it will eventually crash. Just
before this point one may notice memory allocation failure messages in the syslog as well (PIX-3-211001). Please
contact the TAC if you are running out of memory because you are under attack.
Client-PIX# sho mem

134217728 bytes total, 67866624 bytes free
Client-PIX#
The show interface Command
The show interface command is useful for not only determining duplex mismatch problems and cable issues, but it
can also provide further insight if the interface is being overrun. Above, we spoke about the blocks on the PIX. If
the PIX is running out of CPU one indicator is the 1550 byte blocks hovering close to zero (or 16384 byte blocks for
the 66 MHz Gig cards). Another indicator would be the increase of no buffers on the interface. The no buffers
indicate that interface is unable to hand the packet up to the PIX OS because there is not an available block to place
the packet in. Hence, the packet is dropped. If increasing no buffers are occurring regularly, check the PIX's CPU
by issuing the command show cpu usage it should also be high. If so, try and determine what is causing the CPU to
be high. If this is caused by traffic load, then you should consider upgrading your PIX to a more powerful one that
can handle the load.
When a packet first enters an interface, it is placed in the input hardware queue. If the input hardware queue is full,
the packet will be placed in the input software queue. Once the packet is in the input queue it is next passed up to
the PIX OS and placed in a 1550 byte block (16384 byte block for the 66 MHz Gigabit Ethernet interfaces). The
PIX then determines the output interface for the packet and proceeds to place the packet in the outbound interface's
hardware queue. If this is full, it is placed in the output software queue. If the max blocks in either of the software
queues are large, this indicates that the interface is being overrun. For example, if 200 Mbps are coming into the
PIX and all going out a single 100 Mbps interface, the output software queue will indicate high numbers on the
outbound interface, indicating that the interface cannot handle the traffic volume. If this is occurring, consider
upgrading to a faster interface.
Client-PIX# sho int

interface ethernet1 "inside" is up, line protocol is up
Hardware is i82559 ethernet, address is 00d0.b78f.b91a
IP address 54.25.7.47, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
26578013 packets input, 3065617244 bytes, 0 no buffer
Received 18403536 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
7706976 packets output, 698417326 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/24)
output queue (curr/max blocks): hardware (2/56) software (0/33)hardware (0/2) software (0/1)
You also want to check the interface for errors. If you are receiving Runts, Input Errors, CRCs, or Frame errors you most likely have a duplex mismatch. (The other likely cause is a faulty cable - but speaking from experience 9
times out of 10 it is a duplex issue). Please remember that each error counter represents the number of packets that
were dropped because of that error. So, if you see a specific counter incrementing quite regularly - your
performance is most likely really suffering and you need to find the root cause of the problem.
While we are examining the interface counters, please note that if the interface is set to full-duplex, you should not
have any collisions, late collisions, or deferred packets. Conversely, if the interface is set to half-duplex, you should
be receiving collisions, some late collisions, and possibly some deferred. The number of collisions + late collisions
+ deferred should not exceed 10% of the sum of the input + output packet counters. If your collisions exceed 10%
of your total traffic this indicates that this link is being over utilized and you need to upgrade to either full-duplex, or
a faster speed (10 Mbps to 100 Mbps). Again, remember that if you have 10% collisions, that means you are
dropping 10% of your packets going through that interface and each of these packets must be re-transmitted.
For detailed information on the interface counters, please see the interface command in the PIX Command
Reference.
The show processes Command

The show processes command on the PIX will display all the active processes running on the PIX at the time the
command was executed. It is useful to determine which processes are receiving too much CPU time, or which
processes are not receiving any CPU time. To examine this, you will need to issue the show processes command
twice - waiting about one minute between the time you first issued the command before issuing it a second time.
Then subtract the Runtime value from the second output of the process you are examining from the Runtime value
from the first output. This will let you know how much CPU time (in milliseconds) that process has received in that
interval of time. It is important to note that some processes are scheduled to run at particular intervals, and some
processes only run when they have information to process. Then there is the 577poll process - which will most
likely have the largest Runtime of all your processes. This is normal because this is the process that polls the
Ethernet interfaces to see if they have any data that needs to be acted on.
The show failover Command

The show failover command is used to determine the current failover status of both PIXes. It can be issued from
either the Active or Standby PIX. One thing that must be understood early on is the use of the words: Active,
Standby, Primary, and Secondary. A PIX is determined to be either Primary or Secondary according to what end of
the serial failover is connected to that PIX. The serial cable has two ends, one labeled Primary, the other labeled
Secondary. If one plugs the Primary end to a PIX, that PIX is now considered the "Primary" PIX - until the cable is
unplugged. Likewise, if the Secondary end of the cable is plugged into a PIX, that PIX is now considered the
"Secondary" PIX - until the cable is unplugged. It makes no difference which PIX has the Primary end of the cable
plugged into it.
With the serial failover cable plugged into both PIXes, one will be the "Active" PIX, and the other will be the
"Standby" PIX. Only the Active PIX will be passing traffic. The Standby PIX will be waiting idly by for a failover
to occur so it can take over. If a failover does occur, the PIXes will swap MAC addresses as well as IP Addresses.
This is done so that the devices on the outside of the PIX have no way of knowing that a failure occurred. Either
PIX can run as the "Active" PIX. There is no difference in performance or any other issue. But, most people choose
to have their Primary PIX run as the Active PIX for normal operation. That way if a user logs in and sees that the
Secondary PIX is Active, they will know that a failover occurred.
The Poll Frequency is the amount of time in seconds that the PIX sends out hello messages out each interface. Both
PIXes (Active and Standby) send hello messages out each interface every poll frequency. If three consecutative
hello messages are missed on any interface, the PIX will go into a testing state, and run through the failover tests to
see if any interface is bad on either PIX. If an interface is found to be bad, then that PIX will fail itself and if it was
the Active PIX, the Standby will then take over as the Active PIX.
Failover testing consists of the following four consecutive tests:
1.
NIC Status Test:
This test is a Link Up/Down check of the NIC itself. If an interface card is not plugged into an operational
network, it is considered failed.
2.
Network Activity Test:
This test is simply a "received network activity" test. The unit counts all received packets for up to 5
seconds. If any packets are received at any time during this interval, the interface is considered operational
and testing stops. If no traffic is received, the unit performs an ARP test.
3.
ARP Test:
In the ARP test, the unit?s ARP cache is read for the 10 most recently acquired entries. Then, one at a time,
the unit sends ARP requests to these machines, attempting to stimulate network traffic. After each request,
the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered
operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list no
traffic has been received, the unit performs the Ping test.
4.
Ping Test:
To perform the Ping test, the unit sends out a broadcast ping request. The unit then counts all received
packets for up to 5 seconds. If any packets are received at any time during this interval, the interface is
considered operational and testing stops. If no traffic is received, the testing starts over again with the ARP
test.
When either PIX is brought up, the PIX detects that Failover is enabled, and its interfaces enter a "Waiting" state.
They must receive 2 hello messages before they can transition out of the "Waiting" State and into a "Normal" state.
When the PIX Failover is functioning properly, all interfaces will be in a "Normal" state.
If a PIX should happen to fail, use the syslogs to search for the failover reason, and then consult the table below. If
either PIX is in a "Failed" state, you can issue the command failover reset to clear the PIX out of the "Failed" state.
It is important to note that the uptime displayed in the output of a show version is the total time that the PIX set
(either the Primary or Secondary) has been up. To determine how long either PIX has been "active" (actively
passing traffic) issue the command show failover and examine the "Active time". The show failover command can
be issued on either PIX. Always look at the information displayed for "This host" to determine whether you are on
the Primary or Secondary, and whether it is Active or Standby.
Stateful Failover Statistics
Client-PIX# sho fail

Failover On
Cable status: Normal
Reconnect timeout 0:00:03
Poll frequency 15 seconds
This host: Primary - Active
Interface PixState (192.168.199.1): Normal
Interface Client-access (167.211.242.1): Link Down (Shutdown)
Interface intf3 (54.26.96.129): Normal
Interface B2B (167.211.241.254): Normal
Interface outside (127.0.0.1): Link Down (Shutdown)
Other host: Secondary - Standby
Interface PixState (192.168.199.2): Normal
Interface Client-access (167.211.242.2): Link Down (Shutdown)
Interface intf3 (54.26.96.130): Normal
Interface B2B (167.211.241.253): Normal
Interface outside (0.0.0.0): Link Down (Shutdown)

The failover statistics are displayed at the end of the show failover command output. The General xmit and rcv
counts are the sum of all the other stateful object counts. It is normal to ocassionally receive General xerr. This is
due to logical updates being dropped during configuration synchronization between the two PIXes. LUs (or Logical
Updates) are packets that are transmitted between the two PIXes on the stateful failover link. They mostly consist of
connection and translation updates. This is how the two PIXes synchronize themselves. If either receive or transmit
errors are incrementing on the TCP or UDP connections, this is ok. The PIX updates all the connections every few
seconds, so if an update gets dropped for any reason, it will be picked up on the next update. The Logical Update
Queue information lets one know how many updates are currently in the queue to be sent over to the other PIX. It
also lets you know the Maximum amount of updates ever in the queue (high water mark). If the Cur equals the Max
and these numbers are very high (in the hundreds) then the PIX is currently having difficulty keeping up with the
stateful failover updates. Check the CPU usage and the number of connections going through the PIX. Also look at
the Current 256 byte block to see if they are hovering near zero (also indicitative of a CPU issue).
Stateful Failover Logical Update Statistics

Link : PixState
Stateful Obj
xmit
xerr
rcv
rerr
General
6631272 0
497208
sys cmd
497197
497203
up time
26
xlate
80
0
0
tcp conn
6133969 0
udp conn
ARP tbl
RIP Tbl
Logical Update Queue Information

Cur
Max
Total
Recv Q:
497208
Xmit Q:
1399086 Xmit Q:
For more information on PIX Failover see - How Failover Works on the Cisco Secure PIX Firewall
Failover Reason Codes
If one of your PIXes happens to fail, causing a Failover, it is important to try to determine the cause of the failure.
The easiest course of action is to search the syslogs for any Level 1 (Alert) messages. All failover messages are sent
out as a Level 1 syslog. If your syslog messages are stored in a flat text file, you can use the grep command in Unix
to grep for the string "PIX-1-" to view all level 1 syslogs. This will show you exactly what happened and to which
PIX. If the failover occured because of a loss of communication between the two PIXes, then you will receive the
following syslog:
%PIX-1-103001: (Secondary) No response from other firewall (reason code = 3). The Reason Code has three
possible values. To determine what these mean, please use the table below. Once you have determined the cause
of the failover, it is important to take corrective actions to correct the situation so that it does not occur in the future.
Description
Reason Code
No Failover hello seen on Serial cable for 30 +

seconds. This ensures that Failover is running
properly on the other PIX.
An interface did not pass one of the 4 failover tests.

The 4 tests are: 1) Link Up, 2) Monitor for Network
Traffic, 3) ARP test, 4) Broadcast Ping test
No proper ACK for 15+ seconds after a command

has been sent on the serial cable.
Capture ASA
Find out what the IP address is of the client host and if possible, what port that host will connect to on the server (for
our example, http is tcp port 80). For this example we are going to use 10.0.0.1 as the client IP, 192.168.0.1 as the
server.
To define the the interesting traffic in order to catch it, use an ACL.
ASA(config)# access-list cap-list permit tcp host 10.0.0.1 host 192.168.0.1 eq 80
ASA(config)# access-list cap-list permit tcp host 192.168.0.1 eq 80 host 10.0.0.1
Make sure you identify traffic in both directions (to and from the server). While an access-list is not needed, it does
help keep the captures clean and concise.
For example:
ASA# capture in-cap interface inside access-list cap-list

ASA# capture out-cap interface outside access-list cap-list
Please note that if there is NATting/PATting taking place you might need to create two different access lists with
different Ip addresses and/or ports to capture the NATted/PATted traffic.
In ASA 8.0 and late you can do the above capture using the match option that captures BI-directionally.
ASA# capture in-cap interface inside match tcp host 10.0.0.1 host 192.168.0.1 eq 80
An example command to enable HTTP management traffic is as follows:
ASA(config)# http 10.0.0.0 255.0.0.0 inside
where 10.0.0.0 is the allowed subnet and 255.0.0.0 is the mask.
To view the captures, browse to
https://ip_of_firewall/capture/in-cap/pcap
https://ip_of_firewall/capture/out-cap/pcap
By default the browser will save the file as 'pcap' which is largely useless. Alternatively you can specify the name it
should save it as by appending the desired name to the end of the URL:
https://ip_of_firewall/capture/in-cap/pcap/inside.pcap
https://ip_of_firewall/capture/out-cap/pcap/outside.pcap
Use the commands
ASA# no capture in-cap
ASA# no capture out-cap
We can transfer the capture to our workstation:
pix1(config)# copy capture:cap1 tftp://10.0.1.12/bastion.txt

copying Capture to tftp://10.0.1.12/bastion.txt:
pix1(config)#
You can specify the full path as follows:
hostname(config)# copy capture:abc tftp:171.68.11.129/tftpboot/abc.cap
Example 5-13. Time-Range Configuration
Chicago(config)# time-range business_hours
Chicago(config-time-range)#
In the time-range configuration mode, you can specify two different types of time restrictions:
Absolute
Periodic
Absolute
Using the absolute function, you can specify the values based on a start and/or an end time. This function is useful in
cases where a company hires consultants for a period of time and wants to restrict access when they leave. In this
case, you can set an absolute time and specify the start and the end time. Once the time period expires, the
consultants will not be able to pass traffic through the security appliance.
The start and end times are optional. If there is no start time provided, the security appliance assumes that the ACL
needs to be applied right away. If there is no end time configured, the security appliance applies the ACL
indefinitely. Additionally, only one instance of the absolute parameter is allowed to be set up in a given time range.
The following is the command syntax to configure an absolute time range:
absolute [start time date] [end time date]
start time date specifies when to begin applying an ACE, and end time date directs the security appliance when to
stop applying it. In Example 5-14, the administrator has created a time-range policy called business_hours for a
new consultant whose start time/date is 8 a.m. on June 1, 2005 and end time/date is 5 p.m. on December 30, 2005.
Example 5-14. Absolute Time-Range Configuration
Chicago(config-time-range)# absolute start 08:00 01 June 2005 end 17:00 30
December 2005
Note
The start and end times use the same format as the clock set command when configuring time and date values in the
absolute function.
Periodic
Using the periodic function, you can specify the values based on the recurring events. The security appliance
provides many easy-to-configure parameters to suit an environment. Time-based ACLs using this option is useful
when a company wants to allow user access during the normal business hours on the weekdays and wishes to deny
access over the weekends. Cisco ASA allows you to configure multiple instances of the periodic parameter. If both
absolute and periodic parameters are configured in a time range, the absolute time parameters are evaluated first
before evaluating the periodic time value. The following shows the command syntax to configure a periodic time
range:
periodic <days-of-the-week> <hh:mm> to <days-of-the-week> <hh:mm>
The days-of-the-week values can be Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday. If
you need to configure periodic days-of-the-week from Monday through Friday, you can use a shortcut of weekdays
instead. For periodic Saturday and Sunday, you can use weekend as a shortcut. The security appliance can further
the restrictions on the users by setting the optional 24-hour format hh:mm time specifications. In Example 5-15, the
administrator has created a time-range policy called business_hours for the regular employees who work from 8
a.m. to 5 p.m. on weekdays and from 8 a.m. to 12 p.m. on Saturdays.
Example 5-15. Periodic Time-Range Configuration
Chicago(config-time-range)# periodic weekdays 8:00 to 17:00
Chicago(config-time-range)# periodic Saturday 8:00 to 12:00
Once a time-range entry has been set up, the next step is to map it to the ACL by using the time-range keyword, as
illustrated in Example 5-16, in which the administrator allows outside users access to an internal web server,
209.165.202.131, during business hours (8 a.m. to 5 p.m. Monday through Friday and 8 a.m. to 12 p.m. Saturday). If
the outside users try to access the servers outside of this time window, the security appliance will drop the packets
and generate a syslog message logging this event. The ACL name is inside_server and the time-range name is
business_hours. The ACL is applied to the outside interface in the inbound direction.
Example 5-16. Configuration of a Time-Based ACL
Chicago(config)# access-list inside_server extended permit tcp any host
209.165.202.131 eq 80 time-range business_hours
Chicago(config)# access-group inside_server in interface outside
ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection
provide a wealth of information about the state of TCP connections to the ASA. This information can be used to
troubleshoot problems with the ASA, as well as problems elsewhere in the network.
Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through
the ASA. These connections can also be seen with the show conn command.
ASA# show conn protocol tcp
TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA
TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO
TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags UIO
The next picture shows the ASA TCP Connection flags at different stages of the TCP state machine. The connection
flags can be seen with the show conn command on the ASA.
TCP Connection Flag Values
set connection
To specify connection values within a policy-map for a traffic class, use the set connection command in class mode.
Use this command to specify the maximum number of simultaneous connections and to specify whether to enable or
disable TCP sequence number randomization
set connection {conn-max | embryonic-conn-max} n random-seq# {enable | disable}

Syntax Description
conn-max n
The maximum number of simultaneous TCP and/or UDP connections that are allowed.
disable
Turns off TCP sequence number randomization.
enable
Turns on TCP sequence number randomization.
embryonicconn-max n
The maximum number of simultaneous embryonic connections allowed.
random-seq#
Enable or disable TCP sequence number randomization. Each TCP connection has two ISNs:
one generated by the client and one generated by the server. The security appliance randomizes
the ISN of the TCP SYN passing in both the inbound and outbound directions.
Randomizing the ISN of the protected host prevents an attacker from predecting the next ISN
for a new connection and potentially hijacking the new session.
TCP initial sequence number randomization can be disabled if required. For example:
If another in-line firewall is also randomizing the initial sequence numbers, there is no need
for both firewalls to be performing this action, even though this action does not affect the
traffic.
If you use eBGP multi-hop through the security appliance, and the eBGP peers are using
MD5. Randomization breaks the MD5 checksum.
You use a WAAS device that requires the security appliance not to randomize the sequence
numbers of connections.
Defaults
For both the conn-max and embryonic-conn-max parameters, the default value of n is 0, which allows unlimited
connections.
Sequence number randomization is enabled by default.
Note The set connection command parameters (conn-max, embryonic-conn-max, random-seq#) can co-exist
with any nat or static command; that is, you can configure connection parameters either through the nat/static
commands using max-conn, emb_limit, or noramdomseq parameters, or through the MPC set connection
command using conn-max, embryonic-conn-max, or random-seq# parameters. A mixed configuration is not
recommended,
but
if
one
exists,
it
behaves
in
the
following
ways:
When a traffic class is subject to a connection limit or embryonic connection limit from both the MPC set
connection command and the nat/static command, then whichever limit is reached, that limit is applied.
When a TCP traffic class is configured to have sequence number randomization disabled by either the MPC set
connection command or the nat/static command, then sequence number randomization is disabled.
Examples
The following is an example of the use of the set connection command in class mode to configure the maximum
number of simultaneous connections as 256 and to disable TCP sequence number randomization:
hostname(config)# policy-map localpolicy1

hostname(config-pmap)# class local_server
hostname(config-pmap-c)# set connection conn-max 256 random-seq# disable
hostname(config-pmap-c)# exit
set connection timeout

To configure the timeout period, after which an idle TCP connection is disconnected, use the set connection
timeout command in class mode. To remove the timeout, use the no form of this command.
set connection timeout tcp hh[:mm[:ss]] [reset]
no set connection timeout tcp
set connection timeout embryonic hh[:mm[:ss]]
no set connection timeout embryonic
Syntax Description
reset
Sends a TCP RST packet to both end systems after TCP idle connections are removed.
tcp hh[:mm[:ss]] The idle time after which an established connection closes.
Defaults
The default embryonic connection timeout value is 30 seconds.
The default half-closed connection timeout value is 10 minutes.
The default tcp connection timeout value is 1 hour.
Usage Guidelines
You must have configured the policy-map command and the class command before issuing this command.
A TCP connection for which a three-way handshake is not complete is an embryonic connection. For the embryonic
connection timeout value, use 0:0:0 to specify that the connection never times out. Otherwise, the timeout duration
must be at least 5 seconds.
When the TCP connection is in the closing state, use the half-closed parameter to configure the length of time until
the connection is freed. Use 0:0:0 to specify that the connection never times out. The minimum timeout duration is 5
minutes.
The tcp inactive connection timeout configures the period after which an idle TCP connection in the established
state is disconnected. Use 0:0:0 to specify that the connection never times out. The minimum timeout duration is 5
minutes.
The reset keyword is used to send a TCP RST packet to both end systems once an idle TCP connection has timed
out. Some applications require a TCP RST after a timeout to perform properly.
Examples
The following is an example of a set connection timeout command that specifies an embryonic connection timeout
of two minutes:
hostname(config)# access-list http-server permit tcp any host 10.1.1.1

hostname(config)# class-map http-server
hostname(config-cmap)# match access-list http-server

hostname(config-cmap)# exit
hostname(config)# policy-map global_policy global

hostname(config-pmap)# description This policy map defines a policy concerning connection
to http server.
hostname(config-pmap)# class http-server
hostname(config-pmap-c)# set connection timeout embryonic 00:2:00
show aaa local user

To show the list of usernames that are currently locked, or to show details about the username, use the
show aaa local user command in global configuration mode.
show aaa local user [locked]
Syntax Description
locked (Optional) Shows the list of usernames that are currently locked.
Usage Guidelines
If you omit the optional keyword locked, the security appliance displays the failed-attempts and lockout
status details for all AAA local users.
You can specify a single user by using the username option or all users with the all option.
This command affects only the status of users that are locked out.
The administrator cannot be locked out of the device.
Examples
The following example shows use of the show aaa local user command to display the lockout status of
all usernames:
This example shows the use of the show aaa local user command to display the number of failed
authentication attempts and lockout status details for all AAA local users, after the limit has been set
to 5:
hostname(config)# aaa local authentication attempts max-fail 5
hostname(config)# show aaa local user
Lock-time Failed-attempts Locked User
- 6 Y test
- 2 N mona
- 1 N cisco
- 4 N newuser
hostname(config)#
This example shows the use of the show aaa local user command with the lockout keyword to display
the number of failed authentication attempts and lockout status details only for any locked-out AAA
local users, after the limit has been set to 5:
hostname(config)# aaa local authentication attempts max-fail 5
hostname(config)# show aaa local user
Lock-time Failed-attempts Locked User
- 6 Y test
hostname(config)#
Related Commands
Command
Description
aaa local authentication

attempts max-fail
Configures the maximum number of times a user can enter a wrong password
before being locked out.
clear aaa local user failattempts
Resets the number of failed attempts to 0 without modifying the lockout status.
clear aaa local user lockout
Clears th e lockout status of the specified user or all users and sets their failed
attempts counters to 0.
show access-list
To display the counters for an access list, use the show access-list command in privileged EXEC mode.
show access-list id
Examples
The following is sample output from the show access-list command:
hostname# show access-list ac

access-list ac; 2 elements
access-list ac line 1 permit ip any any (hitcnt=0)
access-list ac line 2 permit tcp any any (hitcnt=0)
Related Commands
Command
Description
clear access-list
Clears an access list counter.
clear configure access-list
Clears an access list from the running configuration.
show running-config access-list
Displays the current running access-list configuration
show activation-key
To display the commands in the configuration for features that are enabled by your activation key, including the
number of contexts allowed, use the show activation-key command in privileged EXEC mode.
show activation-key
Usage Guidelines
The show activation-key command output indicates the status of the activation key as follows:
If the activation key in the security appliance Flash file system is the same as the activation key running on the
security appliance, then the show activation-key output reads as follows:
The flash activation key is the SAME as the running key.
If the activation key in the security appliance Flash file system is different from the activation key running on
the security appliance, then the show activation-key output reads as follows:
The flash activation key is DIFFERENT from the running key.

The flash activation key takes effect after the next reload.
If you downgrade your activation key, the display shows that the running key (the old key) differs from the key
that is stored in the Flash (the new key). When you restart, the security appliance uses the new key.
If you upgrade your key to enable extra features, the new key starts running immediately without a restart.
For the PIX Firewall platform, if there is any change in the failover feature (R/UR/FO) between the new key
and the oldkey, it prompts for confimation. If the user enters n, it aborts the change; otherwise it updates the key in
the Flash file system. When you restart the security appliance uses the new key.
Examples
This example shows how to display the commands in the configuration for features that are enabled by your
activation key:
hostname(config)# show activation-key

Serial Number: P3000000134 Running Activation Key: 0xyadayada 0xyadayada 0xyadayada
0xyadayada 0xyadayada
License Features for this Platform:

Maximum Physical Interfaces : Unlimited
Maximum VLANs
Inside Hosts
Failover
VPN-DES
VPN-3DES-AES
Cut-through Proxy
Guards
: 50
: Unlimited
: Enabled
: Enabled
: Disabled
: Enabled
: Enabled
URL-filtering
: Enabled
Security Contexts
: 20
GTP/GPRS
: Disabled
VPN Peers
: 5000
The flash activation key is the SAME as the running key.

hostname(config)#
Related Commands
Command
activation-key
Description
Changes the activation key.
show arp
To view the ARP table, use the show arp command in privileged EXEC mode.
show arp
Usage Guidelines
The display output shows dynamic, static, and proxy ARP entries. Dynamic ARP entries include the age of the ARP
entry in seconds. Static ARP entries include a dash (-) instead of the age, and proxy ARP entries state "alias."
Examples
The following is sample output from the show arp command. The first entry is a dynamic entry aged 2 seconds. The
second entry is a static entry, and the third entry is from proxy ARP.
hostname# show arp

outside 10.86.194.61 0011.2094.1d2b 2
outside 10.86.194.1 001a.300c.8000 outside 10.86.195.2 00d0.02a8.440a alias
Setting Up ASDM
Uploading ASDM
You can use the dir command to determine whether or not the ASDM software is installed. In case the security
Cisco ASA does not have the ASDM software, your first step is to upload the image from an external file server
using the supported protocols
Example 18-1. Uploading the ASDM Image to the Local Flash
Chicago# copy tftp flash
Address or name of remote host []? 172.18.108.26
Source filename []? asdm-501.bin
Destination filename [asdm-501.bin]? asdm-501.bin
Directory of disk0:/
1260 -rw- 5124096
16:47:34 Aug 07 2005 asa701.bin
2511 -rw- 5876644
17:38:14 Aug 07 2005 asdm-501.bin
Setting Up Cisco ASA

When the ASDM file is accessed, the Cisco ASA loads the first ASDM image from the local Flash. If there are
multiple ASDM images in the flash, use the asdm image command and specify the location of the ASDM image
you want to load
Example 18-2. Specifying the ASDM Location
Chicago(config)# asdm image disk0:/asdm-501.bin
Example 18-3. Enabling the HTTP Server
Chicago(config)# http server enable
Chicago(config)# http 172.18.124.0 255.255.255.0 mgmt
To establish an SSL connection, launch a browser and point the URL to the IP address of Cisco ASA. In Figure 181, the administrator is accessing ASDM by typing in
https://172.18.124.205/admin/index.html as the URL.
ASA Accelerated Security Path
This post will provide a brief overview of a seldom referred to part of the ASA, the Accelerated Security Path
(ASP). As we know the ASAs Adaptive Security Algorithm is responsible for inspecting all traffic that traverses
the ASA, and based on its configured security policies will either permit or deny the traffic.
As a new connection enters the ASA it is processed using the Session Management Path.
Part of the Session Management Paths processing is to inspect and create the relevant entry in the ASAs
state/connection table, if a policies exists allowing the traffic.
Generally any further packets received for these established connections, does not require further inspection and are
subsequently handled by the Fast Path. Although, there may be certain packets that would continue to use the
session management path or be passed to the control plane path, such as flows requiring HTTP inspection, FTP or
H.232 etc.
This is akin to Process switching and CEF switching in IOS Routers.
The Session Management Path and Fast Path combined are what make up the Accelerated Security Path.
ASP can come in handy when we want to troubleshoot traffic flows through the ASA. This is done via a suite of
ASP show commands, and can also be incorporated into packet captures, using a capture type of asp-drop.
With ASP debugging we can drill down into the output to see what functions or methods are responsible for
dropping the traffic on the ASA. There are two set of commands available to us, both of which have a substantial
amount of optional keywords; these are, show asp drop and show asp table.
Starting with show asp drop will give us a summary of packets or connections that have been denied by ASP
providing an associated reason and hits on each. As we can see from the output below it is split into 2 sections;
Frame Drop which is based on packet failures; and Flow Drop based on inspected traffic flow failures.
It gives us a brief breakdown of denies based on malformed TCP sessions, Reverse Path Forwarding violations, or
simply denies based on ACL entries etc.
You can also further drill into more specific output using optional keywords, based on either frame or flow drop,
such as show asp drop frame ifc-classify when in virtual firewall mode shows counts for packets that failed to be
classified to context; or show asp drop flow conn-limit-exceeded increments when the value applied to set
connection conn-max is breached.
These are just a couple of the vast amount of options available for use. Check out the ASA Command Reference
document for a full listing.
A key point with the ASP drop output is when running in Multi Context Mode, the information provided is a
summary for all of the virtual contexts not just the context you are currently logged into.
The other side of ASP is the show asp table commands. These are typically used by TAC, so contain a great deal
of info on a production appliance. These tables are primarily used for debugging, so the output is prone to regular
changes.
Below are the asp tables available:
The show asp table arp for instance can be used to check that traffic is flowing to/from a specific host/s based on
an incrementing hit count. It is important to remember that this is dynamic real time output though and will be
subject to resetting.
The show asp table routing can give us further info into how specific nets are routed. This is provided based on
two tables; an input routing table and an output routing table, each showing the routable nets and their associated
interfaces.
And to finish off a quick look at the classify table. This table consists of multiple classifier domains which
correspond to a specific rule action within the ASA, I.e. Inspection rules, filtering rules nat rules etc. Again check
out the command reference for a list of the options.
Below is an example showing SMTP traffic is being inspected and allowed to the inside interface:
show clock
To view the time on the security appliance, use the show clock command in user EXEC mode.
show clock [detail]
show cpu
To display the CPU utilization information, use the show cpu usage command in privileged EXEC mode.
show cpu [usage]
From the system configuration in multiple context mode:
show cpu [usage] [context {all | context_name}]
Usage Guidelines
The cpu usage is computed using an approximation of the load every five seconds, and by further feeding this
approximation into two, following moving averages.
You can use the show cpu command to find process related loads (that is, activity on behalf of items listed by the
output of the show process command in both single mode and from the system configuration in multiple context
mode).
Further, you can request, when in multiple context mode, a breakdown of the process related load to CPU consumed
by any configured contexts by changing to each context and entering the show cpu command or by entering the
show cpu context variant of this command.
While process related load is rounded to the nearest whole number, context related loads include one additional
decimal digit of precision. For example, entering show cpu from the system context produces a different number
than from entering the show cpu context system command. The former is an approximate summary of everything
in show cpu context all, and the latter is only a portion of that summary.
Examples
The following example shows how to display the CPU utilization:
hostname# show cpu usage

CPU utilization for 5 seconds = 18%; 1 minute: 18%; 5 minutes: 18%
This example shows how to display the CPU utilization for the system context in multiple mode:
hostname# show cpu context system

CPU utilization for 5 seconds = 9.1%; 1 minute: 9.2%; 5 minutes: 9.1%
The following shows how to display the CPU utilization for all contexts:
hostname# show cpu usage context all

5 sec 1 min 5 min Context Name
9.1% 9.2% 9.1% system
0.0% 0.0% 0.0% admin

5.0% 5.0% 5.0% one
4.2% 4.3% 4.2% two
show crashinfo
To display the contents of the crash file stored in Flash memory, enter the show crashinfo command in privileged
EXEC mode.
show crashinfo [save]
Usage Guidelines
If the crash file is from a test crash (generated from the crashinfo test command), the first string of the crash file is
": Saved_Test_Crash" and the last string is ": End_Test_Crash". If the crash file is from a real crash, the first string
of the crash file is ": Saved_Crash" and the last string is ": End_Crash". (This includes crashes from use of the
crashinfo force page-fault or crashinfo force watchdog commands).
If there is no crash data saved in flash, or if the crash data has been cleared by entering the clear crashinfo
command, the show crashinfo command displays an error message.
Examples
The following example shows how to display the current crash information configuration:
hostname# show crashinfo save

crashinfo save enable
Related Commands
Command
Description
clear crashinfo
Deletes the contents of the crash file.
crashinfo force
Forces a crash of the security appliance.
crashinfo save
disable
Disables crash information from writing to Flash memory.
crashinfo test
Tests the ability of the security appliance to save crash information to a file in Flash memory.
show conn
To display the connection state for the designated connection type, use the show conn command in
privileged EXEC mode. This command supports IPv4 and IPv6 addresses.
show conn [count | [all] [detail] [long] [state state_type] [protocol {tcp | udp}]
[address src_ip[-src_ip] [netmask mask]] [port src_port[-src_port]]
[address dest_ip[-dest_ip] [netmask mask]] [port dest_port[-dest_port]]]
show failover
To display information about the failover status of the unit, use the show failover command in privileged EXEC
mode.
show failover [group num | history | interface | state | statistics]
Usage Guidelines
The show failover command displays the dynamic failover information, interface status, and Stateful Failover
statistics. The Stateful Failover Logical Update Statistics output appears only when Stateful Failover is enabled. The
"xerr" and "rerr" values do not indicate errors in failover, but rather the number of packet transmit or receive errors.
In the show failover command output, the fields have the following values:
Stateful Obj has these values:
xmitIndicates the number of packets transmitted.
xerrIndicates the number of transmit errors.
rcvIndicates the number of packets received.
rerrIndicates the number of receive errors.
Each row is for a particular object static count as follows:
GeneralIndicates the sum of all stateful objects.
sys cmdRefers to the logical update system commands, such as login or stay alive.
up timeIndicates the value for the security appliance up time, which the active security appliance passes on to
the standby security appliance.
RPC servicesRemote Procedure Call connection information.
TCP connDynamic TCP connection information.
UDP connDynamic UDP connection information.
ARP tblDynamic ARP table information.
Xlate_TimeoutIndicates connection translation timeout information.
VPN IKE updIKE connection information.
VPN IPSEC updIPSec connection information.
VPN CTCP updcTCP tunnel connection information.
VPN SDI updSDI AAA connection information.
VPN DHCP updTunneled DHCP connection information
show firewall
To show the current firewall mode (routed or transparent), use the show firewall command in privileged EXEC
mode.
show firewall
Examples
The following is sample output from the show firewall command:
hostname# show firewall

Firewall mode: Router
Related Commands
Command
Description
firewall transparent
Sets the firewall mode.
show mode
Shows the current context mode, either single or multiple.
show flash
To display the contents of the internal Flash memory, use the show flash: command in privileged EXEC mode.
show flash:
show icmp
To display the ICMP configuration, use the show icmp command in privileged EXEC mode.
show icmp
show interface
To view interface statistics, use the show interface command in user EXEC mode.
show interface [physical_interface[.subinterface] | mapped_name | interface_name] [stats | detail]
Syntax Description
detail
(Optional) Shows detailed interface information, including the order in which the interface
was added, the configured state, the actual state, and asymmetrical routing statistics, if
enabled by the asr-group command. If you show all interfaces, then information about the
internal interfaces for SSMs displays, if installed on the ASA 5500 series adaptive security
appliance. The internal interface is not user-configurable, and the information is for
debugging purposes only.
interface_name
(Optional) Identifies the interface name set with the nameif command.
mapped_name
(Optional) In multiple context mode, identifies the mapped name if it was assigned using
the allocate-interface command.
physical_interface
(Optional) Identifies the interface ID, such as gigabitethernet0/1. See the interface
command for accepted values.
stats
(Default) Shows interface information and statistics. This keyword is the default, so this
keyword is optional.
subinterface
(Optional) Identifies an integer between 1 and 4294967293 designating a logical

subinterface.
Examples
The following is sample output from the show interface command:
hostname> show interface
show interface ip brief

To view interface IP addresses and status, use the show interface ip brief command in privileged EXEC mode.
show interface [physical_interface[.subinterface] | mapped_name | interface_name] ip brief
Syntax Description
interface_name
(Optional) Identifies the interface name set with the nameif command.
mapped_name
(Optional) In multiple context mode, identifies the mapped name if it was assigned using
the allocate-interface command.
physical_interface
(Optional) Identifies the interface ID, such as gigabitethernet0/1. See the interface
command for accepted values.
subinterface
(Optional) Identifies an integer between 1 and 4294967293 designating a logical

subinterface.
Usage Guidelines
In multiple context mode, if you mapped the interface ID in the allocate-interface command, you can only specify
the mapped name or the interface name in a context.
See the "Examples" section for a description of the display output.
Examples
The following is sample output from the show ip brief command:
hostname# show interface ip brief
Interface
Control0/0
IP-Address
127.0.1.1
OK? Method Status
Protocol
YES CONFIG up
up
GigabitEthernet0/0
209.165.200.226 YES CONFIG up
GigabitEthernet0/1
unassigned
GigabitEthernet0/2
10.1.1.50
GigabitEthernet0/3
192.168.2.6
Management0/0
209.165.201.3 YES CONFIG up
up
YES unset administratively down down

YES manual administratively down down
YES DHCP
administratively down down
Table 7-19 show interface ip brief Fields

Field
Description
Interface
The interface ID or, in multiple context mode, the mapped name if you configured it using the
allocate-interface command. If you show all interfaces, then information about the internal
interface for the AIP SSM displays, if installed on the ASA adaptive security appliance. The
internal interface is not user-configurable, and the information is for debugging purposes only.
IPAddress
The interface IP address.
OK?
This column is not currently used, and always shows "Yes."
Method
The method by which the interface received the IP address. Values include the following:
Status
Protocol
unsetNo IP address configured.
manualConfigured the running configuration.
CONFIGLoaded from the startup configuration.
DHCPReceived from a DHCP server.
The administrative state, as follows:
upThe interface is not shut down.
administratively downThe interface is shut down with the shutdown command.
The line status, as follows:
upA working cable is plugged into the network interface.
downEither the cable is incorrect or not plugged into the interface connector.
show ip address
To view interface IP addresses or, for transparent mode, the management IP address, use the show ip address
command in privileged EXEC mode
Examples
The following is sample output from the show ip address command:
hostname# show ip address

System IP Addresses:
Interface
Name
GigabitEthernet0/0
mgmt
GigabitEthernet0/1
inside
GigabitEthernet0/2.40
GigabitEthernet0/3
outside
dmz
IP address
10.7.12.100
10.1.1.100
Subnet mask
Method
255.255.255.0
CONFIG
255.255.255.0
CONFIG
209.165.201.2
255.255.255.224 DHCP
209.165.200.225
255.255.255.224 manual
show ip address dhcp

To view detailed information about the DHCP lease or server for an interface, use the show ip address dhcp
command in privileged EXEC mode.
show ip address {physical_interface[.subinterface] | mapped_name | interface_name} dhcp {lease | server}
Examples
The following is sample output from the show ip address dhcp lease command:
hostname# show ip address outside dhcp lease

Temp IP Addr:209.165.201.57 for peer on interface:outside
Temp sub net mask:255.255.255.224
DHCP Lease server:209.165.200.225, state:3 Bound
DHCP Transaction id:0x4123
Lease:259200 secs, Renewal:129600 secs, Rebind:226800 secs
Temp default-gateway addr:209.165.201.1
Temp ip static route0: dest 10.9.0.0 router 10.7.12.255
Next timer fires after:111797 secs
Retry count:0, Client-ID:cisco-0000.0000.0000-outside
Proxy: TRUE Proxy Network: 10.1.1.1
Hostname: device1
show isakmp sa
To display the IKE runtime SA database, use the show isakmp sa command in global configuration mode or
privileged EXEC mode.
show isakmp sa [detail]
Examples
The following example, entered in global configuration mode, displays detailed information about the SA database:
hostname(config)# show isakmp sa detail

hostname(config)# sho isakmp sa detail
IKE Peer
Type Dir Rky State
Encrypt Hash Auth
1 209.165.200.225 User Resp No AM_Active 3des
IKE Peer
Type Dir Rky State
Lifetime
SHA preshrd 86400
Encrypt Hash Auth
Lifetime
2 209.165.200.226 User Resp No AM_ACTIVE 3des SHA preshrd 86400
Related Commands
Command
Description
clear configure
isakmp
Clears all the ISAKMP configuration.
clear configure
isakmp policy
Clears all ISAKMP policy configuration.
clear isakmp sa
Clears the IKE runtime SA database.
isakmp enable
Enables ISAKMP negotiation on the interface on which the IPSec peer

communicates with the security appliance.
show running-config
isakmp
Displays all the active ISAKMP configuration.
show mac-address-table
To show the MAC address table, use the show mac-address-table command in privileged EXEC mode.
show memory
To display a summary of the maximum physical memory and current free memory available to the operating system,
use the show memory command in privileged EXEC mode.
show memory [detail]
Usage Guidelines
The show memory command lets you display a summary of the maximum physical memory and current free
memory available to the operating system. Memory is allocated as needed.
You can use the show memory detail output with show memory binsize command to debug memory leaks.
You can also display the information from the show memory command using SNMP.
Examples
This example shows how to display a summary of the maximum physical memory and current free memory
available:
hostname# show memory

Free memory:
845044716 bytes (79%)
Used memory:
228697108 bytes (21%)
-------------
----------------
Total memory:
show mode
1073741824 bytes (100%)
To show the security context mode for the running software image and for any image in Flash memory, use the
show mode command in privileged EXEC mode.
show mode
Examples
The following is sample output from the show mode command. The following example shows the current mode and
the mode for the non-running image "image.bin":
hostname# show mode flash:/image.bin

Firewall mode: multiple
show nameif
To view the interface name set using the nameif command, use the show nameif command in privileged EXEC
mode
Examples
The following is sample output from the show nameif command:
hostname# show nameif

Interface
Name
Security
GigabitEthernet0/0
outside
GigabitEthernet0/1
inside
100
GigabitEthernet0/2
test2
50
show ospf border-routers

To display the internal OSPF routing table entries to ABRs and ASBRs, use the show ospf border-routers
show ospf border-routers
Examples
The following is sample output from the show ospf border-routers command:
hostname# show ospf border-routers
OSPF Process 109 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 192.168.97.53 [10] via 192.168.1.53, fifth, ABR, Area 0, SPF 20

i 192.168.103.51 [10] via 192.168.96.51, outside, ASBR, Area 192.168.12.0, SPF 14
i 192.168.103.52 [10] via 192.168.96.51, outside, ABR/ASBR, Area 192.168.12.0, SPF 14
show ospf database

To display the information contained in the OSPF topological database on the security appliance, use the show ospf
database command in privileged EXEC mode.
show perfmon
To display information about the performance of the security appliance, use the show perfmon command.
show perfmon
show route
To display a default or static route for an interface, use the show route command in privileged EXEC mode.
Examples
The following is sample output from the show route command:
hostname(config)# show route
10.30.10.0 255.255.255.0 is directly connected, outside
10.40.10.0 255.255.255.0 is directly connected, inside
192.168.2.0 255.255.255.0 is directly connected, faillink
192.168.3.0 255.255.255.0 is directly connected, statelink
show running-config aaa-server

To display AAA server configuration, use the show running-config aaa-server command in privileged EXEC
mode.
show running-config
show running-config access-group
To display the access group information, use the show running-config access-group command in privileged EXEC
mode.
show running-config access-group
Examples
The following is sample output from the show running-config access-group command:
hostname# show running-config access-group

access-group 100 in interface outside
show running-config access-list

To display the access-list configuration that is running on the security appliance, use the show running-config
access-list command in privileged EXEC mode
Usage Guidelines
The show running-config access-list command allows you to display the current running access list configuration
on the security appliance.
Examples
The following is sample output from the show running-config access-list command:
hostname# show running-config access-list
access-list allow-all extended permit ip any any
show running-config class-map

To display the information about the class map configuration, use the show running-config class-map command in
show running-config
Examples
The following is sample output from the show running-config class-map command:
hostname# show running-config class-map

class-map tcp-port
match port tcp eq ftp
show running-config class-map

To display the information about the class map configuration, use the show running-config class-map command in
Examples
The following is sample output from the show running-config class-map command:
hostname# show running-config class-map

class-map tcp-port
match port tcp eq ftp
show running-config crypto isakmp

To display the complete ISAKMP configuration, use the show running-config crypto isakmp command in global
configuration or privileged EXEC mode.
show running-config crypto isakmp
Examples
The following example issued in global configuration mode, displays information about the ISKAKMP
configuration:
hostname<config># show running-config crypto isakmp

isakmp enable inside
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400
hostname<config>#
show running-config crypto map

To display all configuration for all crypto maps, use the show running-config crypto map command in global
show running-config crypto map
Examples
The following example entered in privileged EXEC mode, displays all configuration information for all crypto
maps:
hostname# show running-config crypto map

crypto map abc 1 match address xyz
crypto map abc 1 set peer 209.165.200.225
crypto map abc 1 set transform-set ttt
crypto map abc interface test
hostname#
show running-config failover

To display the failover commands in the configuration, use the show running-config failover command in
show running-config [all] failover
Usage Guidelines
The show running-config failover command displays the failover commands in the running configuration. It does
not display the monitor-interface or join-failover-group commands.
Examples
The following example shows the default failover configuration before failover has been configured:
hostname# show running-config all failover

no failover
failover lan unit secondary
failover polltime unit 15 holdtime 45
failover polltime interface 15
failover interface policy 1
hostname#
show running-config group-policy

To display the running configuration for a particular group policy, use the show running-config group-policy
command in privileged EXEC mode and append the name of the group policy. To display the running configuration
for all group policies, use this command without naming a specific group policy. To have either display include the
default configuration, use the default keyword.
show running-config [default] group-policy [name]
show running-config http
To display the current set of configured http commands, use the show running-config http command in privileged
EXEC mode.
show running-config http
Examples
The following sample output shows how to use the show running-config http command:
hostname# show running-config http

http server enabled
0.0.0.0 0.0.0.0 inside
show running-config icmp

To show the access rules configured for ICMP traffic, use the show running-config icmp command in privileged
EXEC mode.
show running-config icmp map_name
Examples
The following is sample output from the show running-config icmp command:
hostname# show running-config icmp

!
icmp permit host 172.16.2.15 echo-reply outside
icmp permit 172.22.1.0 255.255.0.0 echo-reply outside
icmp permit any unreachable outside
show running-config interface

To show the interface configuration in the running configuration, use the show running-config interface command
in privileged EXEC mode
Examples
The following is sample output from the show running-config interface command. The following example shows
the running configuration for all interfaces. The GigabitEthernet0/2 and 0/3 interfaces have not been configured yet,
and show the default configuration. The Management0/0 interface also shows the default settings.
formula_1# show running-config interface
!
nameif inside
security-level 100
ip address 10.86.194.60 255.255.254.0
webvpn enable
!
shutdown
nameif test
security-level 0
ip address 10.10.4.200 255.255.0.0
show running-config isakmp

To display the complete ISAKMP configuration, use the show running-config isakmp command in global
show running-config isakmp
Examples
The following example issued in global configuration mode, displays information about the ISKAKMP
configuration:
hostname(config)# show running-config isakmp

isakmp enable inside
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5

isakmp policy 1 group 2
isakmp policy 1 lifetime 86400
hostname(config)#
show running-config logging

To display all currently running logging configuration, use the show runnig-config logging command in privileged
EXEC mode.
show running-config [all] logging [level | disabled]
Examples
The following is an example of the show running-config logging disabled command:
hostname# show running-config logging disabled
no logging message 720067
show running-config nat

To display a pool of global IP addresses that are associated with a network, use the show running-config nat
show running-config nat [interface_name] [nat_id]
Examples
This example shows how to display a pool of global IP addresses that are associated with a network:
hostname# show running-config nat

nat (inside) 1001 10.7.2.0 255.255.255.224 0 0
nat (inside) 1001 10.7.2.32 255.255.255.224 0 0
nat (inside) 1001 10.7.2.64 255.255.255.224 0 0
nat (inside) 1002 10.7.2.96 255.255.255.224 0 0

nat (inside) 1002 10.7.2.128 255.255.255.224 0 0
nat (inside) 1002 10.7.2.160 255.255.255.224 0 0
nat (inside) 1003 10.7.2.192 255.255.255.224 0 0
nat (inside) 1003 10.7.2.224 255.255.255.224 0 0
show running-config nat-control

To show the NAT configuration requirement, use the show running-config nat-control command in privileged
EXEC mode.
show running-config nat-control
Examples
The following is sample output from the show running-config nat-control command:
hostname# show running-config nat-control

no nat-control
show running-config object-group

To display the current object groups, use the show running-config object-group command in privileged EXEC
mode.
show running-config [all] object-group [protocol | service | network | icmp-type | id obj_grp_id]
Examples
The following is sample output from the show running-config object-group command:
hostname# show running-config object-group

object-group protocol proto_grp_1
protocol-object udp
protocol-object tcp
object-group service eng_service tcp

port-object eq smtp
port-object eq telnet
object-group icmp-type icmp-allowed
icmp-object echo
icmp-object time-exceeded
show running-config passwd

To show the encrypted login passwords, use the show running-config passwd command in privileged EXEC mode.
Examples
The following is sample output from the show running-config passwd command:
hostname# show running-config passwd

passwd 2AfK9Kjr3BE2/J2r encrypted
show running-config port-forward

To display the set(s) of applications that WebVPN users can access over forwarded TCP ports, use the show
running-config port-forward command in privileged EXEC mode.
show running-config [all] port-forward
Examples
The following is sample output from the show running-config port-forward command:
hostname# show running-config port-forward
port-forward Telnet 3500 10.148.1.5 23


port-forward SSH2 4976 10.148.1.81 22
port-forward SSH2 4977 10.148.1.85 22
port-forward Apps1 10143 flask.CompanyA.com 143
port-forward Apps1 10110 flask.CompanyA.com 110
show running-config ssh

To show the SSH commands in the current configuration, use the show running-config ssh command in privileged
EXEC mode.
Examples
The following example displays the SSH session timeout:
hostname# show running-config timeout

ssh timeout 5 minutes
hostname#
show running-config tftp-server

To display the default TFTP server address and directory, use the show running-config tftp-server command in
global configuration mode.
show running-config tftp-server
Examples
This example shows how to display the IP/IPv6 address of the default TFTP server and the directory of the
configuration file:
hostname(config)# show running-config tftp-server

tftp-server inside 10.1.1.42 /temp/config/test_config
show running-config tunnel-group
To display tunnel group information about all or a specified tunnel group and tunnel-group attributes, use the show
running-config tunnel-group command in global configuration or privileged EXEC mode.
Examples
The following example entered in global configuration mode, displays the current configuration for all tunnel
groups:
hostname<config># show running-config tunnel-group

tunnel-group 209.165.200.225 type IPSec_L2L
tunnel-group 209.165.200.225 ipsec-attributes
pre-shared-key xyzx
hostname<config>#
show running-config username

To display the running configuration for a particular user, use the show running-config username command in
privileged EXEC mode with the username appended. To display the running configuration for all users, use this
command without a username.
Examples
The following is sample output from the show the running-config username for a user named anyuser:
hostname# show running-config username anyuser

username anyuser password .8T1d6ik58/lzXS5 encrypted privilege 3
show service-policy
To display the configured service policies, use the service-policy command in global configuration mode.
show service-policy [global | interface intf] [inspect | ips | police | priority | set connection]
show xlate
To display information about the translation slots, use the show xlate command in privileged EXEC mode.
Examples
The following is sample output from the show xlate command. It shows how translation slot information with three
active PATs.
hostname# show xlate

PAT Global 192.150.49.1(0) Local 10.1.1.15 ICMP id 340
PAT Global 192.150.49.1(1024) Local 10.1.1.15(1028)
PAT Global 192.150.49.1(1024) Local 10.1.1.15(516)
shutdown
To disable an interface, use the shutdown command in interface configuration mode. To enable an interface, use the
no form of this command.
shutdown
no shutdown
Examples\
The following example enables a main interface:
hostname(config)# interface gigabitethernet0/2

hostname(config-if)# speed 1000
hostname(config-if)# duplex full
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 10.1.1.1 255.255.255.0
hostname(config-if)# no shutdown
ssh
To add SSH access to the security appliance, use the ssh command in global configuration mode. To disable SSH
access to the security appliance, use the no form of this command. This command supports IPv4 and IPv6 addresses.
Usage Guidelines
The ssh ip_address command specifies hosts or networks that are authorized to initiate an SSH connection to the
security appliance. You can have multiple ssh commands in the configuration. The no form of the command
removes a specific SSH command from the configuration. Use the clear configure ssh command to remove all SSH
commands.
Before you can begin using SSH to the security appliance, you must generate a default RSA key using the crypto
key generate rsa command.
The following security algorithms and ciphers are supported on the security appliance:
3DES and AES ciphers for data encryption
HMAC-SHA and HMAC-MD5 algorithms for packet integrity
RSA public key algorithm for host authentication
Diffie-Hellman Group 1 algorithm for key exchange
The following SSH Version 2 features are not supported on the security appliance:
X11 forwarding
Port forwarding
SFTP support
Kerberos and AFS ticket passing
Data compression
Examples
The following example shows how to configure the inside interface to accept SSH version 2 connections from a
management console with the IP address 10.1.1.1. The idle session timeout is set to 60 minutes and SCP is enabled.
hostname(config)# ssh 10.1.1.1 255.255.255.0 inside

hostname(config)# ssh version 2
hostname(config)# ssh copy enable
hostname(config)# ssh timeout 60
What is port forwarding
In this example, we want to be able to access a web server behind the firewall. We'll assume you are using the
standard HTTP port, the web server's internal IP address is 10.9.8.7/24, and that you at least know what you're doing
enough to be configuring an ASA in the first place. I'll give you the steps, then I'll explain.
Step 1: Create a new object group for you web server.
asa5505(config)# object network Webserver
Step 2: Add the IP of the web server to the network group.
asa5505(config-network-object)# host 10.9.8.7
Step 3: Forward the port via the NAT command.
asa5505(config-network-object)# nat (inside,outside) static interface service tcp www www
Step 4: Exit back to the root and add the access list
asa5505(config)# access-list outside_access_in permit tcp any object Webserver eq www
Using the fixup Command
You can use the fixup command to change the default port assignments or to enable or disable application
inspection for the following protocols and applications:
FTP
H.323
HTTP
ILS
RSH
RTSP
SIP
SKINNY (SCCP)
SMTP
SQL*Net
The basic syntax for the fixup command is as follows:
[no] fixup protocol [protocol] [port]
To change the default port assignment, identify the protocol and the new port number to assign. Use the no fixup
protocol command to reset the application inspection entries to the default configuration.
Note Disabling or modifying application inspection only affects connections that are initiated after the command is
processed. Disabling application inspection for a specific port or application does not affect existing connections. If
you want the change to take effect immediately, enter the clear xlate command to remove all existing application
inspection entries.
The following is the detailed syntax of the fixup command showing the syntax for each configurable application:
fixup protocol ftp [strict] [port] | http [port[-port]] | h323 [port[-port]] | ils
[port[-port]] | rsh [514] | rtsp [port] | sip [5060] | skinny [port] | smtp [port[-port]] |
sqlnet [port[-port]]
You can view the explicit (configurable) fixup protocol settings with the show fixup command. The default settings
for configurable protocols are as follows.
show fixup
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521

fixup protocol sip 5060
The default port value for rsh cannot be changed, but additional port statements can be added.
The show fixup protocol protocol command displays the configuration for an individual protocol.
The following are other related commands that let you manage fixup configuration:
show conn stateDisplays the connection state of the designated protocol
show timeoutDisplays the timeout value of the designated protocol
The clear fixup command removes fixup commands from the configuration that you added. It does not remove the
default fixup protocol commands.
You can disable the fixup of a protocol by removing all fixups of the protocol from the configuration using the no
fixup command. After you remove all fixups for a protocol, the no fixup form of the command or the default port is
stored in the configuration.
For some applications, you can define multiple port assignments. This is useful when multiple instances of the same
service are running on different ports.
The following example shows how to define multiple ports for FTP by entering separate commands:

These commands do not change the standard FTP port assignment (21). After entering these commands, the
PIX Firewall listens for FTP traffic on port 21, 2100, 4254, and 9090.
Some protocols let you assign a range of ports. This is indicated in the command syntax as port[-port]. For example,
the following command assigns the port range from 1500 to 2000 to SQL*Net.
fixup protocol sqlnet 1500-2000
Static NAT/PAT
Pre-8.3 NAT
8.3 NAT
Regular Static NAT

static (inside,outside) 192.168.100.100 10.1.1.6 netmask
255.255.255.255
Regular Static PAT
static (inside,outside) tcp 192.168.100.100 80 10.1.1.16 8080
netmask 255.255.255.255

host 10.1.1.6
host 10.1.1.16
service tcp 8080 www
Static Policy NAT

access-list NET1 permit ip host 10.1.2.27 10.76.5.0
255.255.255.224
static (inside,outside) 192.168.100.100 access-list NET1
Pre-8.3 NAT
host 10.1.2.27
host 192.168.100.100
subnet 10.76.5.0 255.255.255.224
nat (inside,outside) source static obj-10.1.2.27
obj-192.168.100.100
destination static obj-10.76.5.0 obj10.76.5.0
8.3 NAT

subnet 192.168.1.0 255.255.255.0
nat (inside) 1 192.168.1.0 255.255.255.0
nat (dmz) 1 10.1.1.0 255.255.255.0
global (outside) 1
subnet 10.1.1.0 255.255.255.0
192.168.100.100
nat (dmz,outside) dynamic 192.168.100.100
Regular Dynamic PAT
Regular Dynamic PAT

nat (inside) 1 10.1.2.0 255.255.255.0
global (outside) 1 192.168.100.100
global (dmz) 1 192.168.1.1

subnet 10.1.2.0 255.255.255.0
object network obj-10.1.2.0-01
subnet 10.1.2.0 255.255.255.0
nat (inside,dmz) dynamic 192.168.1.1
Regular Dynamic PAT-3
nat (inside) 1 0 0
object network obj_any

subnet 0.0.0.0 0.0.0.0
nat (inside,outside) dynamic interface
Dynamic Policy NAT
object-group network og-net-src

network-object 192.168.1.0
255.255.255.0
255.255.255.0
object-group network og-net-dst
255.255.255.0
object-group service og-ser-src
service-object tcp gt 2000
service-object tcp eq 1500
access-list NET6 extended permit
object-group og-ser-src
object-group og-net-src
object-group og-net-dst
nat (inside) 10 access-list NET6
global (outside) 10 192.168.100.100
Policy Dynamic NAT (with multiple
ACEs)
access-list ACL_NAT permit ip

172.29.0.0 255.255.0.0
192.168.1.0
255.255.255.0
172.29.0.0 255.255.0.0
192.168.2.0
255.255.255.0

host 192.168.100.100
object service obj-tcp-range-2001-65535
service tcp destination range 2001 65535
object service obj-tcp-eq-1500
service tcp destination eq 1500
nat (inside,outside) source dynamic og-net-src
obj-192.168.100.100 destination
static og-net-dst og-net-dst
service obj-tcp-range-2001-65535
obj-tcp-range-2001-65535
nat (inside,outside) source dynamic og-net-src
obj-192.168.100.100 destination
static og-net-dst og-net-dst
service obj-tcp-eq-1500 obj-tcp-eq-1500

subnet 172.29.0.0 255.255.0.0
host 192.168.100.100
subnet 192.168.1.0 255.255.255.0
subnet 192.168.2.0 255.255.255.0
subnet 192.168.3.0 255.255.255.0

172.29.0.0 255.255.0.0
192.168.3.0
255.255.255.0
172.29.0.0 255.255.0.0
192.168.4.0
255.255.255.0
nat (inside) 1 access-list ACL_NAT
global (outside) 1 192.168.100.100
Outside NAT
global (inside) 1 10.1.2.30-1-10.1.2.40
nat (dmz) 1 10.1.1.0 255.255.255.0
outside
static (inside,dmz) 10.1.1.5 10.1.2.27
netmask 255.255.255.255
NAT & Interface PAT together

nat (inside) 1 10.1.2.0 255.255.255.0
global (outside) 1 192.168.100.100192.168.100.200
NAT & Interface PAT with additional
PAT together
nat (inside) 1 10.0.0.0 255.0.0.0
global (outside) 1 192.168.100.1192.168.100.200
global (outside) 1 192.168.100.210

subnet 192.168.4.0 255.255.255.0
nat (inside,outside) source dynamic obj-172.29.0.0 obj-192.168.100.100

destination static obj-192.168.1.0 obj-192.168.1.0
host 10.1.2.27
nat (inside,dmz) static 10.1.1.5
subnet 10.1.1.0 255.255.255.0
nat (dmz,inside) dynamic obj-10.1.2.30-10.1.2.40
object network obj-10.1.2.30-10.1.2.40
range 10.1.2.30 10.1.2.40
object network obj-192.168.100.100_192.168.100.200
range 192.168.100.100 192.168.100.200
subnet 10.1.2.0 255.255.255.0
nat (inside,outside) dynamic
obj-192.168.100.100_192.168.100.200 interface
object network obj-192.168.100.100_192.168.100.200
range 192.168.100.100 192.168.100.200
subnet 10.0.0.0 255.0.0.0
object network second-pat
host 192.168.100.210
object-group network dynamic-nat-pat
network-object object obj-192.168.100.100_192.168.100.200
network-object object second-pat
nat (inside,outside) dynamic dynamic-nat-pat interface
Twice NAT with both source IP, Dest IP

object network source-real
and Source port, Dest port change.
On the inside:
Source IP: 10.30.97.129
host 10.30.97.129
object network dest-mapped

host 10.30.97.200
Dest IP: 10.30.97.200

object network dest-real
Source port: 5300
host 172.16.1.10
Dest port: any port
object service inside-src-dest-port
service tcp source eq 5300 destination range 0 65535
On the outside:
object service outside-src-dest-port
Source IP: Interface IP
service tcp source eq 5300 destination eq 1022
Dest IP: 172.16.1.10

Source port: 5300
Dest port: 1022
nat (inside,outside) after source static source-real interface destination

static dest-mapped dest-real service inside-src-dest-port outside-src-destport
(in)
(out)
10.1.1.1-------ASA------xlate-------> 10.2.2.2
Static NAT for a Range of Ports
Original Ports: 10000 - 10010

Translated ports: 20000 - 20010
Not Possible - Need to write multiple

Statements or perform a Static one-toone NAT
object service ports

service tcp source range 10000 10010
object service ports-xlate
service tcp source range 20000 20010
object network server

host 10.1.1.1
object network server-xlate

host 10.2.2.2
nat (inside,outside) source static server server-xlate service ports portsxlate

Firewall

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Firewall

Uploaded by

Copyright:

Available Formats

Here are the individual steps in detail:

1. Packet is reached at the ingress interface.

Capture Command at ASA

TCP (Transmission Control Protocol) communication between applications

TCP Uses a Fixed Connection

IP is for communication between computers.

TCP/IP is TCP and IP working together.

TFTP does not encrypt nor authenticate. It is not a secure protocol.

NetBIOS Remote Machine Name Table

--------------------------------------------2159A-H7-SITA <00> UNIQUE

2159A-H7-SITA <20> UNIQUE

MAC Address = 00-1A-A0-C2-9B-01

Active/Standby Failover in Single Mode

Figure 11-4. Deployment Scenario Using Active/Standby Failover

Configuration of Primary Cisco ASA

Chicago# show run

! Failover is enabled and the unit is acting as a Primary device

failover lan unit secondary

Monitoring and Troubleshooting Failovers

Chicago(config)# show failover

Beginning configuration replication: Sending to mate.

209.165.200.225 255.255.255.224 CONFIG

209.165.200.226 255.255.255.224 CONFIG

Chicago# show failover

This host: Secondary - Standby Ready

slot 1: ASA-SSM-10 hw/sw rev (1.0/5.0(2)S152.0) status (Up)

VPN IPSEC upd 30

VPN CTCP upd

VPN SDI upd

Logical Update Queue Information

Q. What is the difference between gateway and firewall?

Q. A traceout command work across the firewall? why?

Q.Identify the true statements in below

Q.What are considered parts of the IOS Firewall feature set?

Q.What is Authentication Proxy.

Answer: show service-policy

What Triggers a Failover?

ASA Syslog Level vs. Number of Messages

Ip verify reverse-path command is used to stop ip spoofing.

!--- The above NAT statements are replaced by the following

object network obj-192.168.1.0

static (inside,outside) 192.168.1.100 172.22.1.254 netmask

!--- The above Static NAT statement is replaced by the following

object network obj-172.22.1.254

message-length maximum 512

Source IP addressThis is typically the work station or computer of the user.

!--- Output is suppressed.

%ASA-6-302020: Built ICMP connection for faddr 192.168.1.50/512

!--- The user IP address is 192.168.1.50.

ASA Capture Feature

ciscoasa(config)#access-list inside_test permit icmp any host 192.168.1.1

!--- The user IP address is 192.168.1.50.

!--- Output is suppressed.

ICMP echo request from 192.168.1.50 to 192.168.1.1 ID=512 seq=5120 len=32

!--- The user IP address is 192.168.1.50.

In order to disable debug icmp trace, use one of these commands:

undebug icmp trace

!--- Output is suppressed.

%ASA-7-609001: Built local-host inside:192.168.1.50

!--- This ACL line captures all traffic from 192.168.1.50

ciscoasa(config)#access-list inside_test permit ip any host 192.168.1.50 any

!--- This ACL line captures all traffic that leaves

ciscoasa(config)#no access-list inside_test permit icmp any host 192.168.1.1

!--- Clears the previously logged data.