Aviatrix Firewall Network Services (FireNet) simplify the Next Generation Firewall Insertion and Operations. FireNet is the simplest, highest performance, best scale-out architecture for next generation firewalls in the cloud.
Following are some of the highlights
- Simple deployment, autoroute propagation to firewalls
- Advanced egress, IDS, IPS, and ingress security
- Maximize performance, scale, and visibility
- Simplified – no IPSec tunneling or SNAT required
- Integration with Check Point, Fortinet, and Palo Alto Networks Firewalls
FireNet for Google Cloud (GCP)
FireNet for GCP follows the same principle and provides the same benefits as in the other Cloud. It is the same architecture that is consistent across multiple clouds.
Like any other cloud GCP native networking and security services are different than AWS and Azure so there are some unique requirements that engineers should be aware of but from the design, deployment, and operations perspective it is transparent to the enterprise security and networking team.
Before we take a look at FireNet in GCP, we must understand the design requirement imposed by GCP that will lead us into the understanding it better later in the document.
GCP Networking Behavior
In this section, we will discuss the unique GCP Networking Behavior that will dictate some of the design choices needed to design a GCP FireNet solution
GCP Does Not Support Multiple Network Interfaces in the same VPC
GCP does not allow multi-NIC VMs to be deployed in the same VPC network. This restrictions forces Aviatrix FireNet customer to plan for additional VPCs as we will discuss later in the session
GCP Support ECMP on Routing Table
GCP has this great feature to allow ECMP on its routing table.
GCP Support Internal TCP/UDP LB IP as Next Hops
GCP networking is also better as compare to other cloud in terms of supporting internal TCP/UDP LB IP as next hops
GCP FireNet Design Notes
The GCP FireNet design is applicable to GCP Shared VPC or Standard VPC designs.
The GCP FireNet solution requires at least three interfaces to be deployed on the 3rd party security appliance or firewall. Some security vendors do allow Firewalls on stick design where there is only one NIC present to handle ingress, egress, east/west, and management traffic. This type of solution might be good for small deployment but poses scale and segmentation challenges in enterprise-grade security solutions.
Multi-NIC FireNet design is also more flexible and scalable and works really well with the GCP Shared VPC design.
GCP Best Practices for Service Insertion
If you look at the GCP service insertion or NGFW insertion best practices, you will notice they also recommend multiple nic design.
GCP FireNet Topology
Following shows a logical GCP FireNet topology
- Transit FireNet GW VM
- This GW is deployed by Aviatrix controller with two interfaces.
- NIC0 sits in Transit VPC (or Transit FireNet VPC). This side will be connected to Spoke GWs in their respective VPC
- NIC1 connects to LAN VPC facing the Firewall
- Firewall / Security Appliance VM
- The Firewall is deployed by the Aviatrix Controller with 3 interfaces
- NIC0 has the public IP address for the egress traffic. If egress traffic is not required, one can ignore it. The Controller will build this interface regardless
- NIC1 is the management interface. Usually, a public IP address is assigned to this interface. In some cases, customers might want to access management via a private network (over Google Cloud Interconnect etc.) and can assign a private IP as well
- NIC2 is connected to LAN VPC. This will be used to communicate with the Aviatrix Transit FireNet GW
Design Recommendations and Best Practices
- Because VPC resource quotas are set at the project level, make sure to have aggregate VPC resource needs across all VPC
- Do not deploy any workload in the Transit VPC
- Do not deploy any workload in the LAN VPC
- Do not deploy any workload in the Egress VPC
Aviatrix Transit FireNet Design with Standard GCP VPC
Following design shows Aviatrix Transit FireNet design with standard GCP VPC setup. This shows the Aviatrix Spokes also connected to Aviatrix Transit GW
Transit FireNet Deployment
[07:49:12] Starting to create GW aviatrix-transit-fnet-gw.
[07:49:12] Connected to GCE.
[07:49:14] Need gateway image. Copying now..
[07:53:28] Project check complete.
[07:53:29] License check is complete.
[07:53:53] Updating IGW for new gateway…
[07:54:08] Launching compute instance in GCE….
[07:54:44] GCE compute instance created successfully.
[07:54:44] Updating DB.
[07:54:44] Added GW info to Database.
[07:54:45] AVX SQS Queue created.
[07:54:45] Initializing GW…..
[07:55:02] Copy configuration to GW aviatrix-transit-fnet-gw done.
[07:55:02] Copy new software to GW aviatrix-transit-fnet-gw done.
[07:55:03] Copy misc new software to GW aviatrix-transit-fnet-gw done.
[07:55:03] Copy scripts to GW aviatrix-transit-fnet-gw done.
[07:55:03] Copy sdk to GW aviatrix-transit-fnet-gw done.
[07:55:03] Copy libraries to GW aviatrix-transit-fnet-gw done.
[07:55:03] Copy gateway system data files is done.
[07:55:03] Installing software ….
[07:55:07] Issuing certificates …
[07:55:22] Issue certificates done
[07:55:52] GW software started.
[07:57:06] Software Installation done.
[07:57:08] Run self diagnostics done.
[07:57:11] Creating Firenet iLB
[07:57:23] initializing security rule
[07:57:24] GW security policy configured.
[07:57:38] Enable FireNet function.