Booches.nl

McAfee Firewall – NAT mapping

While testing a McAfee Enterprise Firewall running software 8.2.0, I had some problems with the creation of a NAT mapping. The firewall is configured as standalone firewall. All (NAT / access rule) configuration on the firewall is done using Access Control Rules. McAfee uses two types of NAT mapping:

1. 1. NAT: mostly used to translate a private IP address to a public IP address;
2. 2. Redirect: redirect traffic to a public IP address to a private IP address;

I tried to publish an internal network component to the internet. I created a simple rule with the following parameters. These parameters are very straightforward and the configuration is similar to firewalls from different vendors:

I tested the NAT mapping, but couldn’t connect to the internal component using the public IP address. The first step in troubleshooting is looking at the logging, but I couldn’t find any logging on the firewall. It looked like the traffic didn’t even reach the firewall.

We have a shared internet segment with multiple firewalls. So I started doubting the configuration of the different firewalls.

• Was somebody already using the public IP address in a NAT configuration?
• Has the default gateway of the internet segment already an ARP entry for the public IP address?

I looked at the configuration of the firewalls, but nobody was using the public IP address. With this in mind, I ruled out the ARP entry “problems” on the ISP router.

When using NAT on a public IP address, which isn’t the same as the interface IP address, the firewall has to proxy ARP the public IP address. So does the firewall proxy ARP for the public IP address?

I started looking at the rest of the configuration with emphasis on the network configuration. I noticed that I had the option to add an alias IP address to the external interface. This can be found under Network – Interfaces – external interface. I added the public IP address as alias.

You guessed it. The NAT mapping is working……

Cisco ASA – Reset TCP connection

“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

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.

ISA Server 2006 array – renew certificate

When configuring a Microsoft ISA Server 2006 array you have two options for authentication and communication between the Microsoft ISA 2006 Configuration Storage Server and the array members.

• Windows Authentication: Choose this option if ISA server and the Configuration Storage server are in the same domain, or in different domains with a trust relationship between them. The connection will be encrypted (signed and sealed);
• Authentication over SSL encrypted channel: Choose this option if ISA server is in a domain that does not have a trust relationship with the Configuration Storage server domain, or if it is part of a workgroup. The connection will be SSL encrypted.

I normally configure the array members within a DMZ environment en install the CSS server on the internal network.

To maximize the security the array members aren’t part of the Active Directory. So communication between the CSS and the array members is workgroup based and the authentication type used is Authentication over SSL encrypted channel. This option needs the configuration of SSL certificates to authenticate and secure the connection. The certificates have a certain validity period, after which the certificate needs to be renewed.

Normally I always ran the repair option from the installation and specified the new certificate. I discovered a new and simpler method by using the ISACertTool. This tool provides an easy way to renew the certificate on the Configuration Storage Server and the root CA certificate on the array members.

You just need to create a web server certificate in pfx format from a Windows CA server of any other CA server. If the CA server isn’t trusted by the array members, you need to install the CA certificate on the array members. If you use trusted CA server certificate, you can skip this step.

The syntax for the ISACertTool is very straightforward. On the Configuration Storage Server you need to run the following command:

ISACertTool.exe /st <pfx file> /pswd <password> /keepcerts

On the array member you run the following command to install the root CA certificate.

ISACertTool.exe /fw <root ca file>

IMPORTANT: for a correct usage of the tool you need to extract the tool to the Microsoft ISA Server install directory, which is by default C:\Program Files\Microsoft ISA Server.

Juniper SSG to Cisco ASA VPN with overlapping subnets

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.