Interconnect for Azure
Oracle Interconnect for Azure lets you create 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.
For information about multicloud Oracle Database deployments that use Oracle Cloud Infrastructure and Microsoft Azure, see Oracle Database@Azure. This service hosts Oracle Exadata Databases in Azure data centers for the lowest possible latency.
Highlights
- You can connect an Oracle Cloud Infrastructure (OCI) Virtual Cloud Network (VCN) with a Microsoft Azure virtual network (VNet) and run a cross-cloud workload. In the typical use case, you deploy an 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. Oracle Interconnect for Azure requires you to create an Azure ExpressRoute circuit and an OCI FastConnect virtual circuit.
Availability
Oracle Interconnect for Azure is only available in the OCI regions and ExpressRoute locations shown. For more information on Azure region locations and Azure ExpressRoute, see ExpressRoute peering locations and connectivity partners in the Azure documentation.
The following image shows regions with Oracle Interconnect for Azure, showing all OCI regions and noting regions with interconnect to both Azure and GCP. Participating Azure regions are also listed in the following tables.
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.
VCN-to-VNet Connection: Extension from One Cloud to Another
You can connect a VCN and VNet so that traffic that uses private IP addresses goes over the cross-cloud connection.
For example, the following diagram shows a VCN connected to a VNet. 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 VCN and VNet, you set up both an Oracle Cloud Infrastructure FastConnect virtual circuit and an Azure ExpressRoute circuit. The connection has built-in redundancy, which means you need to set up only a single FastConnect virtual circuit and a single ExpressRoute circuit. The bandwidth for the connection is the bandwidth value you select for the ExpressRoute circuit.
For instructions, see Setting Up a Connection.
Peered VCNs
The connection lets traffic 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 doesn't enable traffic between the on-premises network through the VCN to the VNet, or from the 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 Oracle Interconnect for Azure. 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 the VCN. Similar implications affect the VNet. As with the VCN, you can use Azure resources such as route tables and network security groups to secure the VNet.
Controlling the Establishment of a Connection
With Oracle Cloud Infrastructure IAM policies, you can control:
- Who in the organization has the authority to create a FastConnect virtual circuit (see Setting Up a Connection). Deletion of the relevant IAM policy doesn't 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 the VCN and VNet, you can control the packet flow over the connection with route tables in the VCN. For example, you can restrict traffic to only specific subnets in the VNet.
Without deleting the connection, you can stop traffic flow to the VNet by removing route rules that direct traffic from the 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
Ensure that all outbound and inbound traffic with the VNet is intended or expected and as 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.
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 an 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 reference, here are commands for opening a port (1521 in this example):
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reloadFor 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, evaluate other OS-based configuration on the instances in the VCN. There could be default configurations that don't apply to the VCN's CIDR, but inadvertently apply to the VNet's CIDR.
Using Default Security List Rules with the VCN
If the VCN's subnets use the default security list with the default rules, two rules in that list allow ingress traffic from anywhere (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, ensure that all allowed inbound or outbound traffic is intended or expected and as-defined.
Preparing for Performance Impact and Security Risks
In general, prepare the VCN for the ways it could be affected by the VNet. For example, the load on the VCN or its instances could increase. Or the VCN could experience a malicious attack directly from or by way of the VNet.
Regarding performance: If the VCN is providing a service to the VNet, be prepared to scale up the service to accommodate the demands of the VNet. This might mean being prepared to create more instances as necessary. Or if you're concerned about high levels of network traffic coming to the VCN, consider using stateless security rules to limit the level of connection tracking the 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, the VCN can be exposed to bounce attacks. A bounce attack involves a malicious host on the internet sending traffic to the VCN that seems to be coming from the VNet. To guard against this, as mentioned earlier, use security rules to carefully limit the inbound traffic from the VNet to expected and as-defined traffic.
Setting Up a Connection
This section describes how to set up the logical connection between a VCN and VNet (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). Remember to attach the DRG to the VCN after you create it. If you already have Site-to-Site VPN or FastConnect between the on-premises network and VCN, then the 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), security lists |
Prerequisites: BGP Information You Need
The connection between the VCN and VNet uses BGP dynamic routing. When you set up the Oracle virtual circuit, you provide the BGP IP addresses 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:
- 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
You probably 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. For IAM: If your user account is in the Administrators group, you have the required authority. Otherwise, this policy covers all the Networking resources:
Allow group NetworkAdmins to manage virtual-network-family in tenancyTo only create and manage a virtual circuit, you must have a policy such as this:
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyFor more information, see IAM Policies for Networking.
Overall Process
The following diagram shows the overall process of connecting the VCN and VNet.
The first task is to decide what traffic needs to flow between the relevant subnets within the VCN and VNet, and then configure security rules to match. Here are the general types of rules to add:
- Ingress rules for the types of traffic you want to allow from the other cloud's relevant subnets.
- Egress rule to allow outgoing traffic from one cloud to the other. If the VCN's subnet already has a broad egress rule for all types of protocols to all destinations (0.0.0.0/0), then you don't need to add a special one for the traffic to the VNet. The VCN's default security list includes a broad default egress rule.
Here are recommended types of traffic to allow between the VNet and VCN:
- Ping traffic in both directions for testing the connection from each side
- SSH (TCP port 22)
- Client connections to an Oracle database (SQL*NET on TCP port 1521)
Only allow traffic to and from specific address ranges of interest (for example, the other cloud's relevant subnets).
For the VCN:
The following procedure uses security lists, but you could instead implement the security rules in one or more network security groups and then place the VCN's relevant resources in NSGs.
For the VNet: Decide which subnets in the VNet need to communicate with the VCN. Then configure the network security groups for those subnets to allow traffic.
- Decide which subnets in the VCN need to communicate with the VNet.
-
Update the security list for each of those subnets to include rules to allow egress or ingress traffic with the VNet's CIDR block or a subnet of the VNet:
- In the Console, while viewing the VCN you're interested in, select Security Lists.
- Select the security list you're interested in.
-
Select Edit All Rules and create one or more rules, each for the specific type of traffic you want to allow. See the example rules that follow.
-
Select Save Security List Rules at the bottom of the dialog box.
For more information about setting up security rules, see Security Rules.
The following egress security rule lets an instance create a ping request to a host outside the VCN (echo request ICMP type 8). This is a stateful rule that automatically allows the response. No separate ingress rule for echo reply ICMP type 0 is required.
- In the Allow Rules for Egress section, select +Add Rule.
- Leave the Stateless checkbox unselected.
- Destination CIDR: The relevant subnet in the VNet (10.0.0.0/16 in the preceding diagram)
- IP Protocol: ICMP
- Type and Code: 8
- Description: An optional description of the rule.
The following ingress security rule lets an instance receive a ping request from a host in the VNet (echo request ICMP type 8). This is a stateful rule that automatically allows the response. No separate egress rule for echo reply ICMP type 0 is required.
- In the Allow Rules for Ingress section, select +Add Rule.
- Leave the Stateless checkbox unselected.
- Source CIDR: The relevant subnet in the VNet (10.0.0.0/16 in the preceding diagram)
- IP Protocol: ICMP
- Type and Code: 8
- Description: An optional description of the rule.
The following ingress security rule lets an instance receive an SSH connection (TCP port 22) from a host in the VNet.
- In the Allow Rules for Ingress section, select +Add Rule.
- Leave the Stateless checkbox unselected.
- Source CIDR: The relevant subnet in the VNet (10.0.0.0/16 in the preceding diagram)
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 22
- Description: An optional description of the rule.
The following ingress security rule allows SQL*Net connections (TCP port 1521) from hosts in the VNet.
- In the Allow Rules for Ingress section, select +Add Rule.
- Leave the Stateless checkbox unselected.
- Source CIDR: The relevant subnet in the VNet (10.0.0.0/16 in the preceding diagram)
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 1521
- Description: An optional description of the rule.
Set up an ExpressRoute circuit to Oracle Cloud Infrastructure FastConnect. During the circuit setup, you receive a service key from Microsoft. Record that service key, because you must provide it to Oracle in the next task.
In the next task, you set up a FastConnect private virtual circuit to Microsoft Azure: ExpressRoute. When that virtual circuit finishes being provisioned, the ExpressRoute circuit updates to show that private peering is enabled.
- In the Console, confirm you're viewing the compartment that you want to work in. If you're not sure which one, use the compartment that contains the DRG. This choice of compartment, along with a corresponding IAM policy, controls who can access the virtual circuit you're about to create.
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
The resulting FastConnect page is where you create a new virtual circuit and later return to when you need to manage the virtual circuit.
- Select Create Connection.
- Select FastConnect partner and select Microsoft Azure: ExpressRoute from the list.
-
Enter the following for the virtual circuit:
- Name: A friendly name. The value doesn't need to be unique across virtual circuits, and you can change it later. Avoid entering confidential information.
- Create in Compartment: Leave as is (the compartment you're working in).
- Virtual Circuit Type: Select Private Virtual Circuit.
- Dynamic Routing Gateway Compartment: Select the compartment where the DRG resides (already selected).
- Dynamic Routing Gateway: Select the DRG.
- Provisioned Bandwidth: Select the same bandwidth level you chose for the ExpressRoute circuit (or the closest value available).
- Partner Service Key: Enter the service key you received from Microsoft when you set up the ExpressRoute circuit.
- Customer Primary BGP IP Address: This field is the Azure primary BGP IP address. Enter the third address in the primary CIDR block (with a subnet mask from /28 to /31) that you provide, and include the subnet mask at the end. For example: 10.0.0.22/30. For more information about this field and the next ones, see Setting Up a Connection.
- Oracle Primary BGP IP address (optional): You can leave this field blank and Oracle infers the address based on the CIDR block you provided for the Azure BGP IP address. In this example, the correct value would be 10.0.0.21/30.
- Customer Secondary BGP IP Address: This field is the Azure secondary BGP IP address. Enter the third address in the secondary CIDR block (with a subnet mask from /28 to /31) that you provide, and include the subnet mask at the end. For example: 10.0.0.26/30.
- Oracle Primary BGP IP Address (optional): You can leave this field blank and Oracle infers the address based on the CIDR block you provided for the Azure BGP IP address. In this example, the correct value would be 10.0.0.25/30.
-
Select Continue.
The virtual circuit is created.
- Select Close.
After you create the Oracle virtual circuit, you don't need to contact Azure to request provisioning of the circuit. It happens automatically.
Both circuits are provisioned within a few minutes. To verify:
- For the ExpressRoute circuit, confirm that private peering is provisioned.
- For the FastConnect virtual circuit, confirm that its status is UP. See To get the status of the FastConnect virtual circuit.
For the VCN:
- Decide which subnets in the VCN need to communicate with the VNet.
-
Update the route table for each of those subnets to include a new rule that directs traffic destined for the VNet's CIDR to the DRG:
- In the Console, while viewing the VCN you're interested in, select Route Tables.
- Select the route table you're interested in.
- Select Edit Route Rules.
-
Select + Another Route Rule and enter the following:
- Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
- Destination CIDR Block: The relevant subnet in the VNet (10.0.0.0/16 in the preceding diagram).
- Description: An optional description of the rule.
- Select Save.
For the VNet: Decide which subnets in the VNet need to communicate with the VCN. Then configure the route tables for those subnets to route traffic to the VNet gateway.
Any subnet traffic with a destination that matches the rule is routed to the DRG. The DRG then knows to route the traffic to the VNet based on the virtual circuit's BGP session information.
Later, if you no longer need the connection and want to delete the DRG, you must first delete all the route rules in the VCN that specify the DRG as the target.
For more information about setting up route rules, see VCN Route Tables.
If the VNet security groups and VCN security rules are set up correctly, you can create an instance in the VCN and access it from a host in the VNet, or connect from the instance to a host in the VNet. If you can, the connection is ready to use.
If you decide to terminate the connection, you must follow a particular process. See To terminate the connection to Azure.
Managing Oracle Interconnect for Azure
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the compartment where the connection resides, and then select the connection you're interested in. If the icon for the virtual circuit is green and says UP, the virtual circuit is provisioned and BGP has been correctly configured. The virtual circuit is ready to use.
You can change these items for the virtual circuit:
- The name
- Which DRG it uses
If the virtual circuit is in the PROVISIONED state, changing which DRG it uses switches the state to PROVISIONING and might cause the connection to go down. After Oracle reprovisions the virtual circuit, its state returns to PROVISIONED. Confirm that the connection is back up and working.
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the compartment where the connection resides, and then select the connection.
- Select the virtual circuit.
- Select Edit and make changes. Avoid entering confidential information.
- Select Save.
The following diagram shows the overall process of terminating a VCN-to-VNet connection.
- In the Azure portal, view the ExpressRoute circuit, and then view its Connections. Confirm that no Connections still exist for the ExpressRoute circuit. Delete all Connections before proceeding.
-
In the Oracle portal, delete the FastConnect virtual circuit:
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the compartment where the connection resides, and then select the connection.
- Select the virtual circuit.
- Select Delete.
-
Confirm when prompted.
The virtual circuit's Lifecycle State switches to TERMINATING.
- In the Azure portal, confirm that the private peering for the ExpressRoute circuit has been deleted. Also confirm that the ExpressRoute circuit's status has changed to "Not Provisioned".
- In the Azure portal, delete the ExpressRoute circuit.
The connection between Azure and Oracle Cloud Infrastructure is terminated.