Virtual Networking Overview

6 Virtual Networking Overview

When building a private cloud, one of the first steps is to design and configure a virtual cloud network for your cloud resources. This chapter provides an overview of the components made available to you by the Networking service. Several of them are virtual versions of the traditional network components you might already be familiar with.

The sections in this chapter explain how the Networking service works and how you use it to design your virtual cloud network, connect it with your on-premises network, control traffic that flows through it, and so on. The detailed descriptions of typical network scenarios might provide a good starting point for your own configuration.

Virtual Cloud Network

A virtual cloud network, or VCN, is a software-defined equivalent of a traditional network, with firewall rules and various types of communication gateways. A VCN resides in the single region of your Private Cloud Appliance installation and covers one contiguous CIDR block of your choice.

The size of a VCN is /16 to /30. The CIDR block can NOT be changed after the VCN is created. The maximum number of private IPs within a VCN is 64,000. Oracle recommends using a private IP address range as specified in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). This documentation uses the term private IP address when referring to IP addresses in your VCN's CIDR.

You can privately connect a VCN to another VCN so that traffic does not leave the secure network environment of the appliance. However, the CIDRs of the two VCNs must not overlap. The concept of privately connecting VCNs is called peering. It involves setting up a type of virtual router known as a Local Peering Gateway. For more information about the use of gateways in your VCNs, see Network Gateways.

Subnets

A VCN is subdivided into subnets. Each subnet in a VCN consists of a contiguous range of IPv4 addresses that do not overlap with other subnets in the VCN. Example: 172.16.1.0/24. The first two IPv4 addresses and the last in the subnet's CIDR are reserved by the Networking service. You cannot change the size of the subnet after creation.

Subnets act as a unit of configuration: all instances in a given subnet use the same route table, security lists, and DHCP options. Subnets can be either public or private. This is defined when the subnet is created, and cannot be changed later. In a private subnet, instances cannot be assigned a public IP address.

You can think of a compute instance as residing in a subnet. However, to be precise, each instance is attached to a virtual network interface card (VNIC), which in turn resides in the subnet and enables a network connection for that instance.

IPv6 addressing is currently not supported in Private Cloud Appliance.

Route Tables

Each VCN automatically comes with an empty default route table. Subnets use the default route table of the parent VCN, unless you explicitly assign them a different route table. When you add route rules to your VCN, you can simply add them to the default table if that suits your needs. However, if you need both a public subnet and a private subnet, you instead create a separate custom route table for each subnet.

The primary routing scenario is for sending a subnet's traffic to destinations outside the VCN. A subnet has a single route table of your choice associated with it at the time of creation. All VNICs in that subnet are subject to the rules in the route table. Traffic within the VCN is automatically handled by the VCN internal routing. No route rules are required to enable that traffic. You can change which route table the subnet uses at any time. You can also edit a route table's rules, or remove all the rules from the table.

A route rule specifies a destination CIDR block and the target, or the next hop, for any traffic that matches that CIDR. When selecting the target you also specify its compartment. Supported target types for a route rule are the different VCN gateways.

Route rules must be configured carefully to ensure that the network traffic reaches the intended destination and is not dropped. Moving route rules between compartments is not supported.

Public Network in Private Cloud

Oracle Private Cloud Appliance is a private cloud solution. The infrastructure that provides the necessary services to deploy your cloud workloads, is configured to operate within the network environment of your data center. During initialization, the appliance core network components are integrated with your existing data center network design. Uplink ports in the appliance switches connect to your next-level data center switches to provide a redundant high-speed and high-bandwidth physical connection that carries all traffic into and out of the appliance.

This is a critical difference with a public cloud environment, where the infrastructure is managed by your service provider, who grants you restricted access to systems in their data center. Because your cloud resources are not inside your own network, you access them over the internet, using a secure tunneling connection. In this context, network traffic between your public cloud and locations external to it, is sent over the internet by definition. In other words, from the perspective of your cloud environment, the public network is effectively the internet. Compare this with the private cloud environment, where the public network is your on-premises network, and internet access is always indirect through your data center edge router.

Private Cloud Appliance is modeled after Oracle's public cloud offering: Oracle Cloud Infrastructure. This applies not only to the Networking service but to all the major infrastructure services: they have been optimized for the smaller scale of a single rack, while offering the same core functionality. One of the main objectives is to maintain maximum compatibility between both cloud platforms: this provides a very similar user experience and allows you to efficiently migrate workloads between your private cloud environment and your Oracle Cloud Infrastructure account.

Because the public cloud network model is applied to a private cloud environment, where the public network is actually the data center network, certain network resources or components present a different behavior. You need to be aware of these differences when designing and configuring the virtual cloud networks in Private Cloud Appliance.

Access to the on-premises network

The appliance rack is located at your premises: it is set up inside your data center and connected directly to your on-premises network. There is no need for a secure tunnel over the internet to allow your cloud resources and your on-premises network to communicate with each other. Access is enabled through a gateway between your virtual cloud network (VCN) and your on-premises network.
Access to the internet

Resources in your cloud environment have no direct internet access. In contrast with a public cloud environment, no gateway is capable of enabling direct internet connectivity for a VCN. Public connectivity implies that resources have access to the data center network. The configuration of the networking components in the data center determines how cloud resources can connect to the internet and whether they can be reached from the internet.
VCN gateways

To manage network traffic into and out of your VCNs several types of gateways are used. Resources in a VCN can connect to external hosts through either a dynamic routing gateway (DRG), a NAT gateway or an internet gateway. Technically, each of these gateways provides a path to your on-premises network. However, a DRG has an important limitation in that it performs no address translation and thus cannot handle any overlap between VCNs and the on-premises network.

Although these gateways seem interchangeable to a certain extent, it is important to configure and use them strictly for their intended purpose. It helps to ensure that your private cloud network configuration remains compatible with the public cloud network model. If you move a workload into Oracle Cloud Infrastructure, the data center network is removed from the equation, meaning the NAT and internet gateways will provide direct internet access, and a DRG will only provide access to your on-premises network.
Public IP addresses

From the perspective of a virtual cloud network, the public network is effectively the data center network, so a public IP address must be within its CIDR. To accommodate this, you must reserve an address range within the data center CIDR to be used exclusively by Private Cloud Appliance. You typically configure the public IP range during initial system setup. You can extend the range at a later time, but removing IPs is not allowed. The Networking service uses this range as a pool, from which it assigns public IP addresses to cloud resources that require them. A public IP makes a resource reachable from outside the VCN it resides in. In a private cloud context, it allows interaction with other resources in the data center or the on-premises network. The IPs that are considered "public" are really part of the data center's private range.

The use of public IPs has different implications when you move a particular workload into Oracle Cloud Infrastructure, where public IPs are truly unique and publicly routable. True public IPs are scarce and expensive resources. Take this into account when designing applications and services in a private cloud environment: use private IPs to enable connectivity between components and assign public IPs only where true public connectivity is required.

Instance Connectivity

This section discusses different aspects of instance connectivity.

Virtual Network Interface Cards (VNICs)

The compute nodes in the Private Cloud Appliance have physical network interface cards (NICs). When you create and launch a compute instance on one of the servers, the Networking service ensures that a VNIC is created on top of a physical interface, so that the instance can communicate over the network. Each instance has a primary VNIC that is automatically created and attached during launch. The primary VNIC resides in the subnet you specify when creating the instance. It cannot be removed from the instance.

A VNIC enables an instance to connect to a VCN and determines how the instance communicates with endpoints inside and outside of the VCN. Each VNIC resides in a subnet within a VCN and includes these items:

One primary private IPv4 address from the subnet the VNIC is in.
Up to 31 optional private IPv4 addresses from the subnet the VNIC is in.
An optional public IPv4 address for each private IP, assigned at your discretion.
An optional host name for DNS for each private IP address.
A MAC address.
A flag to enable or disable the source/destination check on the VNIC's network traffic.
Optional membership of one or more network security groups (NSGs).
An Oracle-assigned identifier (OCID).
An optional friendly name you can choose and assign.

You can add secondary VNICs to an instance after it is launched. To be able to use a secondary VNIC, you must also configure the instance OS for it. The maximum number of VNICs for an instance varies by shape. Each secondary VNIC can be in a different subnet than the primary VNIC, either within the same VCN or a different one. A secondary VNIC can also be in the same subnet as the primary VNIC. However, attaching multiple VNICs from the same subnet CIDR block to an instance can introduce asymmetric routing, especially on Linux instances.

Note:

To avoid asymmetric routing in a configuration with multiple IP addresses from the same subnet, Oracle recommends assigning multiple private IP addresses to one VNIC, or using policy-based routing.

If traffic comes in to a service on the instance through a secondary VNIC and the service replies, the reply packets automatically have that VNIC's IP address as the source IP address. Policy-based routing is required for that reply to go back out on the same interface and find the correct default gateway.

Secondary VNICs must always be attached to an instance and cannot be moved. The process of creating a secondary VNIC automatically attaches it to the instance. The process of detaching a secondary VNIC automatically deletes it. They are automatically detached and deleted when you terminate the instance. An instance's bandwidth is fixed regardless of the number of VNICs attached. You cannot specify a bandwidth limit for a particular VNIC on an instance.

By default, every VNIC performs the source/destination check on its network traffic. The VNIC looks at the source and destination listed in the header of each network packet. If the VNIC is not the source or destination, then the packet is dropped. If the VNIC needs to forward traffic – for example, if it needs to perform Network Address Translation (NAT) – you must disable the source/destination check on the VNIC.

VNICs reside in a subnet but attach to an instance. The VNIC's attachment to the instance is a separate object from the VNIC or the instance itself. The VNIC and subnet always exist together in the same compartment, but the VNIC's attachment to the instance always exists in the instance's compartment. This distinction affects your IAM policies if you set up an access control scenario where network administrators manage the network and other users manage instances.

IP Addressing

Instances use IP addresses for communication. Each instance has at least one private IP address and optionally one or more public IP addresses. A private IP address enables the instance to communicate with other instances inside the VCN, or with hosts in your on-premises network. A public IP address enables the instance to communicate with hosts outside of the Private Cloud Appliance network environment.

Certain types of resources in your tenancy are designed to be directly reachable from outside the secure appliance network environment, and therefore automatically come with a public IP address. For example: a NAT gateway. Other types of resources are directly reachable only if you configure them to be. For example: specific instances in your VCN. Direct public connectivity also requires that the VCN has an internet gateway and that the public subnet has correctly configured route tables and security lists.

Private IPs

The Networking service defines a private IP object, identified by an Oracle-assigned OCID, which consists of a private IPv4 address and optional host name for DNS. Each instance receives a primary private IP object during launch. The Networking service uses DHCP to assign a private IP address. This address does not change during the instance's lifetime and cannot be removed from the instance. The private IP object is terminated when the instance is terminated.

If an instance has any secondary VNICs attached, each of those VNICs also has a primary private IP. A private IP can have a public IP assigned to it at your discretion. It is not supported to use a private IP as the target of a route rule in your VCN.

About Secondary Private IPs

After an instance is launched, you can add a secondary private IP to one of its VNICs. You can add it to either the primary VNIC or a secondary VNIC on the instance. The secondary private IP address must be in the subnet to which the VNIC belongs. You can move a secondary private IP from a VNIC on one instance to a VNIC on another instance on condition that both VNICs belong to the same subnet.

Typical use cases for a secondary private IP include:

Instance failover: You assign a secondary private IP to an instance. If a problem occurs with the instance, you can easily reassign its secondary private IP to a standby instance in the same subnet. In additon, if the secondary private IP has an associated public IP, that public IP moves along with the private IP.
Running multiple services or endpoints on a single instance: For example, you could have an instance that runs multiple container pods, where each pod uses its own IP address from the VCN's CIDR. The containers have direct connectivity to other instances and services in the VCN. Another example: you could run multiple SSL web servers with each one using its own IP address.

Secondary private IP addresses have the following properties:

They are supported for all shapes and OS types.
They can be assigned only after the instance is launched, or the secondary VNIC is created and attached.
They are automatically deleted when you terminate the instance or detach and delete the secondary VNIC.
Deleting a secondary private IP from a VNIC returns the address to the pool of available addresses in the subnet.
A VNIC can have a maximum of 31 secondary private IPs.
The instance's bandwidth is fixed regardless of the number of private IP addresses attached. You cannot specify a bandwidth limit for a particular IP address on an instance.
A secondary private IP can have a reserved public IP associated with it at your discretion.

Note:

After assigning a secondary private IP to a VNIC, you must configure the instance OS to use it. For Linux and Microsoft Windows instructions, refer to the Oracle Private Cloud Appliance User Guide.

Public IPs

In a private cloud model, public IP addresses are not true unique and publicly routable internet IPs; they are just addresses external to the VCNs in the cloud environment. During initial setup of the appliance, a pool of addresses from the on-premises network is reserved for use as public IPs. A small set of these public IPs is required for system use.

You can assign a public IP address to an instance to enable external communication. The instance is assigned a public IP address from an address pool. Technically, the assignment is to a private IP object on the instance, and the VNIC that the private IP is assigned to must reside in a public subnet. A given instance can have multiple secondary VNICs; each with a (primary) private IP. Consequently, you can assign a given instance multiple public IPs across their VNICs.

The Networking service defines a public IP object, identified by an Oracle-assigned OCID, which consists of a private IPv4 address and additional properties that further define the public IP's type and behavior. There are two types of public IPs:

An ephemeral public IP is temporary and exists for the lifetime of the instance.
A reserved public IP is persistent and exists beyond the lifetime of the instance it is assigned to. It can be unassigned and then reassigned to another instance.

The following table summarizes the differences between both types:

Characteristics	Ephemeral Public IP	Reserved Public IP
Allowed assignment	to a VNIC's primary private IP limits: one per VNIC, two per instance	to a VNIC's primary private IP limit: one per VNIC
Creation	Optionally created and assigned during instance launch or secondary VNIC creation. You can create and assign one later if the VNIC doesn't already have one.	You create one at any time. You can then assign it when you like.
Unassignment	You can unassign it at any time, which deletes it. You might do this if whoever launched the instance included a public IP, but you do not want the instance to have one. When you stop an instance, its ephemeral public IPs remain assigned to the instance.	You can unassign it at any time, which returns it to your tenancy's pool of reserved public IPs.
Moving to a different resource	You cannot move an ephemeral public IP to a different private IP.	You can move it at any time by unassigning and then reassigning it to another private IP. Can be in a different VCN or availability domain.
Automatic deletion	Its lifetime is tied to the private IP's lifetime. Automatically unassigned and deleted when: its private IP is deleted its VNIC is detached or terminated its instance is terminated	Never. Exists until you delete it.
Scope	Availability domain	Regional (can be assigned to a private IP in any availability domain in the region)
Compartment and availability domain	Same as the private IPs	Can be different from the private IPs

When you launch an instance in a public subnet, the instance gets a public IP by default, unless you specify otherwise. After you create a given public IP, you cannot change which type it is. For example, if you launch an instance that is assigned an ephemeral public IP with address 203.0.113.2, you cannot convert the ephemeral public IP to a reserved public IP with address 203.0.113.2.

Resources that are designed to be directly publicly reachable automatically get a public IP address assigned from a pool upon creation. For NAT gateways, the assigned address is a regional ephemeral public IP. Like other ephemeral public IPs, it is automatically unassigned and deleted when you terminate its assigned resource. However, unlike other ephemeral public IPs, you cannot edit it or unassign it yourself.

DHCP Options

The Networking service uses DHCP to automatically provide configuration information to instances when they boot up. Although DHCP lets you change some settings dynamically, others are static and never change. For example, when you launch an instance, either you specify the instance's private IP address or the system chooses one for you. Each time the instance boots up or you restart the instance's DHCP client, DHCP passes that same private IP address to the instance. The address never changes during the instance's lifetime.

The Networking service provides DHCP options to let you control certain types of configuration on the instances in your VCN. You can change the values of these options at your discretion, and the changes take effect the next time you restart a given instance's DHCP client or reboot the instance.

Each subnet in a VCN can have a single set of DHCP options associated with it. That set of options applies to all instances in the subnet. Each VCN comes with a default set of DHCP options with initial values that you can change. Unless you create and assign a different set of DHCP options, every subnet uses the VCN's default set.

These are the available DHCP options you can configure:

Domain Name Server

The default setting is DNS Type = Internet and VCN Resolver.

If instead you set DNS Type = Custom Resolver, you can specify up to three DNS servers of your choice.
Search Domain

If you set up your VCN with a DNS label, the default value for the Search Domain option is the VCN domain name: <VCN_DNS_label>.oraclevcn.com. Otherwise, the Search Domain option is not present in the default set of DHCP options.

In general, when any set of DHCP options is initially created – the default set or a custom set –, the Networking service automatically adds the Search Domain option and sets it to the VCN domain name (<VCN_DNS_label>.oraclevcn.com) if all of these are true:
- The VCN has a DNS label.
- DNS Type = Internet and VCN Resolver.
- You did NOT specify a search domain of your choice during creation of the set of DHCP options.
After the set of DHCP options is created, you can always remove the Search Domain option or set it to a different value. You can specify only a single search domain in a set of DHCP options.

Important notes about your instances and DHCP options:

Whenever you change the value of one of the DHCP options, you must either restart the DHCP client on the instance, or reboot the instance for the changes to take effect. This applies to all existing instances in the subnets associated with that set of DHCP options.
Keep the DHCP client running so you can always access the instance. If you stop the DHCP client manually or disable NetworkManager, the instance cannot renew its DHCP lease and will become inaccessible when the lease expires; typically within 24 hours. Do not disable NetworkManager unless you use another method to ensure renewal of the lease.
Stopping the DHCP client might remove the host route table when the lease expires. Also, loss of network connectivity to your iSCSI connections might result in loss of the boot drive.
Any changes you make to the /etc/resolv.conf file are overwritten whenever the DHCP lease is renewed or the instance is rebooted.
Changes you make to the /etc/hosts file are overwritten whenever the DHCP lease is renewed or the instance is rebooted. To persist your changes to the /etc/hosts file in Oracle Linux or CentOS instances, add the following line to /etc/oci-hostname.conf: PRESERVE_HOSTINFO=2. If the /etc/oci-hostname.conf file does not exist, create it.

Name Resolution

The Domain Name System (DNS) translates human-readable domain names to machine-readable IP addresses. For example, when you type a domain name into your browser, your operating system queries several DNS name servers until it finds the authoritative name server for that domain. The authoritative name server then responds with an IP address or other requested record data; the answer is relayed back to your browser and the DNS record is resolved to the web page.

For DNS name resolution within your VCN, there are two options. You choose an option for each subnet in the VCN, using the subnet's set of DHCP options.

The default choice is the Internet and VCN Resolver, an Oracle-provided solution. It consists of two parts: the Internet Resolver and the VCN Resolver. The Internet Resolver lets instances resolve host names that are publicly published on the internet, without requiring the instances to have internet access by way of either an internet gateway or a connection to the on-premises network. The VCN resolver lets instances resolve host names, which you can assign, of other instances in the same VCN.

Alternatively, you can use a Custom Resolver. It allows you to use up to three DNS servers of your choice for name resolution. These could be DNS servers that are available through the internet, in your VCN, or in your on-premises network, which is connected to your VCN through a DRG.

Domains and Host Names

When you create a VCN and subnets, you can specify DNS labels for each. Subnet DNS labels can only be set if the VCN itself is created with a DNS label. The labels, along with the parent domain of oraclevcn.com form the VCN domain name and subnet domain name. Next, when you launch an instance, you can assign a host name. It is assigned to the primary VNIC that is automatically created during instance launch. Along with the subnet domain name, the host name forms the instance's fully qualified domain name (FQDN).

VCN domain name: <VCN_DNS_label>.oraclevcn.com
Subnet domain name: <subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com
Instance FQDN: <host_name>.<subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com

The FQDN resolves to the instance's private IP address. The Internet and VCN Resolver also enables reverse DNS lookup, which lets you determine the host name corresponding to the private IP address.

If you add a secondary VNIC to an instance, you can specify a host name. The resulting FQDN resolves to the VNIC's primary private IP address. The resulting FQDN resolves to that private IP address.

DNS labels and host names must meet these requirements:

VCN and subnet labels must start with a letter and have a maximum length of 15 alphanumeric characters. Hyphens and underscores are not allowed. The value cannot be changed later.
Host names can be up to 63 characters in length and must be compliant with RFCs 952 and 1123. The value can be changed later.
VCN DNS labels must be unique across the VCNs in your tenancy. Subnet DNS labels must be unique within the VCN, and host names must be unique within the subnet.

Host Name Validation and Generation

If you set DNS labels for VCN and subnet, the host name is validated for compliance during instance launch. If you have not specified a host name, the system attempts to use the instance display name. If the display name does not pass validation, or if you did not specify one, the system generates a DNS-compliant host name. The generated host name is displayed on the instance’s detail page in the Compute Web UI.

If you launch an instance using the CLI or SDK, and you have not specified a host name or display name, the system does not generate them for you. This means the instance will not be resolvable using the Internet and VCN Resolver.

If you add a secondary VNIC to an instance, the system never generates a host name. You must provide a valid host name if you want the private IP address to be resolvable using the Internet and VCN Resolver.

Public DNS Zones

To enable DNS name resolution for instances deployed inside your VCNs, from outside the appliance network environment, Private Cloud Appliance provides configuration support for public DNS zones. Within your tenancy you create the DNS zones, or sections of the DNS namespace, you intend to manage through the Compute Web UI. The edge network of the appliance handles all DNS queries for the domain(s) in question.

When creating a DNS zone, you specify the name of the domain it manages – for example: example.com. You select whether the zone is primary or secondary. A primary zone contains its own DNS records, while a secondary zone retrieves its records from another zone. To access the external zone's records, the secondary zone needs at least one server IP address for the external zone. In addition, a TSIG (Transaction Signature) key may be required. TSIG keys are shared secrets used for authentication of secondary DNS zones. You can store these keys in the compartment of your choice.

Each DNS zone you create automatically contains two essential records:

The SOA (Start of Authority) record specifies authoritative information about the DNS zone. This information includes the primary name server, the domain administrator email address, the domain serial number, and several timers related to refreshing the zone. For more information about SOA records, see RFC 1035.
The NS (Name Server) record lists the authoritative name servers for a zone. For more information about NS records, see RFC 1035.

You configure the DNS zone by adding specific domain information in the form of resource records. For example, using an address record, you make a domain name resolve to the public IP address of an instance in a public subnet of a VCN. The public DNS zones in Private Cloud Appliance support the resource record types described in the table below.

