Access to Microsoft Azure

Oracle and Microsoft have created a cross-cloud connection between Oracle

Cloud Infrastructure and Microsoft Azure in certain regions. This connection
lets you set up cross-cloud workloads without the traffic between the clouds
going over the internet. This topic describes how to set up virtual networking
infrastructure resources to enable this kind of cross-cloud deployment.

Highlights
• You can connect a Microsoft Azure virtual network (VNet) with an Oracle Cloud
Infrastructure (OCI) virtual cloud network (VCN) and run a cross-cloud workload.
In the typical use case, you deploy your Oracle Database on OCI, and deploy an
Oracle, .NET, or custom application in Microsoft Azure.
• The two virtual networks must belong to the same company and not have
overlapping CIDRs. The connection requires you to create an Azure ExpressRoute
circuit and an OCI FastConnect virtual circuit.

Availability
The cross-cloud connection between OCI and Azure is only available in the regions and
ExpressRoute locations shown below. For more information on Azure region locations and
Azure ExpressRoute, see ExpressRoute partners and peering locations in the Azure
documentation.

The following image shows regions with interconnect.

Asia Pacific (APAC)

 OCI location - key Azure ExpressRoute location

Japan East (Tokyo) NRT Tokyo

Singapore (Singapore) - SIN Singapore

South Korea Central (Seoul) - ICN Seoul

Europe, Middle East, Africa (EMEA)

OCI location Azure ExpressRoute location

Germany Central (Frankfurt) - FRA Frankfurt and Frankfurt2

Netherlands Northwest (Amsterdam) - AMS Amersterdam2

UK South (London) - LHR London

South Africa Central (Johannesburg) - JNB Johannesburg

Latin America (LATAM)

OCI location Azure ExpressRoute location

Brazil Southeast (Vinhedo) - VCP Campinas

North America (NA)

 OCI location Azure ExpressRoute location

Canada Southeast (Toronto) - YYZ Toronto and Toronto2

US East (Ashburn) - IAD Washington DC and Washington DC2

US West (Phoenix) - PHX Phoenix

US West (San Jose) - SJC Silicon Valley

Overview of Supported Traffic

Here are more details about the supported types of traffic.

VNet-to-VCN Connection: Extension from One Cloud to Another

You can connect your VNet and VCN so that traffic that uses private IP addresses goes
over the cross-cloud connection.

For example, the following diagram shows a VNet that is connected to a VCN. Resources
in the VNet are running a .NET application that access an Oracle database that runs
on Database service resources in the VCN. The traffic between the application and database
uses a logical circuit that runs on the cross-cloud connection between Azure and Oracle
Cloud Infrastructure.

To enable the connection between the VNet and VCN, you set up an Azure ExpressRoute
circuit and an Oracle Cloud Infrastructure FastConnect virtual circuit. The connection has
built-in redundancy, which means you need to set up only a single ExpressRoute circuit and
single FastConnect virtual circuit. The bandwidth for the connection is the bandwidth value
you choose for the ExpressRoute circuit.

For instructions, see Setting Up a VNet-to-VCN Connection.

Peered VCNs

The connection enables traffic to flow from the VNet through the connected VCN to a
peered VCN in the same Oracle Cloud Infrastructure region, or a different region.

Types of Traffic Not Supported by the Connection

This cross-cloud connection does not enable traffic between your on-premises network
through the VCN to the VNet, or from your on-premises network through the VNet to the
VCN.

Important Implications of Connecting Clouds

This section summarizes some access control, security, and performance implications of
connecting your VCN to a VNet. In general, you can control access and traffic by
using IAM policies, route tables in the VCN, and security rules in the VCN.

The sections that follow discuss implications from the perspective of your VCN. Similar
implications affect your VNet. As with your VCN, you can use Azure resources such as
route tables and network security groups to secure your VNet.

Controlling the Establishment of a Connection

With Oracle Cloud Infrastructure IAM policies, you can control:

• Who in your organization has the authority to create a FastConnect virtual circuit
(see Setting Up a VNet-to-VCN Connection). Deletion of the relevant IAM policy
does not affect any existing connections to a VNet, only the ability for a future
connection to be created.
• Who can manage route tables, network security groups, and security lists.

Controlling Traffic Flow Over the Connection

Even if a connection has been established between your VCN and VNet, you can control
the packet flow over the connection with route tables in your VCN. For example, you can
restrict traffic to only specific subnets in the VNet.

Without terminating the connection, you can stop traffic flow to the VNet by simply
removing route rules that direct traffic from your VCN to the VNet. You can also
effectively stop the traffic by removing any security rules that enable ingress or egress
traffic with the VNet. This doesn't stop traffic flowing over the connection, but stops it at
the VNIC level.

Controlling the Specific Types of Traffic Allowed

It's important that you ensure that all outbound and inbound traffic with the VNet is
intended or expected and well defined. Implement Azure network security group and
Oracle security rules that explicitly state the types of traffic one cloud can send to the other
and accept from the other.

Important

Your Oracle Cloud Infrastructure instances running Linux or Windows platform

images also have firewall rules that control access to the instance. When troubleshooting
access to an instance, ensure that the following items are set correctly: the network security
groups that the instance is in, the security lists associated with the instance's subnet, and the
instance's firewall rules.

If your instance is running Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7,
Oracle Linux 8, Oracle Linux 7, or Oracle Linux Cloud Developer 8, you need to
use firewalld to interact with the iptables rules. For your reference, here are commands for
opening a port (1521 in this example):

Copy
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp

sudo firewall-cmd --reload

For instances with an iSCSI boot volume, the preceding --reload command can cause
problems. For details and a workaround, see Instances experience system hang after
running firewall-cmd --reload.

In addition to security rules and firewalls, you should evaluate other OS-based
configuration on the instances in your VCN. There could be default configurations that
don't apply to your own VCN's CIDR, but inadvertently apply to the VNet's CIDR.

Using Default Security List Rules with Your VCN

If your VCN's subnets use the default security list with the default rules, two rules in that
list allow ingress traffic from anywhere (that is, 0.0.0.0/0, and thus the VNet):
 • Stateful ingress rule that allows TCP port 22 (SSH) traffic from 0.0.0.0/0 and any
source port
• Stateful ingress rule that allows ICMP type 3, code 4 traffic from 0.0.0.0/0 and any
source port

Evaluate these rules and whether you want to keep or update them. As stated earlier, you
should ensure that all permitted inbound or outbound traffic is intended or expected and
well defined.

Preparing for Performance Impact and Security Risks

In general, you should prepare your VCN for the ways it could be affected by the VNet. For
example, the load on your VCN or its instances could increase. Or your VCN could
experience a malicious attack directly from or by way of the VNet.

Regarding performance: If your VCN is providing a service to the VNet, be prepared to

scale up your service to accommodate the demands of the VNet. This might mean being
prepared to launch more instances as necessary. Or if you're concerned about high levels of
network traffic coming to your VCN, consider using stateless security rules to limit the
level of connection tracking your VCN must perform. Stateless security rules can also help
slow the impact of a denial-of-service (DoS) attack.

Regarding security risks: If the VNet is connected to the internet, your VCN can be
exposed to bounce attacks. A bounce attack involves a malicious host on the internet
sending traffic to your VCN that looks like it's coming from the VNet. To guard against
this, as mentioned earlier, use your security rules to carefully limit the inbound traffic from
the VNet to expected and well-defined traffic.

Setting Up a VNet-to-VCN Connection

This section describes how to set up the logical connection between a VNet and VCN (for
background, see Overview of Supported Traffic).

Prerequisites: Resources You Need

You must already have:

• An Azure VNet with subnets and virtual network gateway

• An Oracle Cloud Infrastructure VCN with subnets and an attached dynamic routing
gateway (DRG). It's easy to forget to attach the DRG to your VCN after you create
 it. If you already have Site-to-Site VPN or FastConnect between your on-premises
network and VCN, then your VCN already has an attached DRG. You use that same
DRG here when setting up the connection to Azure.

As a reminder, here is a table that lists the comparable networking components involved in
each side of the connection.

Component Azure Oracle Cloud Infrastructure

Virtual network VNet VCN

Virtual circuit ExpressRoute circuit FastConnect private virtual circuit

Gateway virtual network gateway dynamic routing gateway (DRG)

Routing route tables route tables

Security rules network security groups (NSGs) network security groups (NSGs), secu

Prerequisites: BGP Information You Need

The connection between the VNet and VCN uses BGP dynamic routing. When you set up
the Oracle virtual circuit, you provide the BGP IP addresses that will be used for the two
redundant BGP sessions between Oracle and Azure:

• A primary pair of BGP addresses (one IP address for the Oracle side, one IP address
for the Azure side)
• A separate, secondary pair of BGP addresses (one IP address for the Oracle side,
one IP address for the Azure side)

For each pair, you must provide a separate block of addresses with a subnet mask
from /28 to /31.

The second and third addresses in each address block are used for the BGP IP address pair.
Specifically:

• The second address in the block is for the Oracle side of the BGP session
• The third address in the block is for the Azure side of the BGP session
The first and last addresses in the block are used for other internal purposes.

For example, if the CIDR is 10.0.0.20/30, then the addresses in the block are:

• 10.0.0.20
• 10.0.0.21: Use this for the Oracle side (in the Oracle Console, enter the address as
10.0.0.21/30)
• 10.0.0.22: Use this for the Azure side (in the Oracle Console, enter the address as
10.0.0.22/30, and notice that this address is referred to as the "Customer" side in
the Console)
• 10.0.0.23

Remember that you must also provide a second block with the same size for the secondary
BGP addresses. For example: 10.0.0.24/30. In this case, 10.0.0.25 is for the Oracle side,
and 10.0.0.26 is for the Azure side. In the Oracle Console, you must enter these as
10.0.0.25/30 and 10.0.0.26/30.

Prerequisites: Required IAM Policy

It's assumed that you have the necessary Azure Active Directory access and Oracle Cloud
Infrastructure IAM access to create and work with the relevant Azure and Oracle
networking resources. Specifically for IAM: If your user is in the Administrators group,
you have the required authority.

If your user is not, then a policy like this one generally covers all the Networking resources:

Copy
Allow group NetworkAdmins to manage virtual-network-family in tenancy

To only create and manage a virtual circuit, you must have a policy like this:

Copy
Allow group VirtualCircuitAdmins to manage drgs in tenancy

Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancy

For more information, see IAM Policies for Networking.

Overall Process

The following diagram shows the overall process of connecting your VNet and VCN.