This post will be checklist for items you’ll need when you have Firewall (or Hub) VCN where you route traffic to and have 3rd party firewall appliance (such as Palo Alto) inspecting traffic. You have to understand different route tables which are associated and which routes you have to set to them.
What this post will NOT be is to show how the Firewall routing is done. That’s just because it’s outside of my expertise!
Routing Setup
We’ll be using Dynamic Routing Gateway heavily on this one, so just as a reminder, I’ve written some posts on DRG earlier as well.
DRG Attachment Basics here.
DRG Attachments and Dynamic Route Import Distributions here.
DRG attachment and Remote Peering Connections here.
It’s important to understand which route tables have impact and where, I have made a very basic diagram below trying to explain this so it’ll be easier to understand why some route is needed.
In short, there are three route tables we’re interested on. Subnet route table for traffic leaving the subnet/VCN, DRG VCN attachment route table for traffic arriving to DRG from VCN which tells where traffic should go and finally VCN route table which is on the VCN (not subnet!) which is for traffic arriving for VCN.
It all might seem really overwhelming at first but once you’ve done it few times, it’s really easy to logically think what needs to be and where.
Routing for Firewall
In this example, I want all traffic coming and going from VCNs go through Firewall. Similarly, any traffic leaving to public Internet (or incoming) should go through Firewall. Therefor there will be no NAT or Internet Gateways on any other VCN than Firewall (Hub) VCN.
I’ll need the following setup as shown in below diagram.
Let’s drill down to this, we’re looking what will happen when traffic leaves from VCN C.
- First all traffic from VCN C subnet is routed towards DRG (except Oracle Services and any VCN internal traffic which doesn’t need a route)
- When traffic gets to DRG, we check VCN C attachment route table which has a STATIC route which sends all traffic towards Firewall (Hub) VCN attachment. That attachment has also import route distributions disabled, so we don’t learn any routes dynamically.
- Next stop, Firewall (Hub) VCN route table, this route table is attached to the VCN, not on the subnets and tells to forward traffic to our firewall appliance IP. Typically this is a floating VNIC IP or LB if you use active-active configuration. Check your firewall provider documentation for further details!
- We also need route table(s) in the Firewall VCN subnets. When traffic leaves from appliance, where does it go. We will need route either to NAT or Internet Gateway for any public traffic. Typically this is Internet Gateway when there are connections coming towards OCI from public Internet. You can use also NAT GW if you only have outbound traffic from OCI so you close this connectivity even further. Traffic from VCN C to public Internet would go through these gateways(if allowed in the firewall!). You will also have route back to DRG, any internal traffic is send back to DRG.
- Finally when internal traffic is send from Firewall (Hub) back to DRG, it now goes to Firewall attachment route table. This route table learns routes dynamically and knows all routes towards other VCNs, Virtual Circuits (FC or IPSec VPN) and Remote Peering Connections.
One thing I use to validate all looks good, is going to the DRG attachment route table and click on the Get All Route Rules. That will show what routes the attachments knows (static and dynamic). For the VCN C (Spoke) attachment route table, remember you want to have static route towards Firewall (Hub) VCN attachment. That can be either all traffic or only public internet traffic, depending on your use case.
Summary
This came as a lengthy post and large part of this is also available in OCI documentation, they have good examples there as well. What this post aims to explain is why some route table is needed and where some routing needs to be so everything works.
Hope this helps!