Installing OCI Network Firewall – Design

One of the cool things Oracle has brought to OCI is managed network firewall service which is based on Palo Alto. Before OCI Network Firewall I saw constant requirement to provision self-managed firewall such as Palo Alto, Fortinet, Check Point etc. This is still a requirement as OCI Network Firewall might not provide all the functionality that is needed for some, but I’ve seen it being installed to multiple tenancies already!

This time I’ll install OCI Network Firewall and validate that I can see traffic arriving to firewall, create policies to allow the traffic and check that I can see traffic monitored in the logs. But let’s start with design.

Design

This time to keep this simple I’ll have just two VCNs. My Firewall VCN (Hub) and My Another VCN (Spoke). I have a private subnet in My Another VCN which runs a compute instance, I do want to pass that traffic through Firewall via accepted policies.

One thing to note that contrary to self-managed firewall with multiple interfaces, OCI Network Firewall will only run on one subnet. If your source servers are on private subnet, then firewall subnet must be a private subnet and traffic for it will be through NAT gateway and you can’t use firewall NATting similar as with self-managed firewall from public internet towards private IPs in your VCNs.

OCI Network Firewall documentation can be found from here. One thing I will say, the documentation examples are not so good in my opinion as the networking documentation in general and diagrams can be somewhat confusing.

I drew above diagram to help my network setup, and to help visualize things needed. As you can see, key will be to have correct route tables so traffic leaves from my-another-vcn, traverses through dynamic routing gateway (DRG) and arrives to my-firewall-vcn which has my OCI Network Firewall running.

Explaining routing

Even though routing looks complex, it’s very logical once you understand it. Let’s try to understand how it goes.

I have a private subnet in my-another-vcn which has associated route table which routes ALL (0.0.0.0/0) traffic towards DRG. So, any traffic leaving from my-another-vcn needs to get to DRG.

Once traffic gets to DRG, it will get to DRG VCN attachment which is associated with my-another-vcn and has a route table mapped to it(drg-another-rt). Think it as someone giving instructions where you should go when you arrive to DRG. This time the instruction is for ALL traffic go to firewall attachment which has my-firewall-vcn associated to it.

Once traffic arrives firewall attachment, it has VCN Route table associated with it (similar as my-firewall-vcn) which has route rule towards firewall private IP (10.200.0.233). Unless you don’t have a VCN route table associated, traffic doesn’t know it needs to go to private IP.

When traffic arrives to firewall, we’ll need to have rules (more on those later) to allow or deny traffic. Firewall subnet must have a route towards NAT GW. So, all traffic leaving from firewall must know either to go towards NAT GW or back to DRG if it’s end destination is towards my-another-vcn (10.0.1.0/24).

You will need to have one more rule which is required with Network Firewall, your NAT GW needs to have a rule for traffic coming back from NAT GW towards Firewall IP.

Summary

With above design, we should be able to provision OCI Network Firewall and test if we can hit the firewall with traffic coming from my-another-vcn. After we see traffic being denied in the firewall, we’ll take a look on how to add new policy which allows it and how to monitor traffic within the firewall.