This blog covers the recently announced enhancement of Oracle Cloud Infrastructure (OCI) Networking, Intra-VCN Routing (IVR) and IGW/NATGW/SGW ingress routing within your Virtual Cloud Network (VCN). Today, Fortinet’s FortiGate Firewall can be deployed as either Active-Passive or Active-Active clusters using the OCI Flexible Network Load Balancer to support transit routing in a Hub & Spoke architecture – however, with these enhancements you can route traffic within a VCN which simplifies the overall architecture and routing.
Learn more about the Intra-VCN Routing by reading the blog Announcing OCI Intra-VCN Routing and VCN Gateway Ingress Routing Enhancements authored by Lilian Quan.
Disclaimer: Even though this blog showcases Fortinet partner’s FortiGate solution as an example, this capability should work in tandem with any other 3rd party appliances like Palo Alto Networks, Cisco, Check Point which have also been validated. The customer needs to work with the specific vendor/partner to make sure its product will work and will be supported by the vendor.
Use Cases
Intra-VCN Routing capabilities gives us the simplicity of configuring routing to support OCI workload traffic within VCNs and you can also use a Firewall to inspect/secure your traffic.
- Intra-VCN Routing – Allows you to control routing for intra-VCN traffic – you are able to define subnet level routes, for example.
- IGW/NATGW ingress routing – Allows definition of routes for inbound public traffic to the VCN towards a user-selected next-hop.
- SGW ingress routing enhancement – Allows you to define your own routes for SGW to route traffic from OCI services to destinations inside your VCN.
In this use case, you will be sending traffic within VCNs and inspecting it with the FortiGate firewall.
Prerequisites
- An Oracle Cloud account. If you don’t have an account, you can sign up for an Oracle Cloud Free Tier account.
- A working Intra VCN Network Topology which can be setup as per the topology set out below.
- A working FortiGate firewall VM in your in Hub-VCN
- You can utilize Oracle Cloud Marketplace to deploy FortiGate firewall.
- You can follow this workshop to get yourself familiar with Fortinet’s partner solution.
- Linux VMs running in respective subnets as per the use-case topology.
Note: In a production environment ensure you deploy Firewall VMs with high availability.
Topology:
You can refer to the following topology to support this use case:
Figure 1: Use case network topology
Configuration
The following sections set out the required minimum configuration of a FortiGate VM and the setup of OCI Intra VCN Routing. For more configurations, see the official guide.
VCN Subnets
The first step is to create subnets within your Hub-VCN (named intra-vcn) and the Spoke VCN to support your use-case topology. You can create subnets using OCI Console by navigating to Virtual Cloud Networks > Virtual Cloud Network Details
- Management, Untrust and Trust subnets to support Firewall VM in Hub-VCN
- Client, Server and Public subnets in Hub-VCN to support Linux VMs for traffic validation.
- ServerA, ServerB subnets in Spoke VCN to support Linux VMs for traffic validation.
The below picture shows subnets in Hub-VCN (intra-vcn):
Figure 2: Subnets in Intra-VCN
Next, you need to deploy the FortiGate firewall instance using OCI Marketplace – the primary interface will be attached to the management subnet.
Fortinet FortiGate Firewall(s)
In the VCN, deploy the FortiGate firewall as bring-your-own-license (BYOL) or paid VM listing from OCI Marketplace. You can follow the workshop link shared in the Pre-Requisites section to get yourself familiar with the partner solution. Once your firewall VMs are up, create minimum two additional vNICs (Trust, Untrust) and deploy them on the respective subnets as per the use-case topology. Once the vNICs are set up, reboot the VM and log into your FortiGate firewall VM and configure the interfaces. Below is the interface configuration for the VMs in the Oracle Console. To support the traffic, use the following minimum steps:
- Assign required private/public IP addresses to the interfaces.
- Enable skip/source destination check on the interfaces.
- Configure the required security policies to allow traffic.
- Add the correct routes as per the use-case topology.
FortiGate Firewall
Figure 3: FortiGate Firewall instance and VNICs.
Firewall Interfaces
To provide external connectivity, assign a Public IP address to the untrust interface. Use the trust/untrust interface’s private IP addresses to assign to the firewall interfaces and use them in the various route tables. Configure all firewall interfaces on each firewall following the partner’s recommendation.
Figure 4: FortiGate Firewall instance interfaces
Security policies
Enable security policies to support VCN traffic. You can use Allow All policies for test purposes but ensure that you enable only the required policies on FortiGate VMs in your production environment.
Figure 5: FortiGate Firewall Policies
Firewall routes
Ensure the firewalls have correct routes for your client subnet, server subnet, public IP, Object Storage network, and default routes. For your reference, the picture below shows the routing on the firewall.
Figure 6: FortiGate Firewall Route Rules
Note: If you are using a standalone firewall VM ensure that default gateway traffic is using the correct gateway IP route (i.e.not the management interface.)
Route tables within the VCNs
You would need to configure the route tables to reflect the correct route rules for the use-case topology. At a high level you would need to modify the route tables in the VCNs as follows:
Hub-VCN
- Untrust Subnet Route Table: If you plan to have outbound connectivity, set an entry for the default route as the destination with the target as the Internet or NAT Gateway.
- Trust Subnet Route Table: Create entries with the subnet CIDR as the destination with the target as the Service Gateway or DRG.
- Public VMs Subnet Route Table: Create entries with each subnet CIDR as the destination and the target as the firewall untrust interface, Internet Gateway or DRG.
- Client Subnet route table: Create entries with each subnet CIDR as the destination and the target as the firewall trust interface and/or Internet Gateway or DRG.
- Server Subnet route table: Create entries with each subnet CIDR as the destination and the target as firewall trust interface and/or DRG.
- VCN Ingress Route Table: Create entries with each destination CIDR and the target as the firewall trust interface, so as to inspect the traffic from Spoke VCNs.
Spoke VCN:
- ServerA Route Table: Create entries for each subnet CIDR as the destination with the target as the DRG.
- ServerB Route Table: Create entries for each subnet CIDR as the destination with the target as the DRG.
Please ensure that route symmetry is used so traffic is inspected properly in both directions.
Validation:
At this point, you can validate the traffic from the client, server, public VMs and inspect the traffic from the FortiGate firewall. The below picture shows required VMs running as per use-case topology.
Figure 7: Use-Case Topology Required VMs
North-South traffic inspection from Public VM to Internet via Inernet Gateway (IGW) Ingress Routing
IGW Ingress routing capability allows you to access public VMs directly without configuring any NAT on the Firewall. This will eliminate the need to assign Public IP addresses to the firewall untrust interfaces. The picture below shows logical traffic flow and different routing tables associated to ensure IGW ingress routing capability is used to send traffic to the firewall:
Figure 8: Logical Traffic Flow and Routing
You can access the public VM (152.67.248.55) from internet and access to internet VM (129.213.92.25 ). Traffic will flow through Firewall:
Figure 9: Public VM & Internet Traffic Validation
The picture below shows traffic from the Internet to the Public IP on the VM as well as trffic to the Internet flowing through the FortiGate Firewall:
Figure 10: Traffic on Firewall VM
East-West traffic inspection from Client to Server VMs & North-South inspection from Server to Internet via NAT Gateway (NGW) Ingress Routing
The IVR routing capability and the NGW ingress routing capabilities allow you to route traffic within a VCN, using a user-defined route, to a NGW. The picture below shows the logical traffic flow and the different routing tables used to enable IVR and NGW ingress routing:
Figure 11: Logical Traffic Flow and Routing
You can access the Server VM (10.10.4.74) from the Client VM (10.10.3.217) and the Server VM can access the Internet (129.213.92.25) via the NAT Gateway. Make sure that you are not NATing NGW traffic at the Firewall Policy level. Traffic will flow through Firewall:
Figure 12: Client VM to Server VM & Internet Traffic Validation
The picture below shows traffic between the client/server VMs and to the Internet on the FortiGate Firewall:
Figure 13: Traffic on Firewall VM
East-West traffic inspection from the Server VM to the Oracle Services Network via Service Gateway (SGW) Ingress Routing
SGW ingress routing capability allows you to route traffic via a user-defined route on the SGW. The picture below shows the logical traffic flow and the different routing tables associated to enable SGW ingress routing:
Figure 14: Logical Traffic Flow and Routing
You can access the Object Storage Network from the Server VM (10.10.7.74) through the Service Gateway with traffic flowing through the firewall:
Figure 15: Server VM to Object Storage Traffic Validation
The picture below shows traffic between the Server VM and Object Storage Services as seen on the FortiGate Firewall:
Figure 16: Traffic on Firewall VM
East-West traffic inspection between Spoke VCN VMs via Intra-VCN Routing (IVR)
IVR ingress routing allows you to control traffic routing within a VCN and you can also use Transit routing to send the traffic to a Hub-VCN and inspect traffic between Spoke VCN subnets. The below picture shows the logical traffic flow and the different routing tables used to enable IVR:
Figure 17: Logical Traffic Flow and Routing
You can access the ServerB (10.50.3.166) VM from ServerA VM (10.50.1.103) via the DRG and firewall:
Figure 18: Spoke VMs traffic Validation
The picture below shows the traffic between ServerA and Server B VMs on the FortiGate Firewall:
Figure 19: Traffic on Firewall VM
Conclusion
This post explained and show-cased the new OCI Intra-VCN Routing capability together with Fortinet’s FortiGate solution. We have covered Virtual Cloud Network Routing use-cases which can simplify your Firewall deployment on OCI.
Follow these resources to know more about OCI Networking and more:
- Oracle Cloud Infrastructure
- Oracle Cloud Virtual Cloud Network Routing
- Oracle Cloud Infrastructure hub and spoke architecture
- Oracle Cloud Infrastructure transit hub firewall using a DRG
- Oracle Dynamic routing gateway documentation
Fortinet FortiGate reference materials: