Spoke VCN to Object Storage by using the SGW from the Hub VCN

Many times a question has been raised by our customers and the question sounds like this: it is possible to access the Object Storage or Oracle Services Network (OSN) from a Spoke VCN VMs by using the Hub VCN SGW?

In our blog post we will explore this possibility and on another hand we will explain how this can be achieved from the OCI routing perspective.

As you guessed, we are going to use the Hub&Spoke networking topology and use the Transit Routing to explain the concept:  https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/transitrouting.htm

1. Networking Topology

The scope is from the Test VM at 172.30.0.2 to access the Object Storage by using the SGW from the Hub VCN, in other words we do not want to have an SGW in the Spoke VCN, we want to consolidate the traffic to Object Storage through the SGW from the Hub VCN.

The Hub and Spoke VCNs are locally peered together by using LPG1 and LPG2.

For the setup to work we need to introduce a Third Party Appliance or a Network Virtual Appliance (NVA) in the Hub VCN. In our case the NVA has the IP address of 172.31.0.2.

The appliance will be used to route the traffic from the Spoke VCN -> SGW -> Object Storage and vice-versa when the Object Storage responds.

The reason for introducing the NVA is that in a routing table associated with an LPG a route pointing to the SGW as a next-hop is not permitted: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/transitrouting.htm  section Route Table for an LPG. In our case the NVA is a Linux VM with IP Forwarding function activated and iptables permitting to forward the traffic. The Linux VM can be replaced with any third party appliance (Fortigate NGFW, Palo Alto, Checkpoint etc.) properly configured.

2. Routing Configuration

2.1 Routing table associated with the Spoke VCN subnet 172.30.0.0/24

The public IPs associated with the Object Storage in Ashburn region: https://docs.cloud.oracle.com/en-us/iaas/tools/public_ip_ranges.json

Note: The Security List associated with the the subnet must include 2 egress security rules to permit the traffic to flow to above public IP prefixes.

2.2 Routing table associated with the Hub LPG1

The traffic to above two IP prefixes will be sent by the LPG1 to the private IP of our NVA at 172.31.0.2.

2.3 Routing table associated with the NVA subnet 172.31.0.0/24 in the Hub VCN

The traffic for Object Storage will be sent to the SGW. When the response traffic is received by the NVA there is a need for a route back to the Spoke VCN at 172.30.0.0/16.

Note: The Security List associated with the the subnet must include 2 egress security rules to permit the traffic to flow to above public IP prefixes associated with Object Storage (listed at points 2.1 and 2.2).

2.4 Routing table associated with the SGW in the Hub VCN

When the SGW receives the response from the Object Storage will send the traffic to our NVA for forwarding back to the Spoke VCN VM.

3. Traffic testing

[root@test opc]# host objectstorage.us-ashburn-1.oraclecloud.com
objectstorage.us-ashburn-1.oraclecloud.com has address 134.70.31.247
objectstorage.us-ashburn-1.oraclecloud.com has address 134.70.27.247
objectstorage.us-ashburn-1.oraclecloud.com has address 134.70.35.189

As we can see from the above output, all three IP addresses are part from the IP prefixes defined above in our routing entries.

[root@test opc]# ping objectstorage.us-ashburn-1.oraclecloud.com
PING objectstorage.us-ashburn-1.oraclecloud.com (134.70.35.189) 56(84) bytes of data.
64 bytes from 134.70.35.189 (134.70.35.189): icmp_seq=1 ttl=63 time=0.509 ms
64 bytes from 134.70.35.189 (134.70.35.189): icmp_seq=2 ttl=63 time=0.540 ms
64 bytes from 134.70.35.189 (134.70.35.189): icmp_seq=3 ttl=63 time=0.647 ms
64 bytes from 134.70.35.189 (134.70.35.189): icmp_seq=4 ttl=63 time=0.549 ms
^C
--- objectstorage.us-ashburn-1.oraclecloud.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3042ms
rtt min/avg/max/mdev = 0.509/0.561/0.647/0.054 ms

[root@test opc]# curl -v https://objectstorage.us-ashburn-1.oraclecloud.com
* About to connect() to objectstorage.us-ashburn-1.oraclecloud.com port 443 (#0)
*   Trying 134.70.31.247...
* Connected to objectstorage.us-ashburn-1.oraclecloud.com (134.70.31.247) port 443 (#0)

Let's check if our NVA is receiving the traffic acting as a proxy node:

Yes, the NVA is receiving the traffic and we can access the Object Storage from a Spoke VM using the SGW from the Hub VCN.

The same approach can be used for all Oracle Services from Oracle Services Network ( https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm ) with the proper routing in place.