vFSA on IBM Cloud: Part 1 Architecture
IBM Cloud customers provision compute resources to run their workloads. Resources include Virtual Server Instances (VSI’s), Bare, and Kubernetes Cluster’s. Whether these resources exist in our Virtual Private Cloud (VPC) or in Classic they all reside on the network. This means network security, gateway and routing capabilities, and other advanced Next Generation Firewall (NGFW) features are critical components of their architectures. We have partnered with Fortinet to deliver a new Gateway offering based on the Virtual Fortigate (vFSA).
In this blog series, I will delve into the value proposition of the latest offering on IBM Cloud, divided into three insightful segments. Part 1 will provide an overview of the architecture behind this innovative solution. Part 2 will delve into the intricacies of configuring routing and firewall policies, ensuring seamless integration. Lastly, in Part 3, I will explore best practices encompassing firmware updates, IP allocation, licensing, and more.
What is the architecture of the Fortinet Virtual Fortigate?
Diagram 1 illustrates the network topology within 3 logical layers of the IBM Cloud infrastructure. The network underlay, the bare-metal server’s host and hypervisor, and the Virtual Fortigate virtual machine. This topology provides network redundancy within all 3 layers, and leverages SRIOV to improve and optimize network throughput. Let’s discuss the 3 layers.
The IBM Cloud Infrastructure-As-A-Service (IaaS) Classic environment leverages protocol’s like VLANs to segregate traffic. Transit VLANs are used to connect Gateway’s like the vFSA to the outside private and public networks. It acts as a service network and packets are untagged. Automatic and Premium VLANs carry tagged traffic and contain subnets and IP’s assigned to resources running workload’s on the IBM Cloud. To protect these resources we associate and route the VLAN through the Gateway (vFSA) and then configure the vFSA interfaces to route and protect traffic as desired.
A High Availability (HA) vFSA Gateway can be ordered with 1G or 10G network links. These links have redundancy at the switches and routers within the datacenter and are illustrated in diagram 1 in the simplistic Private and Public “cloud” images.
The Ubuntu Host and KVM Hypervisor
The HA vFSA Gateway comes with 2 dedicated bare-metal servers, each containing an Intel X710 4-port network interface card enabled for SR-IOV. 2 ports (eth0/eth2) are allocated to private traffic and 2 ports (eth1/eth3) for public traffic. Each port is connected to a distinct switch (BCS/FCS) with LACP bonding on the private and public ports to enable redundancy.
The host runs Ubuntu 20.04 LTS and is configured with KVM to support the vFSA virtual machine. IP’s are reserved from the primary subnets of the public and private transit VLANs. The diagram illustrates an HA pair so this would equate to 1 public and 1 private IP for each Ubuntu bare-metal host. In addition, 1 public and 1 private IP is allocated to the vFSA cluster. These IP’s float to the vFSA node serving as the primary in the active/passive vFSA cluster.
Packets traversing the transit VLAN’s either flow through the linux bridges (br0/br1) which leverage the inbuilt Ubuntu networking stack if destined for the host IP or through the SR-IOV virtual functions if destined for the vFSA (agg0/agg1) IP.
We can see from the diagram that the control plane leverages the Linux virtual network interfaces for the local management console and the vFSA HA cluster communication. While the data plane leverages SRIOV. Each SRIOV physical function (eth0, eth1…) is allocated 2 virtual functions (VF). This allows the vFSA VM to map it’s interfaces to distinct PF’s to support redundancy on the data plane interfaces.
The Virtual Fortigate VM
The vFSA provides interface aggregation for ports together. The default configuration creates 4 distinct aggregate interfaces, agg0 to agg3. These are based off the 8 data plane ports shown in the diagram. When you route a VLAN through the vFSA, static BGP routing within the underlay ensures all subnets on that VLAN will hop through either the vFSA agg0 private IP or the agg1 public IP. Best practice is to configure agg2 (private) and agg3 (public) to then recognize and route the tagged VLAN traffic on to the workload. This would encapsulate subnet’s that reside on the automatic and premium VLAN’s we discussed earlier. This allows the vFSA to serve as the router and firewall for all traffic destined for workload IP’s on vFSA protected VLAN’s within the network.
Summary
IBM Cloud Classic provides several different offerings for protecting workloads today, from a physical, single-tenant Fortinet Firewall, to a shared multi-tenant Firewall, to Gateway offerings like the Juniper vSRX and Ciena VRA. This offering enhances our available network security products on IBM Cloud and giving customer’s more options to meet their specific needs.