Oracle Cloud Infrastructure (OCI)’s dynamic routing gateway (DRG) enhancements allows end users to route traffic between virtual cloud networks (VCNs) using DRG. Before, you had to deploy local peering gateways (LPGs) to steer traffic from spoke VCNs to hub or transit VCNs and inspect through firewalls. This blog teaches how you can use dynamic routing gateways to steer your VCN traffic to get inspected using Fortinet FortiGate.
Checkout Official Announcement on this Blog
DRGs give us the flexibility to steer traffic from VCNs and inspect traffic using firewalls. In this use case, we validate traffic between spoke VCNs and inspect using a FortiGate firewall. You can scale your architecture by adding more virtual firewall appliances as needed in a different architecture. You can gain high availability in active-passive use-case or using OCI’s flexible network load balancer in a sandwich topology.
We use only one firewall virtual machine (VM), but in a production environment, use multiple firewall VMs to support your production workload.
An Oracle Cloud account. If you don’t have an account, you can sign up for an Oracle Cloud Free Tier account.
A working hub and spoke network topology
A working FortiGate Firewall VM your in hub VCN
You can utilize Oracle Cloud Marketplace to deploy FortiGate firewall.
Web application VMs are running Apache service on Port 80 (optional).
You can refer the following topology to support this use case:
Figure 1: Use case network topology
You can follow this section to add the required minimum configuration on FortiGate VM and OCI to integrate with the dynamic routing gateway. For more configurations, follow the official guide.
In your hub and spoke topology, you need the use the FortiGate bring-your-own-license (BYOL) or paid VM listing from OCI Marketplace. After you configure the required interfaces, use the maximum transmission unit (MTU) on your interfaces. To support the traffic, use the following minimum steps:
Open the required security policies to support traffic.
Add the correct routes pointing to spoke VCNs and the default gateway.
Enable security policies to support VCN traffic. You can Allow All for test purposes but ensure that you enable only the required policies on FortiGate VMs in your production environment.
Figure 2: Security policies on FortiGate VM
Ensure that you have correct routes for your spoke VCNs, Object Storage network, and default routes. You can follow this diagram as a reference:
Figure 3: Static routes on FortiGate VM
With a working OCI setup, use the following steps for this use case:
Create route rules on your dynamic routing gateway.
Attach spoke and hub VCNs to the dynamic routing gateway.
Update route tables associated with subnets and dynamic routing gateway to support ingress traffic.
You can follow the official steps outlined in the documentation from task 1–10.
Use the following images as a reference point to verify that you have created required steps outlined in the document.
Figure 4: Dynamic routing gateway VCN attachments
Figure 5: To-firewall route tables associated with spoke VCNs
Figure 6: From-firewall route table associated with firewall VCN
Figure 7: Redistributed routes to firewall VCN
Update the route tables to reflect the correct routes for the topology shared and update your topology with the following details:
DRG route table: Entries for each spoke VCN CIDR as the destination with the target as Firewall Trust Interface IP.
Firewall untrust subnet: If you plan to have outbound connectivity, set an entry for the default route as the destination with the target as the internet gateway.
Firewall trust subnet: Create entries for each spoke VCN CIDR as the destination with the target as DRG.
Spoke VCN subnets route table: Set the default entry for each subnet as the destination with the target as DRG.
At this point, you can validate the traffic from the client VMs and inspect the traffic from FortiGate firewall.
To initiate traffic from the client VM, use the following settings:
Client VM source IP address: 10.0.0.59
Destination database spoke VM address and Object Storage network: 10.0.1.96 and 22.214.171.124
The user is trying to reach the web spoke VM from the database spoke VM and back. The user is also trying to download an object from a bucket using a pre-authorized URL.
[opc@web-app ~]$ hostname --all-ip-addresses 10.0.0.59 [opc@web-app ~]$ ping 10.0.1.96 PING 10.0.1.96 (10.0.1.96) 56(84) bytes of data. 64 bytes from 10.0.1.96: icmp_seq=1 ttl=61 time=0.576 ms 64 bytes from 10.0.1.96: icmp_seq=2 ttl=61 time=0.541 ms 64 bytes from 10.0.1.96: icmp_seq=3 ttl=61 time=0.552 ms 64 bytes from 10.0.1.96: icmp_seq=4 ttl=61 time=0.529 ms ^C --- 10.0.1.96 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 113ms rtt min/avg/max/mdev = 0.529/0.549/0.576/0.029 ms [opc@web-app ~]$ [opc@web-app ~]$ $ curl -I https://objectstorage.us-sanjose-1.oraclecloud.com/p/k5bfM7Dx4tZj-DmtUYYx8qYo5FJnJ7FYI1iwneMn6lGJHweapKDrhfCNYb4dRRG2/n/partners/b/traffic/o/logo.png | grep HTTP % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 3924 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 200 OK [opc@web-app ~]$
[opc@db-app ~]$ hostname --all-ip-addresses 10.0.1.96 [opc@db-app ~]$ ping 10.0.0.59 PING 10.0.0.59 (10.0.0.59) 56(84) bytes of data. 64 bytes from 10.0.0.59: icmp_seq=1 ttl=61 time=0.551 ms 64 bytes from 10.0.0.59: icmp_seq=2 ttl=61 time=0.518 ms 64 bytes from 10.0.0.59: icmp_seq=3 ttl=61 time=0.496 ms 64 bytes from 10.0.0.59: icmp_seq=4 ttl=61 time=0.519 ms 64 bytes from 10.0.0.59: icmp_seq=5 ttl=61 time=0.510 ms ^C --- 10.0.0.59 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 115ms rtt min/avg/max/mdev = 0.496/0.518/0.551/0.034 ms [opc@db-app ~]$ curl -I https://objectstorage.us-sanjose-1.oraclecloud.com/p/k5bfM7Dx4tZj-DmtUYYx8qYo5FJnJ7FYI1iwneMn6lGJHweapKDrhfCNYb4dRRG2/n/partners/b/traffic/o/logo.png | grep HTTP % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 3924 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 200 OK [opc@db-app ~]$
You can inspect the traffic flow from FortiGate VM. The traffic comes from the client VM IP. The web spoke VM has IP address 10.0.0.59, and the database spoke VM uses 10.0.1.96. The traffic goes to either the database spoke VM or the web spoke VM, using one of the following methods:
Object Storage networks traffic through service gateways and routes on the firewall
SSH connection traffic from web VM to database spoke VM
Figure 8: Traffic flow on FortiGate firewall
This post explained how to use dynamic routing gateways to simplify a FortiGate firewall use case in a hub and spoke topology. You can use this post as a reference point to validate different firewall appliances and enhance your use cases.
To learn more about how to use load balancers, hub and spoke architecture, and more, see the following resources: