A routing scenario, transit traffic on OCI

In real life networking scenarios we can have different requirements for the customer traffic that is received by OCI and how the traffic needs to be handled. In the previous blogs we have analyzed in depth how the OCI routing is performed once the traffic is received from a FastConnect Virtual Circuit or IPSec tunnels, and how the route priority is implemented at the DRG level.

In this blog we will discuss about a routing scenario I received in the past days and if it can be implemented. The discussion is arround using the OCI as a sort of transit network between two customer On-premises sites. Is this routing scenario a feasible one, can it be implemented given the fact that the OCI cannot be used as a transit network? Let's have a look at the DRG documentation at the link section Route propagation restrictions:

Routes imported from an IPSec tunnel or virtual circuit are never exported to other IPSec tunnel or virtual circuit attachments, regardless of how the export route distribution is configured. In a similar vein, packets which enter a DRG through an IPSec tunnel or virtual circuit attachment can never leave through an IPSec tunnel or virtual circuit attachment. Packets are dropped if routing is configured such that packets originating from IPSec tunnel or virtual circuit attachments are sent to IPSec tunnel or virtual circuit attachments.

Let's analyze a little bit the bolded phrase. If the routing is configured in such a way for an IP packet received from the customer side via a FC VC or IPSec tunnel to exit directly via another FC VC or IPSec tunnel, that packet will be dropped.

What if a third party appliance or a routing device or a firewall will sit on OCI, will receive the traffic from a FC VC or IPSec tunnel, inspect it and routing it over another FC VC or IPSec tunnel to another customer On-premises site? Will that work? In the next sections we will analyze this case and at the end we will conclude if will work or not.

Very Important Note: the case presented requires an advanced routing configuration. Prior to deploy the routing configuration in a Production Network, the existing routing configuration needs to be carefully analyzed so that, the new routing configuration to not affect any Production workload.

For reference, the OCI DRGv2 and Route Conflict blog explains the DRG route mechanism in depth.

Please take into consideration how the route distribution is configured among all the attachments configured (VCN, VC, IPSec, RPC) and how the new routing configuration applied will interfere with the existing routing policies. 

The networking diagram used will be a very simple one, the main scope is to illustrate as simple as possible the concept while maintaining the logic of the routing.

10.0.1.0/24 from Site1 needs IP connectivity to 10.0.2.0/24 from Site2 and vice-versa. Because Site1 and Site2 does not have a direct connectivity, we should use OCI to transport the IP packets between Site1 and Site2. For this purpose, a Firewall Cluster will be created in OCI to provide a packet inspection and routing point.

The firewall will not perform any NAT on the IP packet received.

The traffic path from Site1 at 10.0.1.25 to Site2 at 10.0.2.18: Site1 -> FC VC or IPSec tunnel to Site1 -> DRG -> Firewall at 10.0.0.13 -> DRG -> FC VC or IPSec tunnel to Site2 -> Site2.

The traffic path from Site2 at 10.0.2.18 to Site1 at 10.0.1.25: Site2 -> FC VC or IPSec tunnel to Site2 -> DRG -> Firewall at 10.0.0.13 -> DRG -> FC VC or IPSec tunnel to Site1 -> Site1.

The main scope is to discuss the routing configuration that needs to be in place for accomplishing the above traffic path.

The RT associated with the VC attachment for Site1 contains the following static entry:

Once the static route is added, the DRG will start announce the 10.0.2.0/24 to Site1, otherwise impossible due to the transit restriction.

The same will be true for Site2 for the route added in the corresponding RT associated with the VC for Site2:

Once the two static routes were added, Site1 knows the route to Site2 10.0.2.0/24 and vice-versa.

The traffic between Site1 and Site2 must pass through the Firewall at 10.0.0.13. The DRG VCN RT contains the following entries:

The two above static routes will assure the traffic between Site1 and Site2 will pass through the Firewall for inspection and routing. The entire routing logic is to make the traffic to appear as being originated by OCI and not a transit one. Since the traffic is inspected and routed by the Firewall it will appear as being originated by OCI and not from one VC to another.

The RT associated with the DRG VCN attachment dynamically imported what we are receiving from Site1 and Site2:

The routing configuration is done, let's test the connectivity and perform a packet capture on the Firewall:

The traffic runs as desired and the routing configuration applied, accomplishes the scope defined above. As we can conclude, in certain scenarios we can use the OCI to pass the traffic between different On-premises sites.