Oracle Cloud Infrastructure Documentation

Access to Other VCNs: Peering

VCN peering is the process of connecting multiple virtual cloud networks (VCNs). There are four types of VCN peering:

You can use VCN peering to divide your network into multiple VCNs (for example, based on departments or lines of business), with each VCN having direct, private access to the others. There's no need for traffic to flow over the internet or through your on-premises network by way of an Site-to-Site VPN or FastConnect. You can also place shared resources into a single VCN that all the other VCNs can access privately.

Each VCN can have up to 10 local peering gateways and can attach to only one DRG. A single DRG supports up to 300 VCN attachments, allowing traffic between them to flow as directed by the DRG's route tables. We recommend using the DRG if you need to peer with a large number of VCNs. If you want extremely high bandwidth and super low-latency traffic between two VCNs in the same region, use the scenario described in Local VCN Peering using Local Peering Gateways. Local VCN Peering Through an Upgraded DRG gives you more flexibility in your routing due to the greater number of attachments.

Because remote VCN peering crosses regions, you can use it (for example) to mirror or back up your databases in one region to another.

Overview of Local VCN Peering

Local VCN peering is the process of connecting two VCNs in the same region so that their resources can communicate using private IP addresses without routing the traffic over the internet or through your on-premises network. The VCNs can be in the same Oracle Cloud Infrastructure tenancy  or different ones. Without peering, a given VCN would need an internet gateway and public IP addresses for the instances that need to communicate with another VCN.

Local VCN Peering Through an Upgraded DRG gives you more flexibility in your routing and simplified management but comes at the cost of an increase in latency (by microseconds) due to routing traffic through a virtual router, the DRG.

Important Implications of Peering

This section summarizes some access control, security, and performance implications for peered VCNs. In general, you can control access and traffic between two peered VCNs by using IAM policies, route tables in each VCN, and security lists in each VCN.

Controlling the Establishment of Peerings

With IAM policies, you can control:

Controlling Traffic Flow Over the Connection

Even if a peering connection has been established between your VCN and another, 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 other VCN.

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

For more information about the routing and security lists, see the discussions in these sections:

Local VCN peering using local peering groups:

Remote VCN peering using a remote peering connection:

Local VCN peering using a dynamic routing gateway (DRG) :

Remote VCN peering using a dynamic routing gateway (DRG):

Controlling the Specific Types of Traffic Allowed

It's important that each VCN administrator ensures all outbound and inbound traffic with the other VCN is intended or expected and well defined. In practice, this means implementing security list rules that explicitly state the types of traffic your VCN can send to the other and accept from the other.

Important

Your instances running platform images also have OS firewall rules that control access to the instance. When troubleshooting access to an instance, ensure that all of the following items are set correctly:

  • The rules in the network security groups that the instance is in
  • The rules in the security lists associated with the instance's subnet
  • The instance's OS 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):

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 lists 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 other VCN's CIDR.

Using Default Security List Rules

If your VCN's subnets use the default security list with the default rules it comes with, be aware that there are two rules that allow ingress traffic from anywhere (that is, 0.0.0.0/0, and thus the other VCN):

  • 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 inbound or outbound traffic that you permit is intended/expected and well-defined.

Preparing for Performance Impact and Security Risks

In general, prepare your VCN for the ways it could be affected by the other VCN. 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 other VCN.

Regarding performance: If your VCN is providing a service to another, be prepared to scale up your service to accommodate the demands of the other VCN. 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 list rules to limit the level of connection tracking your VCN must perform. Stateless security list rules can also help slow the impact of a denial-of-service (DoS) attack.

Regarding security risks: You can't necessarily control whether the other VCN is connected to the internet. If it is, your VCN can be exposed to bounce attacks in which a malicious host on the internet can send traffic to your VCN but make it look like it's coming from the VCN you're peered with. To guard against this, as mentioned earlier, use your security lists to carefully limit the inbound traffic from the other VCN to expected and well-defined traffic.