X

The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

Simplify firewall use case using Oracle’s dynamic routing gateway

Arun Poonia
Senior Solutions Architect

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

Use case

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.

Prerequisites

Topology

You can refer the following topology to support this use case:


Figure 1: Use case network topology

Configuration

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.

Fortinet FortiGate

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.

Security policies

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

Default routes

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

Oracle Cloud Infrastructure

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.

Dynamic routing gateway

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

Route tables

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.

Validation

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 134.70.124.2

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.

Web to database spoke traffic and Object Storage traffic


[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 ~]$

Database to web spoke traffic and Object Storage traffic


[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:

  • ICMP traffic

  • 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

Conclusion

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:

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha