OCI Networking – Routing Oracle Services Network Public IPs via Service Gateway

This topic keeps coming up and there are many good blog posts from Oracle and their A-Team on this.

As you know, you utilize Oracle Service Gateway to access Oracle Services within the Region. However, you can also broadcast these public IP addresses via Service Gateway towards Dynamic Routing Gateway (DRG) and then to your on-premises network (FastConnect or IPSec VPN) or to other VCN. In this example, I’m going to route any SGW traffic from my DB VCN towards DRG and then to my VCN which has Service Gateway deployed.

In short what you need:

• VCN (my example tfg-vcn, 10.50.0.0/24) with a VCN route table attached to VCN Route table (in DRG VCN RT attachment) and route towards SGW in that VCN
• SGW in that VCN with a SGW route table attached, routing traffic to on-prem or other VCNs(destination 10.0.0.0/24 for my example) accordingly
• Another VCN(my example my-db-vcn) which doesn’t have SGW attached, routing all traffic towards DRG
  • For on-premises, they would take the public OSN CIDR blocks from here and route them towards FastConnect or IPSec VPN which then lands on OCI

Let’s take a look! First my tfg-vcn 10.50.0.0/24 which has Service Gateway. Note the SGW route table below which sends traffic towards 10.0.0.0/24 which is my VCN without Service Gateway. Think it as SGW needs to know where to send traffic apart from the VCN itself.

Next, tfg-vcn has route table attached in the DRG attachment, think it as route table that when traffic arrives to VCN, it will know where to go! Similar as when you use network firewall, you would have VCN route table towards Private IP.

See target for All Oracle Services within region is my SGW in tfg-vcn.

Finally, in my source VCN I will have route rule which sends ALL traffic (just as an example), towards DRG. No other route rules so it won’t be mixing it up.

What I should validate next is to see that routes are visible on DRG, so when traffic arrives to DRG, something is there to point where the OSN service traffic should go.

Go to the DRG, and check the DRG attachments and their route table. In this case I’m using autogenerated route table but in real configurations I like to use separate route table per attachment (your opinions may differ).

See above, all YYZ (Toronto) services next hop is tfg-vcn. Now let’s test it. I have provisioned a compute instance in the db private subnet which only has route towards DRG, one thing on the private subnets which uses OSN is Linux yum updates. So, we should see two things:

1. 1. 1. YUM update does not time out
      2. We should see traffic leaving from the VCN

YUM update ran fine but I’m more interested to see traffic leaving the compute, how could we see them? Using VCN Flow Logs of course! I have them enabled in my subnet, and if I look traffic leaving from my private server, I see following:

And if we look the public JSON list with 140.204.0. we should see something related to ca-toronto-1..

{
         "region": "ca-toronto-1",
         "cidrs": [
             {
                 "cidr": "40.233.64.0/18",
                 "tags": [
                     "OCI"
                 ]
             },
       .... took out bunch of IPs
             },
             {
                 "cidr": "140.204.0.128/25",
                 "tags": [
                     "OSN"
                 ]
             },

There we go! We see YUM is working, the traffic is leaving VCN towards DRG and DRG routes traffic to my tfg-vcn which has the SGW added.

Just a reminder, if you would do this with your on-premises network, you would have to make sure the OSN IP list is routed towards FC or IPSec VPN tunnel accordingly.