![\"\"](\"http:\/\/blogs-new.it.ox.ac.uk\/networks\/files\/2011\/01\/firewall-test-jan-20111.png\")
<\/a><\/p>\nWith 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)<\/p>\n
interface Vlan5\r\n description internal ipv6 network\r\n ipv6 address 2001:630:440:400::1\/64\r\n!\r\nipv6 route ::\/0 2001:630:440:400::EE<\/span>\r\n<\/pre>\n…plus the etherchannel and interface vlan memberships which if the above made sense to you, you are most likely already familiar with.<\/p>\n
On the red\/outside switches<\/p>\n
interface Vlan4\r\n description outside networks\r\n ipv6 address 2001:630:440:401::1\/64\r\n!\r\nipv6 route 2001:630:440:400::\/64 2001:630:440:401::EE\r\n<\/span><\/pre>\n…again, plus the etherchannel and interface vlan memberships which are as expected.<\/p>\n
Interfaces<\/h3>\n
On the ASA themselves the major important parts are firstly the interfaces:<\/p>\n
!\r\ninterface Ethernet0\/0\r\n description RED (outside) to 3750-1\r\n nameif outside\r\n no ip address\r\n ipv6 address 2001:630:440:401::ee\/64 standby 2001:630:440:401::ed\r\n ipv6 enable\r\n!\r\ninterface Ethernet0\/1\r\n description GREEN (inside) to 2960-1\r\n nameif inside\r\n ipv6 address 2001:630:440:400::ee\/64 standby 2001:630:440:400::ed\r\n ipv6 enable\r\n!<\/span>\r\n<\/pre>\nJust put the above one one ASA of the pair. I left off a management interface for this test as it wasn’t needed.<\/p>\n
Failover Link<\/h3>\n
Then it’s a case of configuring the failover link<\/p>\n
On the ASA that you configured the interfaces on, set it as the initial primary unit in the pair<\/p>\n
failover lan unit primary<\/span><\/pre>\nThen configure the failover interface<\/p>\n
failover lan interface FOCtrlIntf Ethernet0\/3\r\nfailover key *****\r\nfailover link FOCtrlIntf Ethernet0\/3\r\nfailover interface ip FOCtrlIntf 2001:630:440:402::1\/64 standby 2001:630:440:402::ee\r\nfailover<\/span>\r\n<\/pre>\nType 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.<\/p>\n
Firewall Rules<\/h3>\n
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:<\/p>\n
ipv6 access-list inbound remark test acl\r\nipv6 access-list inbound permit icmp6 any any\r\nipv6 access-list inbound permit ip any any\r\nipv6 access-list outside remark test outside acl\r\nipv6 access-list outside permit icmp6 any any\r\nipv6 access-list outside permit ip any any\r\naccess-group outside in interface outside\r\naccess-group inbound in interface inside<\/span><\/pre>\nand 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.<\/p>\n
ipv6 icmp permit any outside\r\nipv6 icmp permit any inside<\/span>\r\n<\/pre>\nHTTP Gotcha<\/h3>\n
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:<\/p>\n
“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.”<\/p><\/blockquote>\n
The command to enable it is<\/p>\n
failover replication http<\/span><\/pre>\n…after which http transfers during a failover condition will continue fine.<\/p>\n
Testing<\/h3>\n
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).<\/p>\n
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.<\/p>\n
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.<\/p>\n
Conclusion<\/h3>\n
Everything worked fine. Yes, you may already be aware of this, but we wanted to test to be sure before considering making any purchase.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading