Networking Scenarios

All networking scenarios for a virtualized cloud environment are similar to scenarios for individual IP subnets connected by physical switches, routers, and gateways. In other words, virtual devices still have MAC (hardware) addresses as source and destination addresses in frames and IP addresses as source and destination addresses in packets.

Content delivery works essentially the same way as well. If the network portion of the source and destination IP addresses are in the same defined VCN subnet, delivery is through a logical switch (bridge) based on source and destination MAC frame addresses. If the network portion of the source and destination IP addresses are in different VCN subnets, then delivery is based on source and destination IP packet addresses.

You do not have to configure a logical switch for Oracle Private Cloud Appliance. The MAC addresses are known to all the other entities connected to the logical switch. It is assumed that if you place two or more VMs in the same VCN subnet, it is okay if they communicate. If instance isolation is the goal, then establish separate subnets or VCNs for them.

Logical Routers

Traffic between different VCN subnets is handled by at least one logical router, by definition. Devices that use IP packet addresses to determine forwarding steps, while using different MAC frame addresses on the different subnets they link, are called routers. In the case where the routers attach to the internet, these virtual devices are internet gateways (IGWs).

In cases where the source or destination IP address rules include IP network address translation (NAT), the packets are handled by a NAT gateway of some type (there are several types of NAT gateways). If some form of NAT is used, these are NAT gateways (NATGW or NGW).

In many cases of virtualized cloud networking, routing is very simple and can be handled by a small, static routing table that has a handful of destinations. More complex virtual environments require more complex logical routers, containing dynamic information that is updated periodically.

Logical routers inspect the packet's IP addresses. The IP addresses, source and destination, are looked up in a route table, called the route rule table in the Oracle Private Cloud Appliance, and forwards the packet to the next hop (another router) or destination (for local delivery) if the IP address rule allows this. If the route rules do not apply to the IP addresses, the packet is silently dropped and does not generate an error message (this is a security feature to prevent blocked probes from gathering information). However, this lack of error messages means that the route rules must be configured very carefully.

One IP address is special when it comes to route rules. This is the IPv4 address 0.0.0.0/0, which essentially matches any IP address at all. In some documents, the 0.0.0.0/0 notation is called an IP address CIDR block, but the same universal matching is true no matter what it is called.

For example, the following route rule allows a packet sent from inside the VCN to any IP address at all to reach a gateway to the internet:

Destination                                                          Target
0.0.0.0/0                                          Internet Gateway  vcn-20210714-0910

Route rules do more than determine the destination of a packet. Route rules also form the basis for network firewalls.

Using Firewalls

Internet access is convenient, but brings concerns over vulnerability and security. Firewalls exist to limit the free passage of traffic between network elements and secure the network. A firewall, logical or physical, examines the traffic flow from a particular source to a particular destination and permits or blocks the packets based on the configured security rules in the route rule table.

Firewalls should be configured not only to allow or block traffic from or to external sources, but should also be configured to validate the traffic passing from subnet to subnet within the same VCN. Threats could be coming from external sources, but also from compromised instances within the network.

Use of Network Segmentation

It is tempting to configure a virtual network as one big entity, with everything easily reachable by everything else. But this makes it relatively easy for attackers to compromise the network: once they are in, they are in everywhere. It is much better to use segmentation for the network and group resources and data into the various segments.

In the Oracle Private Cloud Appliance, segments are essentially network security groups.

Typically, you group data and resources based on similarity or data sensitivity. For example, you can establish a group that examines all traffic received from the data center. Based on your security rules, this traffic can then be passed to a group of application servers, and then onto the database servers.

With this approach, firewalls between the groups secure the application and database servers from any compromised components of the data center.

Use of Tunneling

One complication of virtualized cloud networking is that there is no central authority to assign IP addresses to VCN subnets. Nothing stops one hypervisor from assigning, for example, IP address 192.168.1.6 to VM-1 in Subnet-1 of VCN-1, while another hypervisor assigns the same IP address 192.168.1.6 to VM-7 in Subnet-1 of VCN-1. Yet, if various tables are configured correctly, they can still communicate.

In order to effectively hide these network address complications, the Oracle Private Cloud Appliance moves traffic between network components such as logical routers through IP tunnels. However, this use of tunnels, a common IP network practice, does not change the network scenarios. Instances still have IP addresses, and these addresses are still assigned to a particular subnet and the subnets are assigned to virtual network interface cards (VNICs). All traffic from the various running instances under the same a hypervisor is bonded together into an IP tunnel for transport to the next device between source and destination.

Use of Virtual Cloud Networks

It is easy to say that resources are gathered into one or more VCNs, which are private cloud networks running in a tenancy. But there is a lot more to VCNs than declaring a group of resources and creating a boundary for a VCN.

Planning your VCNs is a critical part of any deployment. VCNs serve as a foundation to structure your application servers, databases, and any other services provided. VCNs should take into account any needs such as redundancy, high availability, scalability, security, and more.

This section details the critical parts of a VCN.

IP Address Ranges

When planning VCNs, the first decision to make is which IP address CIDR block to use.

Note:

To help with the calculation of CIDR blocks, a good resource is: IP Address Guide for CIDR

The VCN network address range should be any VLSM between /16 and /30. This covers virtual networks for between 4 available IP addresses (/30) to 65,536 available IP addresses (/16), although the highest and lowest IP address are not useful for endpoint devices.

The size of the CIDR block chosen for the VCN is of critical importance. If the size is too large, then IP addresses are wasted that could be used in other places in the network. If the size is too small, the solution does not scale because there are not enough IP addresses for the VCN. You can always create another VCN and peer them together, but this is a complication that can be avoided through careful planning.

There are some important points about VCN CIDR blocks:

VCNs should use one of the RFC1918 private address ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
VCNs use a contiguous IPv4 CIDR block. IPv6 is not supported.
You cannot change the VCN and subnet sizes (such as 10.100.0.0/21) after their creation. The IP address range must not overlap with any VCN you want to peer with.
Subnets within a VCN must not overlap with each other.
Remember that the highest and lowest IP addresses in a range are reserved for network functions.

IP Subnets

A subnet is a subdivision of a VCN that uses a continuous IP address range as established by CIDR. Subnets group resources by IP address.

From the VCN perspective, subnets can be public or private. In the context of Oracle Private Cloud Appliance, private VCN addresses must be changed using NAT before they can interact with other VCNs that might be using the same private address space. Public VCN addresses allow for connectivity to the data center network and are accessible from outside the rack.

It is, however, possible to have an RFC1918 address space subnetted into both public IP address spaces (which allows external data center connectivity) and private IP address spaces (which connect within the Oracle Private Cloud Appliance rack).

For example, it is possible for a VCN to do this with an IP CIDR block:

Subnet Name                           Subnet Access                               IP CIDR Block

Public_Subnet_01                      Public                                      10.100.0.0/24
Private_Subnet_01                     Private                                     10.100.1.0/24

Public_Subnet_01 has 256 IP addresses, from 10.100.0.0 to 10.100.0.255 (these two addresses are not often used for devices and have special uses in most IP networks). The netmask is 255.255.255.0

Private_Subnet_01 also has 256 IP addresses, from 10.100.1.0 to 10.100.1.255 (again, the low and high addresses are not often useful for devices). The netmask is 255.255.255.0.

Note that the two address ranges do not overlap. (If the public range was 10.100.0.0/23, then 256 devices would overlap with 10.100.1.0/24.)

Route Tables

A VCN uses a route table to hold the rules governing the sending and receiving of traffic by an instance. A VCN could be allowed or prevented form reaching destinations like:

The global public internet
An on-premise network, such as the date center network
A peer VCN

Whenever a VCN is created, a virtual router with a default route table is also created.

For better security, it is preferable to create a dedicated route table for every subnet rather than use the default rules, which might not be adequate for the level of security needed. Dedicated route tables can more effectively manage the route rules that each subnet needs. For example, if the subnet is allowed to send traffic out onto the global public internet, then the route table for that subnet needs a rule for routing traffic to an internet gateway with the "universal destination" 0.0.0.0/0.

Note:

The CIDR block 0.0.0.0/0 matches all addresses in the IPv4 address space. It means "any IPv4 address with any subnet mask."

A subnet not needing global public network access should not include that rule in the route table. In addition:

Traffic with a source and destination within a VCN is not governed by any route table rules.
If rules overlap (usually regarding different CIDR block or subnets), then the more specific rule applies (often seen as "the longest match").
If there is no rule that applies to the traffic flow, then the traffic is silently dropped (no error message sent).

Every rule in the route table has a target. The targets are the functional network nodes for the common components of any network:

Dynamic Routing Gateway (DRG: the route table rules are not statically configured, but use a routing protocol such as BGP to change them).
Internet Gateway (IG) to connect to the global public internet.
NAT gateway (NATG) for IP address translation.
Service Gateway (SG) to reach a variety of services in other subnets.
Local Peering Gateway (LPG) to connect to peer VCNs.
Private IP address, which routes traffic to a specific instance inside the VCN.

As an example, a VCN could contain a route table with the following rules:

Subnet Name                           Route Table                                Target

Public_Subnet_01                      Public_Subnet_01_Route_Table               IG
Private_Subnet_01                     Private_Subnet_01_Route_Table              NAT Gateway

Route tables are the foundation of VCN security.

Security Lists and Network Security Groups

It might seem odd that an on-premises network needs firewall-like security. But security is important in every context, and not all threats come from outside an organization.

Oracle Private Cloud Appliance offers two security networking mechanisms that act like firewalls to control traffic at the packet level:

Security lists, which are used like physical firewalls for subnets.
Network security groups (NSGs), which act as firewalls for groups of instances across subnets.

You use a security list to define the rules that apply to all inbound (ingress) and outbound (egress) traffic of a subnet. You can associate up to five security lists per subnet. In the same way as route tables, there are default security lists and dedicated security lists. For better control and management, you should always use dedicated security lists for each subnet.

In contrast to security lists, NSGs let you build rules for groups of instances, even if the instances are in different subnets. For example, the same NSG can apply to all the database servers, or all the application servers running a certain application. Instead of applying security to a particular subnet, you create an NSG and then add the appropriate instances to the NSG.

There is no requirement to use either security lists or NSGs. You can use security lists without establishing NSGs, or create NSGs without creating any security lists. However, if you use both security lists and NSGs, the rules that apply to a VNIC are the union (both sets) of the rules that are in the security list for the VNIC and the rules specific to that VNIC from the NSG.

When creating a VCN, a default security list with three ingress rules and one egress rule is created. The default rules are stateful, which means that they know what connections are and that a request is followed by a response and that the rules should take this into consideration. In contrast, stateless rules are applied to every packet regardless of situation.

The default ingress and egress security rules look like this if you display them:. First, the ingress rules (for a 10.0.0.0/16 CIDR block):

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        10.0.0.0/16  CIDR Block   ICMP                                                  3
No        0.0.0.0/0    CIDR Block   ICMP                                                  3, 4
No        0.0.0.0/0    CIDR Block   TCP         22 - 22            22 - 22

These rules, line by line, can be read as:

There is a stateful rule that apples to traffic originating from the VCN 10.0.0.0/16 CIDR block using the ICMP protocol Type = 3 message format (Destination Unreachable) and all Codes. In other words, this rule allows devices in the 10.0.0.0/16 CIDR block to pass Destination Unreachable messages with any code (such as Net or Host Unreachable) back to the sender (another instance in the VCN subnet).
There is a stateful rule that apples to traffic originating from any IP address (0.0.0.0/0 CIDR block) using the ICMP protocol Type = 3 message format (Destination Unreachable) and a Code = 4 (message must be fragmented, but the Do Not Fragment (DF) bit is set in the packet: these are Path MTU Discovery messages). In other words, this rule allows devices to notify sources that the DF bit is set on packets that need to be fragmented because the content exceeds the MTU size established for this VCN subnet.
There is a stateful rule that apples to traffic originating from any IP address (0.0.0.0/0 CIDR block) using the connection-oriented TCP protocol and with the Source or Destination Port = 22 (SSH). In other words, this rule allows SSH for this VCN subnet.

This last rule makes allows you to create a new VCN and subnet, launch a Linux instance, and then use SSH to connect to that instance without writing any new security list rules.

Important:

The default ingress security list does not include a rule to allow Remote Desktop Protocol (RDP) access. If you're using Windows images, make sure to add a stateful ingress rule for TCP traffic on destination port 3389 from authorized source IP addresses and any source port. See To enable RDP access for more information.

The single egress rule is very simple:

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        0.0.0.0/0    CIDR Block   All

This can be read as: "There is a stateful rule that allows packets with any source address and for any IP protocol at all to leave the VCN." This basically says that anything can leave the VCN subnet without a problem.

The default security list comes with no stateless rules. However, you can always add or remove rules from the default security list.

To use these default rules in an NSG, let's give the default ingress and egress rules distinctive names, such as Ingress_Security_List_Subnet01 and Egress_Security_List_Subnet01. Before you can add these rules to an NSG, you must first create the NSG. To create an NSG, you must give it a name and assign it to an existing compartment. You can also add tags, but these can be added later.