Cisco ASA Virtual Context Mode

A single Cisco ASA or a cluster of two ASAs can be partition into multiple virtual firewalls known as security contexts. Each context has it’s own independent firewall, with its own security policy, interfaces, and administrators. These contexts are similar to having multiple standalone ASA devices. In combination with failover groups you can run a ASA cluster in active/active state and utilize both devices. Don’t forget when a failover happens that both failover groups need to run on a single device, keep enough ressources free on both devices and do not oversubscribe too much.

You have to look because there are limitation what features are supported in context mode. In version 8 is unsupport to use dynamic routing protocols, VPN, Threat Detection and Quality of Service. In version 9 are some changes and now dynamic routing protocols (not RIP or OSPFv3) and site-to-site IPsec VPNs are supported.

Here the configuration example how to set-up an Cisco ASA 5580 with 10 Gigabit Ethernet interfaces.

Enabling the context mode

mode noconfirm multiple

Physical interface configuration

interface GigabitEthernet4/2 
  description Failover 
  no shutdown 
  exit 

interface GigabitEthernet4/3 
  description Stateful 
  no shutdown 
  exit 

interface TenGigabitEthernet5/0 
  description TeTrunk-1st 
  no shutdown 
  exit 

interface TenGigabitEthernet5/1 
  description TeTrunk-2nd 
  no shutdown 
  exit

Redundant interface configuration

interface Redundant 1
  description Redundant-Trunk
  member-interface TenGigabitEthernet5/0
  member-interface TenGigabitEthernet5/1
  exit

interface Redundant 1.800
  vlan 800
  description Link-Outside1
  exit

interface Redundant 1.801
  vlan 801
  description Link-Outside2
  exit

interface Redundant 1.100
  vlan 100
  description Link-Inside1
  exit

interface Redundant 1.101
  vlan 101
  description Link-Inside2
  exit

interface Redundant 1.500
  vlan 500
  description Link-Management
  exit

Here you need to start configuring the ASA failover settings. Like you see in the failover group configuration that I put group 1 to the primary device and group 2 to the seconday device for active/active set-up, when I create the virtual security context I join them to the different failover groups.

failover group 1
  primary
  polltime interface 1 holdtime 5
  exit

failover group 2
  secondary
  polltime interface 1 holdtime 5
  exit

failover

failover lan unit primary
failover lan interface failover GigabitEthernet4/2
failover interface ip failover 169.254.0.1 255.255.255.0 standby 169.254.0.2

failover link stateful GigabitEthernet4/3
failover interface ip stateful 169.254.1.1 255.255.255.0 standby 169.254.1.2

failover polltime unit 2 holdtime 6
failover polltime interface 1 holdtime 5
failover timeout 0:00:00

failover active

Failover configuration on the seconday device

interface GigabitEthernet4/2
  description Failover
  no shutdown
  exit

failover lan unit secondary
failover lan interface failover GigabitEthernet4/2
failover interface ip failover 169.254.0.1 255.255.255.0 standby 169.254.0.2

failover

copy running-config startup-config

Now you start to set-up the virtual contexts and add the interfaces I configured before

admin-context admin-asa-01

context admin-asa-01
  allocate-interface Redundant1.500 Link-Management
  config-url disk0:/admin-asa-01.conf
  join-failover-group 1
  exit

context virtual-asa-02
  allocate-interface Redundant1.800 Link-Outside1
  allocate-interface Redundant1.100 Link-Inside1
  config-url disk0:/virtual-asa-02.conf
  join-failover-group 1
  exit

context virtual-asa-03
  allocate-interface Redundant1.801 Link-Outside2
  allocate-interface Redundant1.101 Link-Inside2
  config-url disk0:/virtual-asa-03.conf
  join-failover-group 2
  exit

In the end save the configuration

write memory all

Afterwards you can change to the configured contexts with the command

changeto context virtual-asa-02

and start configuring your virtual firewalls.

Strange VPN behaviour between Juniper ISG and ASA

Always something new what is not working, this time a site-to-site VPN tunnel between a Juniper ISG 2000 and a Cisco ASA 5520. After the initial set-up what a colleague did everything seemed to work fine with the VPN, the tunnel come up and communication was possible. What my colleague not did was to do some intensive testing and check in detail the configuration.

The problems began ones these VPN tunnels were used for production traffic, they worked fine for some hours or maybe days but then suddenly you were not able to send or receive any data over the tunnel and mostly it happen over night where it was difficult to troubleshoot. In the beginning everybody said that it was a problem within the internet but when it happened three or four times a week I got suspicious that its something wrong with the boxes or even configuration.

First thing was to check the configuration and quickly I found a difference in the IPSec Phase2 default timers, the Juniper uses 1 hour and Cisco has 8 hours. I was happy and thought I found the reason for the connectivity problems but then two days later it happened again… 🙁

There where some strange syslog messages about anti-replay checking failed:

ASA-4-402119 IPSEC: Received an ESP packet (SPI= 0xFBEFD496, sequence number= 0x1C24) from 80.210.78.10 (user=80.210.78.10) to 31.217.30.132 that failed anti-replay checking.

These messages always came when we had the connectivity problems and that could be only now the last reason. I have to say I didn’t really found much but there were some articles that Juniper doesn’t support Cisco Anti-Replay checking and that you need to disable that on the Cisco side.

Here a release note I found from Juniper but it’s about Cisco’s GET VPN:

http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/index.html?topic-53319.html

In the end that was the only thing I found and I thought give it a try and disable the anti-replay checking on the ASA when we had the problems again. I did so I waited until the problem happened again and disable the anti-replay checking with the following command:

crypto ipsec security-association replay disable

It’s global command were you disable the checking for the whole device. Here some more information:

http://www.cisco.com/en/US/docs/security/asa/asa81/command/ref/c5.html#wp2200043

When I disabled the checking the communication was suddenly possible again and since then the problem never happened again so the anti-replay checking was the cause of the connection problems between the Juniper and the Cisco. Always something new to learn 🙂

Cisco ASA TCP Syslog Problem

I ran today into a big problem with configuring an TCP syslog server on an Cisco ASA.

logging host "interface_name" "server_ip" tcp/514

After I put in the configuration and someone from the server administration restarted the syslog server and suddenly the whole communication through the ASA stopped working completely.

I saw the following messages in the ADSM and quickly realised that this could be only caused by the TCP logging configuration.

%ASA-3-201008: Disallowing new connections

I didn’t looked before if the feature is disabled to block new connections when a TCP-connected syslog server is down. This is very important that you disable the feature before you configure TCP syslog servers otherwise you ran into the same problem like me.

Here the command to disable the feature:

logging permit-hostdown

In my case I just forgot to check before and will definitively remember for the next time 😉

Bug in Cisco ASA 8.4(4)1 found

I had a new office set-up in Sao Paulo/Brazil and found a bug what should be already fixed but still exists. You cannot access the management interface (inside) of your ASA when you come over an L2L/RemoteAccess VPN and your NAT statements overlaps the management ip address.

It’s an split-tunneling configuration where VPN traffic keeps the original IP address and when you go into the internet you will translated to the outside IP address. Have a look here at the cisco bug CSCtr16184

I used the following config what didn’t work:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs

When you use the NAT statements described in the workaround it works fine:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs route-lookup
nat (outside,inside) source static vpn-subs vpn-subs destination static inside-subs inside-subs route-lookup

This behavior should be already fixed in version 8.4(2.3) but in my 8.4(4)1 it still exists.

Here the bug details from Cisco:

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.

Symptom:

After upgrading the ASA to 8.4.2, all management traffic to-the-box(including icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may fail when destined to the management-access interface IP address.

Conditions:

1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1.
2. Users directly connected to the internal interfaces face no issues with icmp/telnet/ssh/asdm to their respective interfaces.

Workaround:

The problem can be traced to a Manual NAT statement that overlaps with the management-access interface IP address. The NAT statement must have both the source and destination fields. Adding the “route-lookup” keyword at the end of the NAT statement resolves the issue.