| Follow me on:

Cisco ASA – Reset TCP connection

August 22nd, 2011 | No Comments

“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
!
class-map cm_reset_tcp
match access-list reset_tcp
!
policy-map global_policy
class cm_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.

Cisco ASA – Full recovery

May 24th, 2011 | No Comments

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.

Juniper SSG to Cisco ASA VPN with overlapping subnets

March 29th, 2011 | No Comments

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.

Cisco ASA remote management via VPN

February 14th, 2011 | 1 Comment

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.

CLI

fw01/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# management-access inside

ASDM

asa-management

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

Cisco ASA NPE image

January 4th, 2011 | 1 Comment

I got complains from a customer who wasn’t able to configure 3DES or AES encryption for a VPN tunnel. Sounds familiar with a problem I had a couple of weeks ago. So I gave the customer the advice to upgrade and activate the VPN-3DES-AES feature. He tried but that didn’t solve this problem.

I remotely logged in and checked the software he was using. I noticed he was using the image asa832-npe-k8.bin. Problem found!!!

NPE stands for No Payload Encryption. For export to some countries, payload encryption cannot be enabled on the Cisco ASA 5500 series. For version 8.3(2), you can now install a No Payload Encryption image (asa832-npe-k8.bin).

Features that are disabled in the No Payload Encryption image include:

  • Unified Communications;
  • Strong encryption for VPN (DES encryption is still available for VPN);
  • VPN load balancing (note that the CLI is still present; the feature will not function, however)
  • Downloading of the dynamic database for the Botnet Traffic Filer (Static black and whitelists are still supported. Note that the CLI is still present; the feature will not function, however);
  • Management protocols requiring strong encryption, including SSL, SSHv2, and SNMPv3. You can, however, use SSL or SNMPv3 using base encryption (DES). Also, SSHv1 and SNMPv1 and v2 are still available;

If you attempt to install a Strong Encryption (3DES/AES) license, you see the following warning:

WARNING: Strong encryption types have been disabled in this image; the VPN-3DES-AES license option has been ignored.

I replaced the software image with the regular image and the problem was solved.