Baseline network in OCI: VCN, subnets, gateways and traffic control

The initial network of an Oracle Cloud Infrastructure (OCI) tenancy tends to become the foundation for the applications, databases and integrations that arrive later. If its subnets and rules are created only so that the first machine responds, later workloads inherit access that nobody explicitly approved.

This article proposes designing that network from the flows the business needs: which component receives public traffic, which one calls external services and which one accesses internal data. With that map, every decision about the VCN, gateways and security rules has a verifiable justification. A validation procedure closes the article.

Addressing and ownership

A Virtual Cloud Network (VCN) is a configurable private network within an OCI region. Its subnets organize resources and use address ranges expressed in CIDR notation. The VCN and subnets guide describes these relationships and the scope of each subnet.

Before assigning a range, it should be compared with the networks of offices, data centers and other clouds that may be connected later. Overlapping ranges complicate private routing and are expensive to correct. Reserving room to grow is reasonable; granting communication permissions in anticipation is not.

The network also needs owners: who manages routes, who approves an application's access and who handles connectivity incidents. A naming convention (for example, production-application-private) helps if the team shares it, but it must be backed by an inventory of owners. An old rule should not depend on finding whoever created it.

A small, documented initial layout is enough: one zone for public ingress and another for internal components, with environments separated according to their isolation needs. The network design should be coordinated with compartments and IAM policies, because changing a route requires management permissions, not only technical knowledge.

Public and private subnets

A private subnet prevents its resources from having public IP addresses; a public subnet allows it. Belonging to a public subnet is not enough, however, for a server to be reachable from the internet: it needs the right address, a valid route and rules that allow the traffic, as the Internet Gateway documentation explains.

In a web application, the public entry point can sit in one subnet and the internal servers in a private one. The path to the database should follow how the application works; direct access from the internet for operational convenience has no justification. This layout is a reference to be adjusted to each service.

Administrative access is designed separately from user access. It should be documented from which authorized network machines are administered and which mechanism is used to reach private resources. An occasional support need does not justify permanently opening administration ports to any source.

One gateway per destination type

Each gateway serves a different destination. The Internet Gateway connects the VCN to the internet when the rest of the configuration allows it. The NAT Gateway lets resources without public IPs initiate outbound connections and receive the responses, without accepting connections initiated from outside; its conditions are in the NAT Gateway guide.

The Service Gateway provides private access to supported Oracle services within the Oracle Services Network. It is not a general internet exit: its routes use specific service destinations. Regional availability and covered services are listed in Access to Oracle Services: Service Gateway.

To connect corporate networks, a Dynamic Routing Gateway (DRG) is evaluated together with the appropriate connection. Oracle documents its use with Site-to-Site VPN tunnels, FastConnect virtual circuits and network-to-network connections. According to the DRG guide, creating the gateway does not establish the path by itself: attachments and their route tables are also required.

As a criterion, gateways are created from the list of destinations, not in advance. A server that downloads packages from public repositories goes out through NAT; one that accesses a supported Oracle service, through the Service Gateway; one that calls a private corporate system, through the DRG, with its return routes documented.

Routes and rules: two independent controls

A route defines where a packet travels toward a destination; a security rule defines which traffic may pass. They are independent controls. Adding a port rule does not fix a missing gateway, and adding a route does not grant access to an application.

The recommended tool is a flow table with source, destination, protocol, port and service owner. For each row, the route table involved and the security control that authorizes the communication are identified, including the return path when traffic crosses networks managed by another team.

Two examples of dependencies. A private subnet with internet egress needs a route to the NAT Gateway and egress permissions consistent with its use. Access to Oracle services requires the service destination and the selected gateway to match. DNS adds to both: a correct route is useless if the name resolves to an endpoint other than the intended one.

During troubleshooting, one component should be changed at a time, in this order: resolved destination, path, then network and operating-system permissions. This preserves evidence of which change fixed the fault and avoids accumulating rules whose necessity nobody can explain.

Network security groups by function

Security lists apply their rules to the interfaces of every resource in a subnet. Network Security Groups (NSGs) group interfaces that share security requirements, even when they do not coincide with the whole subnet, as the network security groups guide describes.

Organizing by function (web ingress, application, database) is a good starting point. When the service supports it, a rule can use another NSG in the same VCN as its source or destination, so the policy expresses a relationship between functions rather than a list of individual addresses to maintain.

Permissions from security lists and NSGs combine: a restrictive NSG does not cancel a broad allowance in the subnet's list. Explaining why a packet passes requires reviewing both. The security rules documentation details this evaluation and the difference between stateful and stateless rules.

With stateful rules, OCI tracks the connection and allows the corresponding responses; with stateless rules, permissions must be defined in both directions. Mixing both types on the same traffic requires prior analysis. The operating-system firewall is a third layer that can block a connection OCI already allowed. If the endpoint uses Zero Trust Packet Routing (ZPR) attributes, its policies are an additional condition on top of NSGs and security lists.

Validating the approved flows

Before handing the network to application teams, each path is tested from the component that will actually initiate the call. A test from a workstation validates a different source and can give false confirmation. Negative tests (access that must be denied) matter as much as positive ones.

• CIDR ranges do not overlap with the networks that will be connected.
• Every resource with a public IP has a recorded justification.
• Every destination is associated with its gateway and route table.
• The effective permissions of security lists and NSGs are reviewed together.
• DNS and the operating-system firewall are validated from the real source.
• Accepted tests and the owner of future changes are recorded.

Xterra Engine designs and validates baseline OCI networks from the flow inventory, before the first workloads arrive.