Resource Record Type	Description
A	An address record used to point a host name to an IPv4 address. For more information about A records, see RFC 1035.
AAAA	An address record used point a host name at an IPv6 address. For more information about AAAA records, see RFC 3596.
ALIAS	A private pseudo-record that allows CNAME functionality at the apex of a zone.
CAA	A Certification Authority Authorization record allows a domain name holder to specify one or more Certification Authorities authorized to issue certificates for that domain. For more information about CAA records, see RFC 6844.
CDNSKEY	A Child DNSKEY moves a CDNSSEC key from a child zone to a parent zone. The information provided in this record must match the CDNSKEY information for your domain at your other DNS provider. This record is automatically created if you enable DNSSEC on a primary zone in Private Cloud Appliance DNS. For more information about CDNSKEY, see RFC 7344.
CDS	A Child Delegation Signer record is a child copy of a DS record, for transfer to a parent zone. For more information about CDS records, see RFC 7344.
CERT	A Certificate record stores public key certificates and related certificate revocation lists in the DNS. For more information about CERT records, see RFC 2538 and RFC 4398.
CNAME	A Canonical Name record identifies the canonical name for a domain. For more information about CNAME records, see RFC 1035.
CSYNC	A Child-to-Parent Synchronization record syncs records from a child zone to a parent zone. For more information about CNAME records, see RFC 7477.
DHCID	A DHCP identifier record provides a way to store DHCP client identifiers in the DNS to eliminate potential host name conflicts within a zone. For more information about DHCID, see RFC 4701.
DKIM	A Domain Keys Identified Mail is a special TXT record set up specifically to supply a public key used to authenticate arriving mail for a domain. For more information about DKIM records, see RFC 6376.
DNAME	A Delegation Name record has similar behavior to a CNAME record, but allows you to map an entire subtree beneath a label to another domain. For more information about DNAME records, see RFC 6672.
DNSKEY	A DNS Key record documents public keys used for DNSSEC. The information in this record must match the DNSKEY information for your domain at your other DNS provider. For more information about DNSKEY records, see RFC 4034.
DS	A Delegation Signer record resides at the top-level domain and points to a child zone's DNSKEY record. DS records are created when DNSSEC security authentication is added to the zone. For more information about DS records, see RFC 4034.
IPSECKEY	An IPSec Key record stores public keys for a host, network, or application to connect to IP security (IPSec) systems. For more information on IPSECKEY records, see RFC 4025.
KEY	A Key record stores a public key that is associated with a domain name. Currently only used by SIG and TKEY records. IPSECKEY and DNSKEY have replaced key for use in IPSec and DNSSEC, respectively. For more information about KEY records, see RFC 4025.
KX	A Key Exchanger record identifies a key management agent for the associated domain name with some cryptographic systems (not including DNSSEC). For more information about KX records, see RFC 2230.
LOC	A Location record stores geographic location data of computers, subnets, and networks within the DNS. For more information about LOC records, see RFC 1876.
MX	A Mail Exchanger record defines the mail server accepting mail for a domain. MX records must point to a host name. MX records must not point to a CNAME or IP address. For more information about MX records, see RFC 1035.
NS	A Nameserver record lists the authoritative nameservers for a zone. NS records are automatically generated at the apex of each new primary zone you create. For more information about NS records, see RFC 1035.
PTR	A Pointer record reverse maps an IP address to a hostname. This behavior is the opposite of an A Record, which forward maps a hostname to an IP address. PTR records are commonly found in reverse DNS zones. For more information about PTR records, see RFC 1035.
PX	A resource record used in X.400 mapping protocols. For more information about PX records, see RFC 822 and RFC 2163.
SOA	A Start of Authority record specifies authoritative information about a DNS zone, including: the primary nameserver the email of the domain administrator the domain serial number several timers relating to refreshing the zone An SOA record is generated automatically when a zone is created. For more information about SOA records, see RFC 1035.
SPF	A Sender Policy Framework record is a special TXT record used to store data designed to detect email spoofing. For more information about SPF records, see RFC 4408.
SRV	A Service Locator record allows administrators to use several servers for a single domain. For more information about SRV records, see RFC 2782.
SSHFP	An SSH Public Key Fingerprint record publishes SSH public host key fingerprints using the DNS. For more information about SSHFP records, see RFC 6594.
TLSA	A Transport Layer Security Authentication record associates a TLS server certificate, or public key, with the domain name where the record is found. This relationship is called a TLSA certificate association. For more information about TLSA records, see RFC 6698.
TXT	A Text record holds descriptive, human readable text, and can also include non-human readable content for specific uses. It is commonly used for SPF records and DKIM records that require non-human readable text items. For more information about TXT records, see RFC 1035.

Traffic Management Steering Policies

Steering Policies enable you to configure policies to serve intelligent responses to DNS queries, meaning different answers (endpoints) may be served for the query depending on the logic defined in the policy. Private Cloud Appliance supports these types of traffic management steering policies:

Policy Type	Description
Load Balancer	Load Balancer policies allow distribution of traffic across multiple endpoints. Endpoints can be assigned equal weights to distribute traffic evenly across the endpoints, or custom weights may be assigned for ratio load balancing.
IP Prefix Steering	IP Prefix steering policies enable you to steer DNS traffic based on the IP Prefix of the originating query. You can divide users into groups based on the subnets from where requests originate, and steer them to specific resources based on the subdivision you made. For example, you can serve different responses for your internal users as opposed to external users.

Policy Type

Description

Load Balancer

Load Balancer policies allow distribution of traffic across multiple endpoints.

Endpoints can be assigned equal weights to distribute traffic evenly across the endpoints, or custom weights may be assigned for ratio load balancing.

IP Prefix Steering

IP Prefix steering policies enable you to steer DNS traffic based on the IP Prefix of the originating query.

You can divide users into groups based on the subnets from where requests originate, and steer them to specific resources based on the subdivision you made. For example, you can serve different responses for your internal users as opposed to external users.

A steering policy contains rules to answer DNS queries. You use those rules to filter answers based on the properties of the DNS request. When multiple answers are served in response to DNS queries, that group of answers is called an answer pool. The answers within a pool are sorted by priority and are marked eligible or ineligible. Ineligible answers are omitted from the response.

When attached to a DNS zone, a steering policy takes precedence over all resource records of the zone it covers, and causes DNS responses to be constructed from the steering policy rules instead. For example, if a steering policy attached to the example.com DNS zone contains a rule covering the domain application.example.com and an answer for the A (address) record type, then the steering policy responds with that answer regardless of any relevant A records that exist in the zone. If a steering policy has no answer for the record type being requested, the DNS request is passed on to the next steering policy or the base zone records.

Steering policies only support records of the types A, AAAA, CNAME. A domain can have at most one steering policy attachment covering a given record type. This means a DNS zone (example.com) may have multiple attached steering policies covering different record types for a given domain – for example, one A record policy and one CNAME record policy for application.example.com. A DNS zone may also have multiple attached steering policies covering a given record type for different domains – for example, an A record policy for application.example.com and an A record policy for database.example.com. However, multiple steering policies for the same domain and record type are not supported, because the answer can be provided by only one policy.

Network Gateways

To manage traffic to and from a VCN, you can add optional virtual routers, which provide additional functions. You set up rules in route tables to route traffic from the subnets through a gateway to destinations outside the VCN. This section describes the role and usage of each gateway type.

Dynamic Routing Gateway

A dynamic routing gateway, or DRG, provides a path for private network traffic between your VCN and an on-premises network. In the context of Private Cloud Appliance, this traffic is routed to the data center network and on to its destination. The data center network is considered a public network because it is external to the appliance environment. However, no form of tunneling is required since traffic does not travel over the internet. This is a significant difference with public cloud environments.

For the purpose of access control, when creating a DRG, you must specify the compartment where you want the DRG to reside. If you are not sure which compartment to use, put the DRG in the same compartment as the VCN.

A DRG is a standalone object. To use it, you must attach it to a VCN. In the API, the process of attaching creates a DRG Attachment object with its own OCID. To detach the DRG, you delete the attachment object.

A VCN can be attached to only one DRG at a time, though a DRG can be attached to multiple VCNs. You can detach a DRG and reattach it at any time. After attaching a DRG, you must update the routing in the VCN to use the DRG. Otherwise, traffic from the VCN will not flow to the DRG.

The basic routing scenario sends traffic from a subnet in the VCN to the DRG. When sending traffic from the subnet to your on-premises network, you set up a rule in the subnet's route table. The rule's destination CIDR is the CIDR for the on-premises network or a subnet within, and the rule's target is the DRG.

NAT Gateway

A NAT gateway gives cloud resources without a public IP access to the on-premises network, which is an external public network from the point of view of a VCN, without exposing those resources. You create a NAT gateway in the context of a specific VCN, so the gateway is automatically attached to that VCN upon creation. The gateway allows hosts to initiate connections to the on-premises network and receive responses, but prevents them from receiving inbound connections initiated from the on-premises network. NAT gateways are highly available and support TCP, UDP, and ICMP ping traffic. The Networking service automatically assigns a public IP address to the NAT gateway. You cannot choose its public IP address.

When a host in the private network initiates a connection to the on-premises network, the NAT device's public IP address becomes the source IP address for the outbound traffic. The response traffic from the on-premises network therefore uses that public IP address as the destination IP address. The NAT device then routes the response back to the private network, to the host that initiated the connection.

VCN routing is controlled at the subnet level, so you can specify which subnets use a NAT gateway. Private Cloud Appliance only supports one NAT gateway per VCN.

For the purpose of access control, when creating a NAT gateway, you must specify the compartment where you want the gateway to reside. If you are not sure which compartment to use, put the gateway in the same compartment as the VCN.

By default, a NAT gateway allows traffic at the time of creation. However, you can block or allow traffic through the gateway at any time. Blocking a NAT gateway prevents all traffic, regardless of any existing route rules or security rules in the VCN.

Internet Gateway

An internet gateway connects the edge of the VCN with the on-premises network. The ultimate target of the traffic routed through an internet gateway may be the internet. However, in a private cloud model, the internet gateway routes traffic to the on-premises network. Traffic to and from the internet is then managed by the routing configuration in the on-premises network.

You create an internet gateway in the context of a specific VCN, so the gateway is automatically attached to that VCN upon creation. To use the gateway, the hosts on both ends of the connection must have public IP addresses for routing. Connections that originate in your VCN and are destined for a public IP address, either inside or outside the VCN, go through the internet gateway. Connections that originate outside the VCN and are destined for a public IP address inside the VCN also go through the internet gateway.

A given VCN can have only one internet gateway. You control which public subnets in the VCN can use the gateway by configuring the subnet's associated route table. The public subnet's security list rules ultimately determine the specific types of traffic that are allowed to and from the resources in the subnet. An internet gateway can be disabled, meaning no traffic flows to or from the internet, regardless of any existing route rules that enable such traffic.

For the purpose of access control, when creating an internet gateway, you must specify the compartment where you want the gateway to reside. If you are not sure which compartment to use, put the gateway in the same compartment as the VCN.

Local Peering Gateway

VCN peering is the process of connecting multiple virtual cloud networks (VCNs) so that resources can communicate using private IP addresses. 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. You can also place shared resources into a single VCN that all the other VCNs can access privately. Two peered VCNs can be in the same tenancy or different ones.

The following components are required to set up a peering connection:

Two VCNs with non-overlapping CIDRs
A local peering gateway (LPG) on each VCN in the peering relationship
A connection between the two LPGs
Route rules to enable traffic over the peering connection to and from the desired subnets in the respective VCNs
Security rules to control the types of traffic allowed to and from the instances in the subnets in question

Policies

Peering between two VCNs requires explicit agreement from both parties in the form of IAM policies that each party implements for their own VCN's compartment or tenancy. If the VCNs are in different tenancies, each administrator must provide their tenancy OCID and put in place special coordinated policy statements to enable the peering.

To implement the IAM policies required for peering, the two VCN administrators must designate one administrator as the requestor and the other as the acceptor. The requestor must be the one to initiate the request to connect the two LPGs. In turn, the acceptor must create a particular IAM policy that gives the requestor permission to connect to LPGs in the acceptor's compartment. Without that policy, the requestor's request to connect fails. Either VCN administrator can terminate a peering connection by deleting their LPG.

Routing and Traffic Control

As part of configuring the VCNs, each administrator must update the VCN's routing to enable traffic to flow between the VCNs. In practice, this looks just like routing you set up for any gateway, such as an internet gateway or dynamic routing gateway. For each subnet that needs to communicate with the other VCN, you update the subnet's route table. The route rule specifies the destination traffic's CIDR and your LPG as the target. Your LPG routes traffic that matches that rule to the other LPG, which in turn routes the traffic to the next hop in the other VCN.

You can control packet flow over the peering 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 does not stop traffic flowing over the peering connection, but stops it at the VNIC level.

Security Rules

Each VCN administrator must ensure that all outbound and inbound traffic with the other VCN is intended, 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. If your subnets use the default security list, there are two rules allowing SSH and ICMP ingress traffic from anywhere, thus also the other VCN. Evaluate these rules and whether you want to keep or update them.

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 do not apply to your own VCN's CIDR, but inadvertently apply to the other VCN's CIDR.

Service Gateway

Certain services, such as the object storage service, are exposed internally over a conceptual Services Network. Normally, these services would use public IP addresses that can be reached over a public network – or in a public cloud model, over the internet. Instead, the purpose of a service gateway is to enable a VCN to privately access the services in the Services Network, meaning resources in a private subnet, within a tightened down VCN with no external access, can still connect to those services.

A VCN can have only one service gateway. You create a service gateway in the context of a specific VCN, so the gateway is automatically attached to that VCN upon creation. A service gateway allows traffic to and from all subnets at the time of creation; there is no mechanism to block or disable this traffic.

In Private Cloud Appliance, these services are implemented at the infrastructure level through the management node cluster. Technically, the service endpoints, which are fully qualified domain names, are reachable from the entire on-premises network by default. which means the service gateway has no real function. Specifically for private cloud use, there is no need to configure a service gateway and associated route rules to enable private access to the service endpoints. However, in order to maintain compatibility with Oracle Cloud Infrastructure, the concept of a service gateway does exist.

The service gateway uses a service CIDR label, which is a string that represents the endpoints for the service or group of services of interest. This means that you don't have to know the specific endpoints. If the service's endpoint changes in the future, you do not need to make any adjustments. You use the service CIDR label when you configure the service gateway. With Private Cloud Appliance you are allowed to create the service gateway and configure route rules involving a "Service CIDR Block". However, remember they serve no purpose other than compatibility.

Because Private Cloud Appliance is set up within the safe boundaries of your data center network, securing private access to services is much less of a concern, compared with a public cloud environment like Oracle Cloud Infrastructure. Therefore, security rules are not implemented for service gateways. For details, see Security Rules.

Virtual Firewall

The Networking service offers two virtual firewall features that both use security rules to control traffic at the packet level. They offer different ways to apply security rules to a set of virtual network interface cards (VNICs).

Security lists:

A security list defines security rules at the subnet level, which means that all VNICs in a given subnet are subject to the same rules. Each VCN comes with a default security containing default rules for essential traffic. The default security list is automatically used with all subnets, unless a custom security list is specified. A subnet can have up to five associated security lists.
Network security groups (NSGs):

A network security group defines security rules based on membership. Its security rules apply to resources that are explicitly added to the NSG. A VNIC can be added to a maximum of five NSGs. An NSG is intended to provide a virtual firewall for a set of cloud resources with the same security posture. For example: a group of instances that perform the same tasks and thus need to use the same set of ports.

Oracle recommends using NSGs instead of security lists because NSGs let you separate the VCN's subnet architecture from your application security requirements. However, NSGs are only supported for specific services. It is possible to use both security lists and NSGs together, depending on your particular security needs.

If you have security rules that you want to enforce for all VNICs in a VCN, the easiest solution is to put the rules in one security list, and then associate that security list with all subnets in the VCN. This way you can ensure that the rules are applied, regardless of who in your organization creates a VNIC in the VCN. Alternatively, you can add the required security rules to the VCN's default security list.

If you choose to combine security lists and network security groups, the set of rules that applies to a given VNIC is the union of these items:

The security rules in the security lists associated with the VNIC's subnet
The security rules in all NSGs that the VNIC is in

A packet in question is allowed if any rule in any of the relevant lists and groups allows the traffic, or if the traffic is part of an existing connection being tracked because of a stateful rule.

Security Rules

This section explains important aspects of security rules that you need to understand in order to implement them as part of security lists or network security groups. How you create, manage, and apply security rules varies between security lists and network security groups. Related sections provide more detailed information about each implementation.

Parts of a Security Rule

A security rule allows a particular type of traffic into or out of a VNIC. For example, a commonly used security rule allows ingress TCP port 22 traffic for establishing SSH connections to the instance. Without security rules, no traffic is allowed into and out of VNICs in the VCN.

Each security rule specifies the following items:

Direction (ingress or egress): Ingress is inbound traffic to the VNIC; egress is outbound traffic from the VNIC.

The REST API model for security lists is different from network security groups. With security lists, there is an IngressSecurityRule object and a separate EgressSecurityRule object. With network security groups, there is only a SecurityRule object, and the object's direction attribute determines whether the rule is for ingress or egress traffic.
Stateful or stateless: If stateful, connection tracking is used for traffic matching the rule. If stateless, no connection tracking is used. See Stateful and Stateless Rules in this section.

Source type and source: For ingress rules only; the source you provide depends on the source type you choose. These source types are allowed:

Source Type	Allowed Source
CIDR	The CIDR block where the traffic originates from. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required. For example, include the /32 if specifying an individual IP address.

Destination type and destination: For egress rules only; the destination you provide depends on the destination type you choose. These destination types are allowed:

Destination Type	Allowed Destination
CIDR	The CIDR block that the traffic is destined for. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required. For example, include the /32 if specifying an individual IP address.

IP Protocol: Either a single IPv4 protocol or "all" to cover all protocols.
Source port: The port where the traffic originates from. For TCP or UDP, you can specify all source ports, or optionally specify a single source port number, or a range.
Destination port: The port where the traffic is destined to. For TCP or UDP, you can specify all destination ports, or optionally specify a single destination port number, or a range.
ICMP type and code: For ICMP, you can specify all types and codes, or optionally specify a single type with an optional code. If the type has multiple codes, create a separate rule for each code you want to allow.
Description: NSG security rules contain an optional attribute to include a description of the rule. This is currently not supported for security list rules.

Stateful and Stateless Rules

When you create a security rule, you choose whether it is stateful or stateless. The default is stateful. Stateless rules are recommended if you have a high-volume internet-facing website, for the HTTP/HTTPS traffic.

Marking a security rule as stateful indicates that you want to use connection tracking for any traffic that matches that rule. This means that when an instance receives traffic matching the stateful ingress rule, the response is tracked and automatically allowed back to the originating host, regardless of any egress rules applicable to the instance. And when an instance sends traffic that matches a stateful egress rule, the incoming response is automatically allowed, regardless of any ingress rules.

Marking a security rule as stateless indicates that you do NOT want to use connection tracking for any traffic that matches that rule. This means that response traffic is not automatically allowed. To allow the response traffic for a stateless ingress rule, you must create a corresponding stateless egress rule.

If you use both stateful and stateless rules, and there is traffic that matches both a stateful and stateless rule in a particular direction, the stateless rule takes precedence and the connection is not tracked. You would need a corresponding rule in the other direction, either stateless or stateful, for the response traffic to be allowed.

If you decide to use stateless security rules to allow traffic to/from endpoints outside the VCN, it is important to add a security rule that allows ingress ICMP traffic type 3 code 4 from source 0.0.0.0/0 and any source port. This rule enables your instances to receive Path MTU Discovery fragmentation messages. This rule is critical for establishing a connection to your instances. Without it, you can experience connectivity issues.

Best Practices for Security Rules

Use network security groups

Oracle recommends using NSGs for components that all have the same security posture. For example, in a multi-tier architecture, you would have a separate NSG for each tier. A given tier's VNICs would all belong to that tier's NSG.

Within a given tier, you might have a particular subset of the tier's VNICs that have additional, special security requirements. Therefore you would create another NSG for those additional rules, and place that subset of VNICs into both the tier's NSG and the NSG with additional rules.
Understand default security list rules

Each VCN automatically comes with a default security list that contains several default security rules to help you get started using the Networking service. Those rules exist because they enable basic connectivity.

Even if you choose not to use security lists or the default security list, get familiar with the rules so you better understand the types of traffic that your networked cloud resources require. You might want to use those rules in your NSGs or any custom security lists that you set up.

There is no default rule to allow ping requests. If you want to ping an instance, add a stateful ingress rule to specifically allow ICMP traffic type 8 from the source network you plan to ping from. To allow ping access from the internet, use 0.0.0.0/0 for the source. Note that this rule for pinging is separate from the default ICMP-related rules in the default security list. Do not remove those rules.
Do not delete default security rules indiscriminately

Your VCN might have subnets that use the default security list by default. Do not delete any of the list's default security rules unless you have first confirmed that resources in your VCN do not require them. Otherwise, you might disrupt your VCN's connectivity.
If necessary, add rules to allow ping requests

There is no default rule to allow ping requests. If you want to ping an instance, add a stateful ingress rule to specifically allow ICMP traffic type 8 from the source network you plan to ping from. To allow ping access from the internet, use 0.0.0.0/0 for the source. Note that this rule for pinging is separate from the default ICMP-related rules in the default security list. Do not remove those rules.
If necessary, add rules to handle fragmented UDP packets

Instances can send or receive UDP traffic. If a UDP packet is too large for the connection, it is fragmented. However, only the first fragment from the packet contains the protocol and port information. If the security rules that allow this ingress or egress traffic specify a particular (source or destination) port number, the fragments after the first one are dropped. If you expect your instances to send or receive large UDP packets, set both the source and destination ports for the applicable security rules to ALL instead of a particular port number.
Align OS firewall rules with security rules

Your instances running images provided with Private Cloud Appliance also have OS firewall rules that control access to the instance. When troubleshooting access to an instance, make sure 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

Security Lists

A security list acts as a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out. Each security list is enforced at the VNIC level. However, you configure your security lists at the subnet level, which means that all VNICs in a given subnet are subject to the same set of security lists. The security lists apply to a given VNIC whether it is communicating with another instance in the VCN or a host outside the VCN. Each subnet can have multiple security lists associated with it, and each list can have multiple rules.

Each VCN comes with a default security list. If you do not specify a custom security list for a subnet, the default security list is automatically used with that subnet. You can add and remove rules in the default security list. It has an initial set of stateful rules, which should in most cases be changed to only allow inbound traffic from authorized subnets. The default rules are:

Stateful ingress: Allow TCP traffic on destination port 22 (SSH) from authorized source IP addresses and any source port.

This rule makes it easy for you to create a new cloud network and public subnet, launch a Linux instance, and then immediately use SSH to connect to that instance without needing to write any security list rules yourself.

The default security list does not include a rule to allow Remote Desktop Protocol (RDP) access. If you are using Microsoft 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.
Stateful ingress: Allow ICMP traffic type 3 code 4 from authorized source IP addresses.

This rule enables your instances to receive Path MTU Discovery fragmentation messages.
Stateful ingress: Allow ICMP traffic type 3 (all codes) from your VCN's CIDR block.

This rule makes it easy for your instances to receive connectivity error messages from other instances within the VCN.
Stateful egress: Allow all traffic.

This allows instances to initiate traffic of any kind to any destination. This implies that instances with public IP addresses can talk to any internet IP address if the VCN has a configured internet gateway. And because stateful security rules use connection tracking, the response traffic is automatically allowed regardless of any ingress rules.

The general process for working with security lists is as follows:

Create a security list.
Add security rules to the security list.
Associate the security list with one or more subnets.
Create resources, such as compute instances, in the subnet.

The security rules apply to all the VNICs in that subnet.

When you create a subnet, you must associate at least one security list with it. It can be either the VCN's default security list or one or more other security lists that you already created. You can change which security lists the subnet uses at any time. You can add and remove rules in the security list. It is possible for a security list to contain no rules.

Network Security Groups

A network security group (NSG) provides a virtual firewall for a set of cloud resources, within a single VCN, that all have the same security posture. For example: a group of compute instances that all perform the same tasks and thus all need to use the same set of ports.

Rules in an NSG are enforced on VNICs, but their NSG membership is determined through their parent resources. Not all cloud services support NSGs. Currently, the following types of parent resources support the use of NSGs:

Compute instances: When you create an instance, you can specify one or more NSGs for the instance's primary VNIC. If you add a secondary VNIC to an instance, you can specify one or more NSGs for that VNIC. You can also change the NSG membership of existing VNICs.
Mount targets: When you create a mount target for a file system, you can specify one or more NSGs. You can also update an existing mount target to use one or more NSGs.

For resource types that do not yet support NSGs, continue to use security lists to control traffic to and from those parent resources.

An NSG contains two types of elements:

VNICs: One or more VNICs; for example, the VNICs attached to the set of compute instances that all have the same security posture. All the VNICs must be in the VCN that the NSG belongs to. A VNIC can be in a maximum of five NSGs.
Security rules: Rules that define the types of traffic allowed into and out of the VNICs in the group. For example: ingress TCP port 22 SSH traffic from a particular source.

The general process for working with NSGs is as follows:

Create an NSG.

When you create an NSG, it is initially empty, without any security rules or VNICs. After the NSG is created, you can add or remove security rules to allow the types of ingress and egress traffic that the VNICs in the group require.
Add security rules to the NSG.
Add parent resources, or more specifically VNICs, to the NSG.

When you manage an NSG's VNIC membership, you do it as part of working with the parent resource, not the NSG itself. You can do this when you create the parent resource, or you can update the parent resource and add it to one or more NSGs.

When you create a compute instance and add it to an NSG, the instance's primary VNIC is added to the NSG. You can create secondary VNICs separately, and optionally add them to NSGs.

There are some differences in the REST API model for NSGs compared to security lists:

With security lists, there is an IngressSecurityRule object and a separate EgressSecurityRule object. With network security groups, there is only a SecurityRule object, and the object's direction attribute determines whether the rule is for ingress or egress traffic.
With security lists, the rules are part of the SecurityList object, and you work with the rules by calling the security list operations; for example: UpdateSecurityList. With NSGs, the rules are not part of the NetworkSecurityGroup object. Instead you use separate operations to work with the rules for a given NSG; for example: UpdateNetworkSecurityGroupSecurityRules.
The model for updating existing security rules is different between security lists and NSGs. With NSGs, each rule in a given group has a unique identifier. When you call UpdateNetworkSecurityGroupSecurityRules, you provide the IDs of the specific rules that you want to update. With security lists, the rules have no unique identifier. When you call UpdateSecurityList, you must pass in the entire list of rules, including rules that are not being updated in the call.
There is a limit of 25 rules when calling the operations to add, remove, or update security rules.

Network Security

This section provides information about controlling access and security in your cloud network. The firewall functionality inside a VCN is described in detail in Virtual Firewall. Additional topics about secure network access are discussed here.

Ways to Secure Your Network

There are several mechanisms to control security for your cloud network and compute instances:

Private subnets: If instances do not require a public IP address, you can designate a subnet to be private, to prevent instances from obtaining a private IP.
Firewall rules: To control packet-level traffic into and out of an instance, you can configure firewall rules directly on the instance itself. Images provided with Private Cloud Appliance that run Oracle Linux automatically include default rules that allow ingress on TCP port 22 for SSH traffic. Also, Microsoft Windows images may include default rules that allow ingress on TCP port 3389 for Remote Desktop access.
Gateways and route tables: To control general traffic flow from your cloud network to outside destinations – the internet, your on-premises network, or another VCN – you configure your cloud network's gateways and route tables to allow only the connectivity that is effectively required.
IAM policies: You can control who has access to the Private Cloud Appliance interfaces. You can control which cloud resources can be accessed and which type of access is allowed. For example, you can control who can set up your network and subnets, or who can update route tables, network security groups, or security lists.

Access Control

This topic provides basic information about using compartments and IAM policies to control access to your cloud network.

Using Compartments with Network Resources

Whenever you create a cloud resource such as a virtual cloud network (VCN) or compute instance, you must specify which IAM compartment you want the resource to be in. A compartment is a collection of related resources that can only be accessed by certain groups that have been given permission by an administrator in the tenancy. The administrator creates compartments and corresponding IAM policies to control which users in your organization access which compartments. Ultimately, the goal is to ensure that users can only access the resources they need.

In an enterprise production environment, you typically divide the tenancy into multiple compartments to more easily control access to certain types of resources. For example, your administrator could create Compartment_A for your VCN and other networking components. The administrator could then create Compartment_B for all the compute instances and block storage volumes that the HR department uses, and Compartment_C for all the instances and block storage volumes that the Marketing department uses.

The administrator would then create IAM policies that give users only the level of access they need in each compartment. For example, HR instance administrators are not entitled to modify the existing cloud network. So they would have full permissions for Compartment_B, but limited access to Compartment_A: only what is required to launch instances into the network. If they try to modify other resources in Compartment_A, the request is denied.

Network resources such as VCNs, subnets, route tables, security lists, service gateways, and NAT gateways can be moved from one compartment to another. When you move a resource to a new compartment, inherent policies apply immediately.

Detailed information about the use of compartments, and how to control access to your cloud resources, is provided in the chapter Identity and Access Management Overview. More specifically, refer to Organizing Resources in Compartments and How Policies Work.

Using IAM Policies for Networking

A convenient and common approach to granting access to Networking is to grant permission to a Network Administrators group to manage the VCN and all related networking components: subnets, security lists, route tables, gateways, and so on. It is useful to also allow the Network Administrators to launch instances in order to test network connectivity. Both policies – to manage network resources and to launch instances – are covered in Common Policies. The required policy statements should look similar to this example:

Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group NetworkAdmins to manage instance-family in compartment ABC
Allow group NetworkAdmins to use volume-family in compartment ABC

If you are not yet familiar with IAM policies, refer to How Policies Work in the chapter Identity and Access Management Overview.

If you prefer a finer-grained approach to access control, you can write policies that focus on individual resource types. For example, the virtual-network-family resource type includes individual resource types such as subnets, route-tables, security-lists or local-peering-gateways. You can grant specific access to these by writing separate policies per resource type.

In addition, you can write policies that limit the level of access by using a different policy verb; for example: manage versus use, and so on. If you do, there are some nuances to understand about the policy verbs for Networking.

Be aware that the inspect verb not only returns general information about the network components; for example, the name and OCID of a security list or route table. It also includes the contents of the component; for example, the actual rules in the security list, the routes in the route table, and so on.

Also, the following operations are available only with the manage verb, not the use verb:

Update (enable/disable) internet-gateways
Update security-lists
Update route-tables
Update dhcp-options
Attach a DRG to a VCN
Peer two VCNs

Each VCN has various components that directly affect the behavior of the network: route tables, security lists, DHCP options, internet gateway, and so on. When you create one of these components, you establish a relationship between that component and the VCN, which means you must be allowed in a policy to both create the component and manage the VCN itself. However, the ability to update that component – to change the route rules, security list rules, and so on – does NOT require permission to manage the VCN itself, even though changing that component can directly affect the behavior of the network. This discrepancy is designed to give you flexibility in granting least privilege to users, and not require you to grant excessive access to the VCN just so the user can manage other components of the network. Be aware that by giving someone the ability to update a particular type of component, you are implicitly trusting them with controlling the network's behavior.

Networking Scenarios

This section describes a number of basic networking scenarios to help you understand the networking service and how networking components operate together.

Public Subnet

This section describes a setup consisting of a VCN and a public subnet. For external connectivity the VCN needs an internet gateway. Your on-premises network also uses this gateway to communicate with resources inside the VCN. The IP addresses used in this scenario must be public. In a private cloud context, this means a unique address directly reachable from the on-premises network.

The subnet uses the default security list, which has default rules that are designed to make it easy to get started. The rules enable typical required access; for example inbound SSH connections and any type of outbound connections. Remember that security list rules only allow traffic. Any traffic not explicitly covered by a security list rule is implicitly denied. In this scenario, you add additional rules to the default security list. You could instead create a custom security list for those rules. You would then set up the subnet to use both the default security list and the custom security list.

The subnet uses the default route table, which contains no rules when the VCN is created. In this scenario, the table has only a single rule: to route traffic intended for all destinations (0.0.0.0/0) through the internet gateway.

To set up this networking scenario, you perform the following steps:

Create the VCN.

Choose a compartment you have permission to work in. Specify one or more non-overlapping CIDR blocks for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.
Create the public subnet.

Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Select the default route table. Make sure the subnet is a public subnet, so that instances can obtain public IP addresses. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.
Create the internet gateway.

When you create the internet gateway, it is enabled immediately. However, you must add a route rule to allow traffic to flow to the gateway.
Update the default route table to use the internet gateway.

The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add a rule that routes all traffic destined for addresses outside the VCN to the internet gateway. Enter these parameters:
- Target Type: Internet Gateway
- Destination CIDR block: 0.0.0.0/0
  
  This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
- Target: The internet gateway you created.
Because the subnet was set up to use the default route table, the resources in the subnet can now use the internet gateway. The existence of this rule also enables inbound connections to the subnet, through the internet gateway. The next step is to specify the types of traffic you want to allow into and out of the instances you later create in the subnet.
Update the default security list.

You set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

For example, if the instances in your subnet are web servers, they likely need to receive inbound HTTPS connections. To enable that traffic, add an ingress rule to the default security list using these parameters:
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 443
Create instances.

Your next step is to create one or more instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, you must give each instance a public IP address, otherwise you cannot access them through the internet gateway.

Private Subnet

This section describes a setup consisting of a VCN and a private subnet. For connectivity to your on-premises network, the VCN needs a dynamic routing gateway (DRG).

To set up this networking scenario, you perform the following steps:

Create the VCN.

Choose a compartment you have permission to work in. Specify one or more non-overlapping CIDR blocks for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.
Create the private subnet.

Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Make the subnet private; the instances you create cannot obtain a public IP address. Select the default route table. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.
Update the default security list.

You set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

For example, if your subnet contains Microsoft Windows instances and you intend to access them using RDP, add an ingress rule to the default security list using these parameters:
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 3389
Create a dynamic routing gateway (DRG) and attach it to your VCN.

When you create the DRG, it is in "Provisioning" state for a short period. Make sure provisioning is done before continuing. Next, attach the DRG you just created to your VCN. For this scenario you can ignore the advanced attachment options. The DRG attachment will be in "Attaching" state for a short period before it is ready.

To allow traffic to flow to the DRG, you must add a route rule.
Update the default route table to use the DRG.

The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add a rule that routes all traffic destined for addresses in your on-premises network to the DRG. Enter these parameters:
- Target Type: Dynamic Routing Gateway.
  
  The VCN's attached DRG is automatically selected as the target.
- Destination CIDR block: 0.0.0.0/0
  
  This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
Because the subnet was set up to use the default route table, the DRG now enables traffic between the resources in the subnet and in your on-premises network.
Create instances.

Your next step is to create one or more instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, no additional configuration is required in order to access the instances from your on-premises network.

Public and Private Subnets

This section describes a simple multi-tier setup consisting of a VCN with a public and a private subnet. The public subnet holds public instances such as web servers, and the private subnet holds private instances such as database servers. The VCN has a dynamic routing gateway (DRG) for connectivity to your on-premises network. Instances in the public subnet have external access through an internet gateway.

Note:

In a public cloud environment, instances in the private subnet could be allowed to initiate external connections using a NAT gateway, for example to get software updates. However, in Private Cloud Appliance the NAT gateway would provide access to the on-premises network, which the DRG already enables for those instances. The combination of a NAT gateway and DRG could cause issues due to non-deterministic routing.

Each subnet uses the default security list, which has default rules that are designed to make it easy to get started. The rules enable typical required access; for example inbound SSH connections and any type of outbound connections. Remember that security list rules only allow traffic. Any traffic not explicitly covered by a security list rule is implicitly denied.

Each subnet also has its own custom security list and custom route table with rules specific to the needs of the subnet's instances. In this scenario, the VCN's default route table, which is always empty to start with, is not used.

To set up this networking scenario, you perform the following steps:

Create the VCN.

Choose a compartment you have permission to work in. Specify one or more non-overlapping CIDR blocks for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.
Add the necessary gateways to the VCN.

The instances in the public subnet need an internet gateway for incoming and outgoing public traffic. The instances in the private subnet need a NAT gateway to be able to reach the data center network and the internet. These gateways are enabled immediately upon creation, but you must add route rules to allow traffic to flow to them.

To be able to reach the private instances in the VCN from your on-premises network, you create a DRG and attach it to the VCN. When you create the DRG, it is in "Provisioning" state for a short period. Make sure provisioning is done before attaching it to the VCN. For this scenario you can ignore the advanced attachment options. The DRG attachment will be in "Attaching" state for a short period before it is ready. To allow traffic to flow to the DRG, you must also add a route rule.
Create custom route tables for the subnets you will create later.
1. For the public subnet, create a route table and add a rule that routes all traffic destined for addresses outside the VCN to the internet gateway. Enter these parameters:
  - Target Type: Internet Gateway
  - Destination CIDR block: 0.0.0.0/0
    
    This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
  - Target: The internet gateway you created.
2. For the private subnet, create a route table and add two rules: one that routes traffic destined for the on-premises network to the DRG, and one that routes all other traffic leaving the VCN to the NAT gateway.
  
  Create the route rule for the NAT gateway with these parameters:
  - Target Type: NAT Gateway
  - Destination CIDR block: 0.0.0.0/0
    
    This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
  - Target: The NAT gateway you created.
  Create the route rule for the DRG with these parameters:
  - Target Type: Dynamic Routing Gateway.
    
    The VCN's attached DRG is automatically selected as the target.
  - Destination CIDR block: 10.25.0.0/16
    
    This means that traffic intended for an address in the on-premises network (10.25.x.y) goes to the DRG target specified in this rule.
Update the default security list.

Add security list rules that allow the types of connections that the instances in the VCN will need.

Edit each of the existing stateful ingress rules so that the Source CIDR is not 0.0.0.0/0, but the CIDR for your on-premises network; in this example: 10.25.0.0/16.
Create custom security lists for the subnets you will create later.
1. Create a custom security list for the public subnet and add rules to allow the types of connections that the public instances will need. For example, web servers likely need to receive HTTP and HTTPS ingress traffic. For HTTP, use the settings below. For HTTPS, add another similar rule for TCP port 443.
  - Source Type: CIDR
  - Source CIDR: 0.0.0.0/0
  - IP Protocol: TCP
  - Source Port Range: All
  - Destination Port Range: 80
2. Create a custom security list for the private subnet and add rules to allow the types of connections that the private instances will need. For example, database servers likely need to receive SQL*Net (TCP port 1521) ingress traffic from clients in the private and the public subnet. For clients in the public subnet, use the settings below. For clients in the private subnet, add another similar rule for the CIDR of the private subnet (172.16.1.0/24).
  - Source Type: CIDR
  - Source CIDR: 172.16.2.0/24
  - IP Protocol: TCP
  - Source Port Range: All
  - Destination Port Range: 1521
Create the subnets in the VCN.
- Public subnet:
  
  Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.2.0/24. Make sure the subnet is a public subnet, so that instances can obtain public IP addresses. Select the custom public subnet route table you created earlier.
  
  Select two security lists: both the default security list and the public subnet security list you created earlier. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.
- Private subnet:
  
  Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.1.0/24. Make the subnet private; the instances you create in this subnet cannot obtain a public IP address. Select the custom private subnet route table you created earlier.
  
  Select two security lists: both the default security list and the private subnet security list you created earlier. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.
Create instances.

Your next step is to create instances in the subnets. Each instance automatically gets a private IP address. For each instance in the public subnet, make sure to assign the instance a public IP address. Otherwise, you won't be able to reach the instance from your on-premises network. The DRG you set up allows you to reach the instances in the private subnet from your on-premises network without any additional configuration.