Comprehensive cloud support is essential when agile and efficient security at scale is required. With Cisco Secure Firewall Threat Defense 7.1, we have added support for the AWS Gateway Load Balancer (GWLB) to drive simple, agile, and efficient security in the cloud. This integration simplifies insertion of Cisco Secure Firewall in AWS with Geneve protocol (RFC 8926) encapsulation. It makes architectures more scalable, in part by removing the need for source network address translation (SNAT) in the traffic path. Let’s consider a few common use cases where this new capability makes a difference.
Use-case: Ingress and Egress traffic inspection
Figure 1 below shows a scalable architecture for protecting ingress traffic using Cisco Secure Firewall and AWS Gateway Load Balancer. This architecture recommends creating an appliance VPC with an AWS Gateway Load Balancer and Cisco Secure Firewall virtual appliances in the backend pool of the gateway load balancer. Gateway load balancers talk to these firewalls using Geneve encapsulation, eliminating the need for SNAT, as packets have embedded virtual network interface (vni) information.
The Internet user sends traffic destined to the elastic-IP-address of a workload. Traffic hits the Internet gateway, and then it is redirected to the AWS Gateway Load Balancer Endpoint (GWLBe). The GWLBe sends traffic to the GWLB, and then to the firewall for inspection. Following inspection, the packet is then forwarded to the destination workload via GWLBe.
- Ingress Traffic Flow:
User -> IGW -> GWLBe -> GWLB -> Secure Firewall -> GLWB -> GWLBe -> Workload
Figure 2 shows a scalable architecture for protecting outbound traffic using Cisco Secure Firewall and AWS Gateway Load Balancer. In this Cisco Validated Design, we recommend creating an appliance VPC with a Gateway load balancer and Cisco Secure Firewalls in the backend pool of gateway load balancer. Gateway load balancers talk to these firewalls using Geneve encapsulation.
The workload sends traffic to the Internet. Based on the route table, traffic is routed to GWLBe. Once traffic reaches the gateway load balancer endpoint, it forwards traffic to the gateway load balancer in the appliance VPC. The gateway load balancer then forwards the traffic to Cisco Secure Firewall. Once inspection is complete, the firewall forwards the traffic back to the GWLB. Once the traffic reaches the GWLB, it sends it back to the GWLBe, directing the traffic to the Internet.
- Egress Traffic Flow:
Workload-> GWLBe -> GWLB -> Secure Firewall -> GLWB -> GWLBe -> Internet
IGW1-RT: This route table is associated to Internet Gateway (IGW1) and there is a route for application subnet (10.81.100.0/24) point to the gateway load balancer endpoint (GWLBEP).
GWLBEPsubnet1-RT: This route table is associated to GWLBEPsubnet1 and there is a default route that points to the Internet Gateway (IGW).
AppSubnet1-RT: This route table is associated to AppSubnet1 and there is a default route that points to the gateway load balancer endpoint (GWLBEP1).
Firewall Configuration:
- Enable Firewall interface
- Associate security zone to firewall interface
VNI Interface configuration:
- Enable VNI interface and add a name for VNI interface
- Create and associate for Security Zone on VNI interface
- Enable AWS proxy
- Enable VTEP Interface
Use-case: Centralized deployment with AWS Transit Gateway (East/West traffic flow)
Figure 3 shows centralized security deployment architecture. In this design, AWS Transit Gateway connects application VPC to appliance VPC. Transit gateway receives traffic from application VPC and forwards the same to GWLBe (endpoint). GWLBe sends traffic to GWLB, GLWB sends the traffic to Cisco Secure Firewall. Post firewall inspection, traffic is forwarded back to the GLWB and then to the destination VPC via transit gateway.
Use-case: Centralized deployment with AWS Transit Gateway (east/west traffic flow)
Figure 4 shows east/west traffic flow between customer’s Data Center and appliance VPC.
My next blog will a deep-dive on architecture for a centralized deployment model with AWS Transit Gateway and Cisco Secure Firewall in AWS (Figure 3 and Figure 4). Stay tuned!
Additionally, Cisco announced it will be supporting Secure Firewall as a Service on AWS. These enhancements are all part of our commitment to simplify security across hybrid and multicloud environments, harmonizing network, workload, and application security.
Additional resources
Cisco Secure Firewall for Public Cloud
Cisco Secure Firewall on AWS Marketplace
At-a-Glance: Cisco Secure Firewall
Blog Announcement: Cisco Secure Firewall as a Service on AWS
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
Share:
Leave a Reply