OCI Logging – Auditing VCN Security list changes

In this article, we discuss a common governance requirement: auditing changes to a VCN Security List. VCN security list has set of firewall rules, but it doesn’t list information about when a rule has added/modified/removed. But this information will be very much required when we work on finding route cause of security related issues. It’s highly possible that security list changes would have created violations and we need to identify who changed what, when, and from where. 

Lets explore how OCI Audit helps to get the details. Choose a Security list and perform changes in the security list rules.

 

Add a Ingress security rule to the security list.

Add Ingress rule

Also add a egress rule to the security list.

Egress rule has been added.

We have added an Ingress and egress rule. Now our task is to identify when the ingress/egress rule has been changed and what changes have been done.

We can find the details at Observability Management -> Logging -> Audit. OCI Audit records control-plane events - meaning actions performed through the OCI Console, OCI CLI, SDK, Terraform, or APIs that create, update, or delete OCI resources.

In the Audit page, first select the compartment where you want to review activity. Audit entries record control-plane events, such as creating, updating, or deleting OCI resources.

The most important filter on this page is the Time range. By default, the console shows events from the last 5 minutes. When you open the Audit page, it loads all audit events that occurred within that default time window.

Other filters—such as User, Resource, Request action, and related fields will be populated based on the events retrieved for the selected compartment and time range. If you expand the time window (for example, last 1 hour or last 24 hours), you will see more events and more filter values available.

Another important filter is Event type. All audit events have event type. Choosing right event type will help us to reach the event that we look for. In this exercise, we target the security list changes. Event type having security list change is “com.oraclecloud.virtualNetwork.UpdateSecurityList”.

In case if we are not seeing this event type, then we may need to increase the Filter by time.

Once the event type is chosen, we could see the related events. In our case Ingress and Egress change have happened at different time, hence it has created two different Audit events.

Click the arrow button located in the right corner, that will expand the event.

The event contains many details. To identify what changed in the Security List, locate the stateChange section. It contains two parts:

• current: the Security List state after the change
• previous: the Security List state before the change

Comparing these two sections reveals exactly what was modified.

The current denotes the current status of security list and previous denotes the state of security list before change. Comparing both will give the details of the change.

Under the current we can find egressSecurityRules and ingressSecurityRules which has details of security rules.

Click the egressSecurityRules

Collect egressSecurityRules from previous section.

We could the difference is “2” which is present only in current version. It means a rule has been added by the update.

Checking ingressSecurityRules, we could see it has same number of rules for current and previous section, which means only egress rule got changed at this time.

Along with the actual changes, we can fine some additional details.

Timecreated -> the time the change has happened.
CompartmentId -> compartment of security list
VcnID -> OCID of VCN
id -> OCID of security list.

In summary, OCI Audit logs provide a reliable way to track and prove changes made to VCN Security Lists, something the Security List UI alone does not capture. 

  OCI Logging – Enable Flow logging for VCN

Oracle Cloud Infrastructure (OCI) provides built-in observability features to help you monitor cloud activity. For networking, VCN Flow Logs capture traffic flow metadata (source/destination IP, ports, protocol, direction, bytes/packets, and accept/reject status). This is very useful for troubleshooting connectivity, validating security posture, and supporting audits or penetration testing evidence.

In this article, we will enable Flow Logs at the subnet level and control the captured traffic using a Capture Filter.

To enable Logging to VCN, go to Network -> VCN -> Subnets page.

Click Monitoring tab and in the Monitoring page, we could see Logs section.

 We need to enable Flow Logs. Click the three dots located in the right side and click Enable Log option.

Specify compartment, Log location, Log group and Log name.

We ned to specify Capture filter, it’s a required parameter to enable log. We need to specify OCID of desired Capture filter.

The network activities will create huge amount of logs, OCI provides option to mention which traffic needs to be included or excluded from flow logs. The Capture Filter can be created in the Networking -> Network Command center -> Capture Filters.

Specify name, compartment for Capture filter. It can be created for either Flow log capture filter and VTAP. For our activity we need capture filter for Flow log. Sampling rate defines the percentage of network flows to be examined, we can specify one of the predefined percentage (1%,5%,10%,20%,25%,50%,100%).

The next section is defining rules which needs to included or excluded from flow logs. We can define upto 10 rules in a capture filter and it will follow the order to examine. If first rule is met then it will stop executing other rules, so we need to be careful with the rules.

The rules can also defined later in the capture filter. Suppose we are not sure about the traffic to be excluded/included, then we can leave with Traffic disposition as All (Accept and Reject) and Include/Exclude as Include, in that way we are making to include all the traffic without any condition.

Once the capture filter is created, copy the OCID of that.

Paste the OCID in the Subnet’s Enable resource log page that we discussed earlier.

It also gives option to specify retention period of captured logs. Its available in the Advanced option.

The default and minimum Log retention is 1 month and Maximum is 6 months.

 Click the Log name and in the Log details page, choose Explore log. We could see all the flow traffic captured in the log.

 

 IPv6 Connectivity Across OCI VCNs via Dynamic Routing Gateway

In the past articles, we discussed the IPv6 address format and how the communication can happen via Internet Gateway. In this article, we will explore how IPv6 communication can be set up via Dynamic Routing Gateway (DRG).

IPv6 address includes a VCN-specific identifier, which ensures global uniqueness. Because of this uniqueness, interconnectivity between networks is possible even when their IPv4 CIDR ranges overlap. If the VCN, Subnets and Compute instances are enabled with IPv6 then please move to DRG section.

First, we create two VCNs with the same IPv4 CIDR range. Next, we enable IPv6 CIDR ranges for both VCNs to allow seamless communication over IPv6. In this exercise VCNs are created in the same region.

The VCN has only IPv4 CIDR Range.

Lets enable IPv6 CIDR range to the VCN.

After enable, we could see IPv6 CIDR range now.

Right now, only VCN got enabled with IPv6 and we need to enable IPv6 CIDR range at Subnet level.

In the Subnet -> IP Administration page, add IPv6 prefix.

Perform the above steps for Second VCN and subnets within the second vcn.

At this stage VCNs and Subnets are configured with IPv6. Lets test the communication among them by creating VM compute instance in each VCN and try to communicate through IPv6.

After instance creation, we can check their IPv4 and IPv6 address.

 

Dynamic Routing Gateway

Create a Dynamic Routing Gateway (DRG) in the OCI console.

Attach the VCNs into the DRG.

 

The DRG attachement has default route table. Check the route rules.

Click “Get all route rules” button. We could see IPv4 CIDR are showing conflict and IPv6 routes are clean.

 

Security rules and Route tables configuration

At the network side, we need to enable rules to allow communication among them. Add Security list and Route rule to allow communication between the instances. Specify IPv6 CIDR range of other VCN as Source CIDR (Ingress) and Destination CIDR (Egress) and use “IPv6-ICMP” protocol.

First_VCN

 

For Route rules, Specify Dynamic routing gateway as protocol with IPv6 version.

Second_VCN

Perform the security rule and Route rule configuration in Second VCN.

Test the connectivity by pinging the compute instances from each other.

 

 

Enabling IPv6 Communication Between Overlapping VCN CIDR Networks

In the previous article, we discussed the IPv6 address format and how it differs from IPv4. In this article, we will explore how IPv6 communication can be set up.

In the IPv4 model, VCN CIDR ranges must not overlap in order to establish connectivity between networks. However, in real-world environments - especially in multi-cloud architectures - CIDR overlap is a common challenge. This limitation can be effectively addressed by using IPv6 for communication.

As we know, an IPv6 address includes a VCN-specific identifier, which ensures global uniqueness. Because of this uniqueness, interconnectivity between networks is possible even when their IPv4 CIDR ranges overlap.

Let’s look at the steps in detail. First, we create two VCNs with the same IPv4 CIDR range. Next, we enable IPv6 CIDR ranges for both VCNs to allow seamless communication over IPv6.

The VCN has only IPv4 CIDR Range.

Lets enable IPv6 CIDR range to the VCN.

After enable, we could see IPv6 CIDR range now.

Right now, only VCN got enabled with IPv6 and we need to enable IPv6 CIDR range at Subnet level.

In the Subnet -> IP Administration page, add IPv6 prefix.

Perform the above steps for Second VCN and subnets within the second vcn.

At this stage VCNs and Subnets are configured with IPv6. Lets test the communication among them by creating VM compute instance in each VCN and try to communicate through IPv6.

After instance creation, we can check their IPv4 and IPv6 address.

At the network side, we need to enable rules to allow communication among them. Add Security list and Route rule to allow communication between the instances. Specify IPv6 CIDR range of other VCN as Source CIDR (Ingress) and Destination CIDR (Egress) and use “IPv6-ICMP” protocol.

First_VCN

 

In general, the communication between different VCN happens via Local peering gateway, but here IPv4 CIDR ranges are overlapping, hence we can’t use Local peering gateway, lets use Internet gateway.

Second_VCN

Perform the security rule and Route rule configuration in Second VCN.

Test the connectivity by pinging the compute instances from each other.