Configuring ‘Stateless’ Active/Standby failover on an ASA 5505

This post covers the Stateless Active/Standby failover configuration that would normally be done on an ASA 5505 which does not support Stateful failover. ASA 5505 and 5510 are the most commonly used firewalls in the small-medium sized businesses, with the later one supporting Stateful failover. This post only covers the Stateless or Regular failover that would be configured on a ASA 5505 device.

Here’s the network diagram of a typical stateless active/standby failover:

Click to enlarge

FW1 and FW2 will be configured to work in an active/standby failover mode, FW1 being the primary unit and FW2 being the secondary unit of the High Availability pair. Ethernet0/3 on both the firewalls will be serving as the LAN failover interface to propagate the communication between the firewalls about their failover status, synchronizing configuration/commands, etc. You can either use a single switch, two switches or an ethernet crossover cable for you LAN failover interface.

Primary unit configuration (FW1):

1. Configure the device to be the primary unit in the HA pair.

asa(config)# failover lan unit primary

2. Name interface ethernet0/3 as int_fo and this will be the LAN failover interface which will check the health of a failover peer ASA and pass configuration updates between the peers.

asa(config)# failover lan interface int_fo Ethernet0/3

3. Configures LAN failover encryption. Data passing through the failover cable will be encrypted.

asa(config)# failover key mysecretkey

