Cisco Secure Endpoint – looking very positive in recent reports!
November 9, 2022
REPEAT AND REFINE: HOW DO YOU GET TO CARNEGIE HALL? (Pt. 6 of “Why Don’t You Go Dox Yourself?”)
November 10, 2022

Cisco Secure Firewall on AWS: Build resilience at scale with stateful firewall clustering

Organizations embrace the public cloud for the agility, scalability, and reliability it offers when running applications. But just as organizations need these capabilities to ensure their applications operate where needed and as needed, they also require their security does the same. Organizations may introduce multiple individual firewalls into their AWS infrastructure to produce this outcome. In theory, this may be a good decision, but in practice—this could lead to asymmetric routing issues. Complex SNAT configuration can mitigate asymmetric routing issues, but this isn’t practical for sustaining public cloud operations. Organizations are looking out for their long-term cloud strategies by ruling out SNAT and are calling for a more reliable and scalable solution for connecting their applications and security for always-on protection.

To solve these challenges, Cisco created stateful firewall clustering with Secure Firewall in AWS.

 

Cisco Secure Firewall clustering overview

Firewall clustering for Secure Firewall Threat Defense Virtual provides a highly resilient and reliable architecture for securing your AWS cloud environment. This capability lets you group multiple Secure Firewall Threat Defense Virtual appliances together as a single logical device, known as a “cluster.”

A cluster provides all the conveniences of a single device (management and integration into a network) while taking advantage of the increased throughput and redundancy you would expect from deploying multiple devices individually. Cisco uses Cluster Control Link (CCL) for forwarding asymmetric traffic across devices in the cluster. Clusters can go up to 16 members, and we use VxLAN for CCL.

In this case, clustering has the following roles:

Figure 1: Cisco Secure Firewall Clustering Overview

The above diagram explains traffic flow between the client and the server with the insertion of the firewall cluster in the network. Below defines the roles of clustering and how packet flow interacts at each step.

 

Clustering roles and responsibilities 

Owner: The Owner is the node in the cluster that initially receives the connection.

    • The Owner maintains the TCP state and processes the packets. 
    • A connection has only one Owner. 
    • If the original Owner fails, the new node receives the packets, and the Director chooses a new Owner from the available nodes in the cluster.

Backup Owner: The node that stores TCP/UDP state information received from the Owner so that the connection can be seamlessly transferred to a new owner in case of failure.

Director: The Director is the node in the cluster that handles owner lookup requests from the Forwarder(s). 

    • When the Owner receives a new connection, it chooses a Director based on a hash of the source/destination IP address and ports. The Owner then sends a message to the Director to register the new connection. 
    • If packets arrive at any node other than the Owner, the node queries the Director. The Director then seeks out and defines the Owner node so that the Forwarder can redirect packets to the correct destination. 
    • A connection has only one Director. 
    • If a Director fails, the Owner chooses a new Director.

Forwarder: The Forwarder is a node in the cluster that redirects packets to the Owner. 

    • If a Forwarder receives a packet for a connection it does not own, it queries the Director to seek out the Owner 
    • Once the Owner is defined, the Forwarder establishes a flow, and redirects any future packets it receives for this connection to the defined Owner.

Fragment Owner: For fragmented packets, cluster nodes that receive a fragment determine a Fragment Owner using a hash of the fragment source IP address, destination IP address, and the packet ID. All fragments are then redirected to the Fragment Owner over Cluster Control Link.  

 

Integration with AWS Gateway Load Balancer (GWLB)

In the Secure Firewall Threat Defense, Cisco brought support for AWS Gateway Load Balancer (Figure 2). This feature enables organizations to scale their firewall presence as needed to meet demand (see details here).

Figure 2: Cisco Secure Firewall and AWS Gateway Load Balancer integration

 

Cisco Secure Firewall clustering in AWS

Building off the previous figure, organizations can take advantage of the AWS Gateway Load Balancer with Secure Firewall’s clustering capability to evenly distribute traffic at the Secure Firewall cluster. This enables organizations to maximize the benefits of clustering capabilities including increased throughput and redundancy. Figure 3 shows how positioning a Secure Firewall cluster behind the AWS Gateway Load Balancer creates a resilient architecture. Let’s take a closer look at what is going on in the diagram.

Figure 3: Cisco Secure Firewall clustering in AWS

Figure 3 shows an Internet user looking to access a workload. Before the user can access the workload, the user’s traffic is routed to Firewall Node 2 for inspection. The traffic flow for this example includes:

User -> IGW -> GWLBe -> GWLB -> Secure Firewall (2) -> GLWB -> GWLBe -> Workload

In the event of failure, the AWS Gateway Load Balancer cuts off existing connections to the failed node, making the above solution non-stateful.

Recently, AWS announced a new feature for their load balancers known as Target Failover for Existing Flows. This feature enables forwarding of existing connections to another target in the event of failure.

Cisco is an early adaptor of this feature and has combined Target Failover for Existing Flows with Secure Firewall clustering capabilities to create the industry’s first stateful cluster in AWS.

aws
Figure 4: Cisco Secure Firewall clustering rehashing existing flow to a new node

Figure 4 shows a firewall failure event and how the AWS Gateway Load Balancer uses the Target Failover for Existing Flows feature to switch the traffic flow from Firewall Node 2 to Firewall Node 3. The traffic flow for this example includes:

User -> IGW -> GWLBe -> GWLB -> Secure Firewall (3) -> GLWB -> GWLBe -> Workload

 

Conclusion

Organizations need reliable and scalable security to protect always-on applications in their AWS cloud environment. With stateful firewall clustering capabilities from Cisco, organizations can protect their applications while maintaining cloud benefits such as agility, scalability, and reliability.

Cisco Secure Firewall Threat Defense Virtual is available in the AWS marketplace, providing features like firewalling, application visibility & control, IPS, URL filtering, and malware defense. Cisco offers flexible options for firewall licensing, such as pay-as-you-go (PAYG) and bring-your-own-license (BYOL). To learn more about how Cisco Secure Firewall clustering capabilities can help protect your AWS applications, see our additional resources, check out our 30-day free trial, or speak to your Cisco sales representative.

 

Additional Resources 

Cisco Secure Firewall Clustering in the Cloud

Building a Scalable Security Architecture on AWS with Cisco Secure Firewall and AWS Gateway Load Balancer

Introducing AWS Gateway Load Balancer Target Failover for Existing Flows

Secure Firewall for Public Cloud webpage


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn