Packet captures are very useful for troubleshooting purposes. The Cisco ASA supports packet captures even in multiple context mode. I normally configure packet captures on CLI level. This can be done by configuring an access-list to match the specific traffic you would like to capture. Add the access-list and the specific interface in a capture command. Mostly I download the capture in raw format for further analysis with a tool like WireShark. The capture can be downloaded via TFTP or via a secure connection (HTTPS) to the Cisco ASA firewall.
When running a Cisco ASA in multiple context mode, I always disable the ability to connect directly to a context for management purposes. That way you have to access the admin context for management access, but this also denies the option to download the capture via a secure connection directly from the Cisco ASA traffic context.
The easiest way to download the capture in multiple context mode is via a TFTP transfer from the system context. Check the example command below. The capture is made within the context named contextA and the capture has the name captureA. The following command can be used to download the capture in raw (pcap) format.
copy /pcap capture:contextA/captureA tftp://10.10.10.10/captureA.pcap
You can now analyse the capture with WireShark
“Normal” TCP applications use a three-way handshake to establish a session. After data has been send the session is closed. Some legacy applications don’t always close a TCP session. They keep the session open, even when the session is idle for a long time (+ 2 hours). When the session is idle and a client wants to send data, the clients sends a PSH packet followed by the new data. Both stations use the original session information to maintain the connection.
This behavior is problematic when components, like firewalls are along the path between the two clients. A Cisco ASA firewall for example automatically flushes a TCP session when it’s idle for 1 hour. When the clients start sending data after an idle period of 1 hour, by starting with a PSH command, the firewall doesn’t recognize the session anymore and drops the traffic. Both clients need to flush / restart their TCP session to establish a new valid session through the firewall.
The Cisco ASA firewall has the option to change the default idle timers and even send a reset (RSET) to both clients when the idle timer is reached. The Reset bit in TCP is designed to allow a client to abort / terminate the TCP session with another client. This forces both clients to re-establish a new session, which is learned and maintained by the firewall. This prevents a session from getting dropped in the firewall when it’s idle for more than one hour.
To configure a TCP reset you need to specify the “interesting” traffic for a reset through an access-list and specify the reset parameters via a policy-map like shown below.
access-list reset_tcp extended permit ip 192.168.10.0 255.255.255.0 host 10.10.10.205
match access-list reset_tcp
set connection timeout idle 0:15:00 reset
The configuration snippet resets a connection when it’s idle for 15 minutes between the network 192.168.10.0/24 and the host 10.10.10.205. The sessions are initiated by the remote network. You can view the connection parameters with the show conn command.
fw01# show conn address 192.168.10.2 address 10.10.10.205 detail
TCP DMZ:192.168.10.2/31731 Inside:10.10.10.205/4000,
flags UIOB, idle 3m11s, uptime 51m56s, timeout 15m0s, bytes 165157
The output shows the configured idle timeout of 15 minutes, the real idle timeout and the uptime of the connection.
While trying to perform a password recovery on a Cisco ASA, I noticed that the password recovery feature was disabled on the appliance. Without the password recovery feature enabled, you can recover the Cisco ASA, but the file system will be wiped completely.
During the boot of the Cisco ASA you need to press ESC to enter rommon and you will receive the following warning.
WARNING: Password recovery and ROMMON command line access has been
disabled by your security policy. Choosing YES below will cause ALL
configurations, passwords, images, and files systems to be erased.
ROMMON command line access will be re-enabled, and a new image must be downloaded via ROMMON.
Erase all file systems? y/n [n]: y
Permanently erase Disk0: and Disk1:? y/n [n]: y
All data from disk0: will be erased after which you will gain access to the rommon of the appliance. To perform the full recovery you need to enter the following commands:
rommon #0> interface <interface id>
rommon #1> address <IP address>
rommon #2> file <image name>
rommon #3> server <IP address TFTP server>
rommon #4> tftp
The new image will be loaded to the Cisco ASA appliance and the appliance will boot with its default configuration. After the Cisco ASA is booted you have the format disk0:. When you issue the show disk0: command before the format, you will notice that there is no free space on the disk. After the format you need to upload the appropriate ASA and ASDM image.
Be aware that after performing a full recovery the previous VPN-3DES-AES activation keys and other licenses will be lost. You can get a new activation key at http://www.cisco.com/go/license.
I needed to configure a site-to-site VPN connection between a Juniper SSG firewall and a Cisco ASA firewall. The configuration of a VPN connection is very straightforward, but this time the networks behind the firewalls are overlapping.
I have configured the Cisco ASA multiple times in such scenario, but the configuration of the Juniper SSG was new for me. I found a good article in the Juniper Knowledge Base. The article helped me to configure the VPN connection on the Juniper SSG firewall. The “tricky” part is the configuration of the MIP’s on the tunnel interface and the policy from the VPN network to the Trust network.
The only difference in my configuration is the definition of proxy ID’s within the VPN profile configuration. My scenario involves multiple subnets behind the Juniper SSG firewall en behind the Cisco ASA firewall. For every combination of subnets (Security Association) you have to configure a separate tunnel interface and VPN profile.
By default, remote access VPN users aren’t able to manage a Cisco ASA firewall on the inside interface using any kind of management protocol (SSH, telnet, HTTPS).
You can enable remote management by specifying the management-access interface. You can specify the interface via the CLI or via the Cisco Adaptive Security Device Manager (ASDM). Both methods are specified below.
fw01/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# management-access inside
When using the Management Access feature with remote VPN connections (IPSec or SSL VPN) don’t forget to add the VPN pool to the corresponding management access protocols on the interface you specified as management access interface