4. Define the failover interface IP for the primary unit ( as well as the secondary unit (

asa(config)# failover interface ip int_fo standby

5. With this we enable the failover feature on the primary unit

asa(config)# failover

6. Assign IPs to the interfaces. The standby keyword assigns the IP that will be used on the secondary unit’s inside/outside interface.

asa(config)# interface Ethernet0/0
asa(config-if)# nameif outside
asa(config-if)# security-level 0
asa(config-if)# ip address standby
asa(config-if)# interface Ethernet0/1
asa(config-if)# nameif inside
asa(config-if)# security-level 100
asa(config-if)# ip address standby

The reason you configure the IP of the secondary unit from the primary using the standby keyword is because, if you configure the IPs on the secondary unit directly, it is any way going to get erased as soon as it starts replicating the config from the primary unit.

The standby values defined in the above configuration will be applied to the secondary units respective interfaces.

Secondary unit configuration (FW2):

1. Below are the only commands you would need on the secondary unit to enable HA/Failover feature between the primary and secondary firewall. Rest of the configuration will be replicated from the primary unit.

asa(config)# failover lan unit secondary
asa(config)# failover lan interface int_fo Ethernet0/3
asa(config)# failover key mysecretkey
asa(config)# failover interface ip int_fo standby
asa(config)# failover

The “failover interface ip” command needs to be put in the exactly same manner on both, the primary and secondary unit. While configuring the secondary unit, you may think of using the first and the at the end, but that is not the case. You have to specify the active IP first and then the standby IP.

Things to note:

  • The terms Primary and Secondary are used only to determine the addressing provided to the firewalls. They do not define the active or standby roles. Either the primary or secondary unit can be in active or standby state.
  • It is recommended that a dedicated interface must be used for the LAN Failover interface. The interface can be connected to an intermediary switch or directly with a crossover cable.
  • By default, all the ASA interfaces are monitored for their health with hello packets. Use the no monitoring-interface int_name global command if you want to remove monitoring for a particular interface.
  • Upon failover, the standby ASA (now active) swaps all interface IP addresses and mac-addresses with the previously active ASA to maintain consistency in the ARP cache.
  • Any command that is explicitly configured on the standby unit will be deleted when the active unit sends its configuration file to the standby unit for replication.
  • Once the devices are in the active/standby mode, changes done on the standby unit will not be replicated on the active unit. If changes are made on the standby unit, they can be discarded when you issue the write standby exec command on the active unit. It discards all the configuration except the failover commands on the standby unit.


ASA Failover/High Availabillity – An overview (terms and concepts)

Failover/High Availability – Two ASAs are paired to operate together and provide redundancy in case of a device failure.

Primary Unit – Determines which of the two ASAs will be referred as the ‘Primary Unit’. Initially, all the configurations are done on the primary unit. It should not be confused with the term ‘active’. The primary unit can either be active or standby.

Secondary Unit – Determines which of the ASAs will be referred as the ‘Secondary Unit’. It should not be confused with the term ‘standby’. The secondary unit can either be active or standby.

Active – The device with the active role will handle all the security functions.

Standby – The unit with the standby role will monitor the active unit for failure and take the active role when a failure occurs.

Failover link – A dedicated link between the two ASAs to propagate communication regarding the failover state, configuration/commands synchronization. Although you can use the already existing data interfaces for the failover related communication, it is not recommended.

Stateful Failover link – A dedicated link between the two ASAs to propagate communication regarding the active TCP/UDP sessions so that they can be replicated on to the standby unit for a stateful failover. Always a separate interface must be used because of the large number of connections that are established/turned down, as the same information is cascaded to the standby ASA in realtime.

Types of failover:

  1. Active/Standby Failover – One ASA take the active role and handles all the normal security functions. The other ASA stays in standby mode and is ready to take over the active role in the event of a failure. This type of failover provides device redundancy.
  2. Active/Active Failover – This can be achieved only when using ASAs in multiple context mode. The contexts can be organized into groups and each ASA is active for one group and standby for the other group. This type of failover provides device redundancy as well as load balancing across contexts.

Stateless failover – The TCP/UDP connections are NOT replicated on the standby unit, this causes the active connections to drop when a failover occurs. Both the above failover types support stateless failover.

Stateful failover – The TCP/UDP connections are replicated on the standby unit, so at the time of failover the standby unit has the TCP/UDP state information and the connections are not dropped. Both the above failover types support stateful failover.

State information replicated in Stateful failover- NAT, ARP, MAC, TCP/UDP connections, H.323 and SIP, MGCP and HTTP (if explicitly enabled).

State information not replicated in Stateful failover- Dynamic routing table entries, uauth cut-through proxy, DHCP leases, Phone proxy and SSM Activity.


  1. Both the units must be of the same model.
  2. Both the units should have Identical sets of interfaces.
  3. Both the units must have the same software configuration and proper license.
  4. Both the units must have the same SSM modules, if any.
  5. Both the units must be in the same mode (transparent/routed, single/multiple context)

The Election Procedure:

  1. While booting, if both ASAs are equally healthy, primary > active and secondary > standby.
  2. While booting, if one is healthier than the other, the healthier one takes the active role.
  3. While booting, if the active role is already assigned, the other ASA takes the standby role.
  4. While booting, if no peer is detected, the booting ASA will become active.

Monitored Interfaces – By default, every ASA interface will be monitored to detect a failure that might trigger a failover. Interfaces can be excluded from monitoring if required.

Monitoring peer’s health:

  1. If hellos are received over the LAN failover interface, the peer is alive and no failover occurs.
  2. If hellos are not received over the LAN failover interface but are received on other monitored interfaces, the peer is alive and no failover occurs. However, the LAN failover interface is declared as “failed” and should be replaced ASAP.
  3. If no hellos are received over any interface, the peer is declared to be “failed” and failover occurs.

Hello packets – Over the LAN failover interface > 1 second
Over other monitored interface > 5 seconds

Hold timer – Over the LAN failover interface > 15 seconds
Over other monitored interface > 5 times the hello timer (25 seconds)

The Interface testing mode – If hello packets are not seen on a monitored interface within ‘half’ of the hold time (25 seconds), that interface is moved into the ‘testing’ mode to determine if a failure has occurred.

  1. Interface Status – If the link is ‘down’, the interface is failed.
  2. Network activity – If no packets are received for 5 seconds, the next testing phase begins. If packets are received, the interface can still be used.
  3. ARP – The interface stimulates received traffic by sending ARP requests . If no traffic is received in 5 seconds, the next testing phase begins.
  4. Broadcast ping – Traffic is stimulated by sending an ICMP echo request to the broadcast address on the interface. If no replies are received in 5 seconds, the interface is marked as “failed”.