Introduction

This document describes the how target failover in AWS, along with Cisco Secure Firewall clustering, provides connection resilience.

Both physical and virtual Cisco Secure firewalls offer clustering capabilities. The cluster contains two copies of each entry in the connection table: there is a flow owner and backup flow owner for each flow. Therefore, at least in principle, the cluster can provide connection resilience across cluster node failure.

However, the cluster relies on the network infrastructure to rebalance the existing flows across the remaining healthy nodes. Virtual environments present a particular challenge because of the behavior of cloud-native load balancers.

In October 2022, AWS has recently introduced a feature on its gateway load balancer called target failover (disabled by default). In combination with Cisco Secure Firewall clustering, this feature provides connection resilience across cluster node failure.

Cisco Support for AWS Target Failover

Cisco introduced clustering of Cisco Secure Firewalls in AWS in the 7.2 release. This included support for deploying a firewall cluster behind a gateway load balancer. Since the cluster natively supports connection resilience, AWS target failover works with the 7.2 release.

However, Cisco did not officially support AWS target failover was not ** until the 7.4 release. This has two implications.

• Cisco extensively tested AWS target failover leading up to the 7.4 release.
• Gateway load balancer target groups created by the Cloud Formation and Terraform templates associated with the 7.4 release have the correct configuration. This requires setting certain target group attributes discussed later in this document.

Clustering Cisco Secure Firewalls in the Public Cloud

Clustering is a way to combine multiple Cisco Secure Firewalls into a single logical firewall.

Clustering has been available on the Cisco Secure Firewall since the 6.0.1 release. Clustering serves two purposes.

• Scaling. Scale throughput using a pay-as-you-grow models.
• Connection level resilience. Existing connections can survive a single cluster node failure.

To achieve both scaling and redundancy, Cisco recommends an N+1 model, meaning that if you demand the throughput provided by an N node cluster, you deploy N+1 nodes to ensure sufficient throughput in case of a single node failure.

A major difference between physical and virtual firewall clustering is the interface-mode:

• Spanned interface-mode. An interface across the cluster has a shared virtual IP address and shared MAC address. Physical firewalls use this feature.
• Individual interface-mode There is no shared virtual IP address. Each interface of each firewall uses separate IP addresses. Virtual firewalls use this feature.

In physical firewall clusters usually use EtherChannel load balancing. EtherChannel, along with LACP, guarantee the failover of connections in the case of firewall failure. EtherChannel operates at layer 2, so it can load balance between multiple nodes that are sharing a single IP address.

However, virtual firewall clusters rely on layer 3 load balancers. Typically, these load balancers are stateful. When a node becomes unhealthy, new flows are rebalanced among the health firewalls. However, how the load balancer treats existing flows to unhealthy nodes varies.

Therefore, for the public cloud, connection resilience across cluster node failure depends on the type of load balancer and its configuration.

Configuring Target Failover in AWS

Target failover is available on AWS gateway load balancers. This setting is off by default.

To configure this setting with the AWS CLI, use the modify-target-group-attributes command, with the following key value pairs:

• Key=target_failover.on_deregistration and Value= no_rebalance (default) or rebalance
• Key=target_failover.on_unhealthy and Value= no_rebalance (default) or rebalance

These attributes are also available in the AWS Cloud Formation Templates.

Below is the relevant AWS portal page. Note that if you use the portal page, both the attributes are enabled and disabled together.

Note that this behavior is not available for the network load balancers. Therefore, even with Cisco firewall clusters, connections will not survive a cluster node failure. Third party load balancers, in combination with Cisco Secure Firewall clusters, may be able to provide connection level resilience in AWS. However, Cisco does not officially support these third party solutions.

📚References

• For details about public cloud clustering feature in Cisco Secure Firewalls, see Virtual Firewall Clustering.
• For Cisco Secure Firewall integration with the AWS GWLB, see Cisco Secure Firewall 7.1 Release - Deployment with AWS Gateway Load Balancer.
• For a detailed discussion of the AWS GWLB target failover feature, see Introducing AWS Gateway Load Balancer Target Failover for Existing Flows.
• To configure the AWS GWLB target failover feature, see Target groups for your Gateway Load Balancers.