The purpose of this blog is to provide the reader information for deploying virtual Firewalls (vFW) in OCI Virtual Cloud Network (VCN). This blog provides information in general and is not specific to any vendor in the market. Vendors like PaloAlto (VM-Series), Cisco (NGFWv, ASAv), Fortinet (FortiGate-VM), and others provide virtual versions of their flagship appliance products. It is very important that you work directly with your vendor of choice to validate your design using this blog as a guide.
When deploying a virtual Firewall (vFW) within your VCN you need to define the requirements for your deployment in order to size the Virtual Machine accordingly and to make sure your vendor of choice supports the deployment. Below are some questions to consider when gathering requirements:
What is the throughput required?
What other services will be enabled on the vFW?
Threat Prevention – What is the throughput required?
What is the throughput required?
How many tunnels?
What IPSec parameters are required?
How many new sessions per second and what is the maximum sessions required?
How many security zones do you need?
How many virtual interfaces (vNIC) do you need? Keep in mind that you need an additional interface (management) on top of the interfaces for traffic flow
Based on the information you collected from the questions above work with your vendor to determine what particular model will support your requirements. Then check the vendor’s specs to determine the VM size. Once you have this information compare it with the Oracle Compute Shapes available that meets your CPU, memory, disk space, hypervisor, and vNICs requirements. As you work with your vendor of choice confirm that the image for the vFW is compatible/supported in Oracle Cloud and procure the proper license.
There are different use cases to deploy vFWs in OCI and all depends of what you are trying to accomplish within your VCN.
The main purpose of deploying a vFW in OCI is to protect the resources deployed on your VCN. Perhaps you want to create a DMZ to make applications available to your users over the internet, or perhaps you want to segregate resources from talking to each other, or perhaps you want to log traffic between your resources. The vFW can protect north-south, or east-west, or a combination of traffic flow as long as traffic is outside of the VCN where the FW is deployed. It is recommended to have a vNIC per security zone which aligns with the requirements to size the correct VM.
Note: Within your VCN you can also use security lists to segregate traffic or to create a DMZ. Customer might prefer to use a vFW to have more control or to maintain a unified security deployment with the rest of their network.
In a single VCN deployment the objective of the FW is to inspect/control traffic destine for outside of the VCN. vNICs will be allocated to different subnets within the VCN. It is recommended that the subnets are regional to have more flexibility. Note that the route table for each of the subnets are required to point to the vNIC of the vFW in order to reach hosts outside the VCN. For example in the diagram below, Subnet A route table will need an entry for an external subnet (on-prem or Internet) pointing to the IP address of vNIC2. Otherwise the subnets will use the built-in routing to route traffic within the VCN bypassing the vFW. From the Untrust VNIC traffic can go to on-prem via the DRG using FastConnect or VPN connect or it can reach the Internet via an Internet Gateway.
If your tenancy involves multiple VCNs, you can accomplish the same features mentioned above as long as your VCNs are within the same region. In this case each vNIC is associated to subnets in different VCNs and the vFW can be used to route traffic between VCNs. The same as single VCN, the subnet’s routing table will point to the vNIC as a gateway to route to other VCNs.
Note: Communication between VCNs can also be accomplished by using a Local Peering Gateway (LPG) within OCI.
The vFW could also be deployed to perform NAT/PAT functions. For example if you want to allow a VM in Subnet A to access the Internet. Subnet’s A routing table will point to vNIC2 for any traffic destined to the Internet. When the traffic arrives to vFW it will have a policy to NAT/PAT the traffic and send it out the interface which has access to the Internet. With the vFW you can also NAT/PAT internal traffic base on policies depending of your requirements.
Note: Within your VCN you could use a NAT gateway to allow resources in a private subnet to access the Internet.
A vFW could also terminate IPSec VPN tunnels from remote offices or DC. For this solution to work the untrusted interface needs to be part of a public subnet within the VCN. In the example below the untrusted interface is vNIC1 and the WAN Subnet should be public.
Note: You can also use Oracle VPN Connect to terminate tunnels in the DRG attached to the VCN. Oracle by default provides two headends for redundancy.
For any critical component in the network you need to design the solution with redundancy and resiliency in mind. Deploying redundant solutions in the cloud is a little different than on-prem because in the cloud, the IP addresses are owned and managed by the cloud and they are assigned to a particular object (device or host). This concept will affect how the Virtual IP (VIP) between two devices is moved when there is a failure. For example, if we use HSRP for redundancy, the VIP is assigned to the primary/active device and when it fails, the secondary/standby device takes ownership of the VIP. This is managed by the protocol itself. Vendors have their own way to manage the VIP between the devices in a cluster. In the cloud the protocol can detect the failure but it can’t move the VIP on its own. Some vendors have the ability to interact with the cloud and move the VIP natively, for the ones that don’t you have to move the VIP using some scripting language like Python or other tools like Pacemaker and Corosync. Please check with your vendor how to deploy redundant vFW in OCI.
Note: On a HA deployment you require additional interfaces which interconnect the hosts in the cluster. Depending of the vendor and the type of features you are running on the vFW you might need from 1 to 3 additional vNICs. Check your OCI Shape to make sure you have the necessary vNICs available to support an HA deployment. In the example below you will need 5 VNICs for this deployment (1 mgmt (not pictured), 1 Untrust, 1 Subnet A, 1 Subnet B, 1 crossbar between vFWs (assuming only 1 is required)).
As you can see in the diagram below you will have a VIP for each of the vNICs. The VIP IP is what will be used as the next hop when routing out of the subnets. When vFW1 fails the VIP for all 3 vNICs is moved to vFW2 and your routing will continue to work.
The first step for deploying a vFW in OCI is to make sure the vendor supports your deployment in OCI. Second make sure the Oracle Shape you select for your VM meets your business requirements and the vendor’s requirements. The process for installing the vFW depends of the vendor specific. Check with your vendor for step by step instructions how to deploy their product in OCI.
Note: When deploying a vFW in OCI, typically the first vNIC that gets created is the management interface. Make sure you place that interface in the proper management subnet.
Below there are couple links to documentation for some vendors. Cisco is not supported in OCI at the time of this writing.
Fortinet - https://docs.fortinet.com/vm
If you search this site you will find some blogs created for specific vendors