Network Development Team

There was some debate on the Cisco ASA failover situation with regard to IPv6. Since we’re potentially about to make a interim firewall purchase for the main university IPv6 traffic (we route IPv6 separately to IPv4 to avoid a limitation of the older FWSM firewall modules that currently handle the Universities IPv4 traffic) we tested the capabilities to ensure they matched what was required – namely stateful failover of IPv6 traffic. In laymans terms: your communications with the Internet over IPv6 shouldn’t be interrupted when one firewall is unplugged.

We’ve enough equipment to be able to test, so I setup an airgapped network using IPv6 only, roughly mimicking a basic dual site setup. In production it would hopefully have redundant crosslinks and a fibre would be used to connect between the ASAs due to the physical distance of being located at two separate sites (in case one burns down or similar). I used addresses from our public provision but there were no physical connections from the test network. The  ASAs need matching software, I applied 8.3(2) although I’ve since been told that anything from 8.2.2 onwards should match my results – obviously I can only confirm the version I tested. The ASA 5510 upwards have identical software/commands so this test should be valid for 5520s, 5540s etc, it’s the smaller 5505 that is different to the rest of the range in some ways.

I am not a Cisco expert, my own background is system administration, so some of the test was perhaps needlessly complex (the dual switches at each end) but was useful for my own switch revision and practise. If I’ve accidentally left out any configuration from my test writeup that you think would be helpful for people, let me know in the comments and I’ll add it in (the intended audience is IT officers in colleges or departments). The basic plan looked like:

With the switches involved there was one firmware difference which I ignored, also the configuration of the switches isn’t important, however on the green/inside 2960 I used (on one of them)

interface Vlan5
 description internal ipv6 network
 ipv6 address 2001:630:440:400::1/64
!
ipv6 route ::/0 2001:630:440:400::EE

…plus the etherchannel and interface vlan memberships which if the above made sense to you, you are most likely already familiar with.

On the red/outside switches

interface Vlan4
 description outside networks
 ipv6 address 2001:630:440:401::1/64
!
ipv6 route 2001:630:440:400::/64 2001:630:440:401::EE

…again, plus the etherchannel and interface vlan memberships which are as expected.

Interfaces

On the ASA themselves the major important parts are firstly the interfaces:

!
interface Ethernet0/0
 description RED (outside) to 3750-1
 nameif outside
 no ip address
 ipv6 address 2001:630:440:401::ee/64 standby 2001:630:440:401::ed
 ipv6 enable
!
interface Ethernet0/1
 description GREEN (inside) to 2960-1
 nameif inside
 ipv6 address 2001:630:440:400::ee/64 standby 2001:630:440:400::ed
 ipv6 enable
!

Just put the above one one ASA of the pair. I left off a management interface for this test as it wasn’t needed.

Failover Link

Then it’s a case of configuring the failover link

On the ASA that you configured the interfaces on, set it as the initial primary unit in the pair

failover lan unit primary

Then configure the failover interface

failover lan interface FOCtrlIntf Ethernet0/3
failover key *****
failover link FOCtrlIntf Ethernet0/3
failover interface ip FOCtrlIntf 2001:630:440:402::1/64 standby 2001:630:440:402::ee
failover

Type exactly the same failover configuration in the above section on the second ASA (e.g. excluding the ‘primary’ statement). Don’t swap the interface addresses around when configuring the second device or it wont work. You should see a message saying it’s found the second ASA and it’s mirroring the configuration across. You no longer need to type any configuration on the secondary (non active ASA), and it will warn you if you attempt to do so.

Firewall Rules

I don’t care about firewall rules for this test, but we want to pass traffic. Obviously on a production system you probably have some more restrictive rules in mind:

ipv6 access-list inbound remark test acl
ipv6 access-list inbound permit icmp6 any any
ipv6 access-list inbound permit ip any any
ipv6 access-list outside remark test outside acl
ipv6 access-list outside permit icmp6 any any
ipv6 access-list outside permit ip any any
access-group outside in interface outside
access-group inbound in interface inside

and I’d like to be able to ping the firewall interfaces themselves while setting up the network in case of human error on my part.

ipv6 icmp permit any outside
ipv6 icmp permit any inside

HTTP Gotcha

Now, if you test sending traffic from a host on the outside to a host on the inside now, all transfers will be fine during failover except http – you have to expressly turn this on. This caught me out initially as SSH transfers continued fine when the network cable was wrenched from the active ASA but http connections died. If I’d set aside some time and read the failover section of the ASA book properly instead of skim reading it this wouldn’t have been a surprise as p539 of the Cisco Press ASA book states:

“HTTP connections usually have a short lifetime and therefore are not replicated by default. Additionally, they add considerable load on the security appliance if the amount of http traffic is large in comparison to other traffic.”

The command to enable it is

failover replication http

…after which http transfers during a failover condition will continue fine.

Testing

I tested by transferring a large file via http and ssh (I used a 120MB file) then removing the network cable from one of the active interfaces on the live ASA. When you pull out the network interface you’ll see a pause of about 2 seconds but the transfer will then continue (the session has not died).

For my test a Windows 7 machine was the client, GNU/Linux from a Live CD was the server, although it was just what I had to hand and shouldn’t make any difference. For these I used 2001:630:440:400::2 on the client and 2001:630:440:401::2 on the server.

Without the http replication feature on you’ll see the transfer hang, despite the secondary ASA having taken over the duties of the first successfully. Without stateful failover in general your users would notice a failover, this is why the state information is needed: to remove impact on your users of a fault.

Conclusion

Everything worked fine. Yes, you may already be aware of this, but we wanted to test to be sure before considering making any purchase.