Troubleshooting Network Problems in OCI using VCN Flow logs

In our earlier article, we discussed how to enable VCN Flow Logs in OCI. Once the logs are enabled, the next step is to use them for troubleshooting.

This is where VCN Flow Logs become very useful.

When a connection does not work, we look for did the traffic reach the target? was it allowed? was it rejected? Which source IP and port were involved? Which destination IP and port were involved?

VCN Flow Logs help us answer these questions because they record details about traffic that has been accepted or rejected based on the security rules in the VCN. These logs are useful for auditing traffic and for troubleshooting security lists and NSGs. Each flow log record contains traffic information for a single VNIC.

Why VCN Flow Logs Help in Troubleshooting

Mostly when network connection fails, the issue can be caused by:

·        a missing ingress rule

·        a missing egress rule

·        a wrong port

·        traffic going to the wrong IP

·        an NSG or security list blocking the traffic

VCN Flow Logs help us look at actual traffic metadata. In simple terms, VCN Flow Logs give us a traffic story.

Open the Log and Use “Explore with Log Search”

Once flow logs are enabled and traffic has started flowing, we can open the log details page in OCI Logging. Click Observability & Management -> Logging -> Search.

Also, we can invoke the search from the Logs page. Choose the Log (which has been enabled for VCN/Subnet/Resource as discussed in the Enablement point in the previous article) and then click Explore log and Explore with Log search as shown in the picture.

This opens the Search page with that specific log already selected, so we can perform deeper analysis and investigation directly on the Search page.

This is one of the most useful options for troubleshooting because it takes us from a simple log view into a search and analysis view.

When we open Explore with Log Search, OCI Logging lets us do several useful things.

the Logging Search page can:

·        search logs in basic or advanced mode

·        filter by fields, text, log groups, and time range

·        visualize results

·        open each log line in raw JSON

·        export search results to JSON

 

The Logging Search page supports time-based filtering, and searches can be limited to a selected time range. OCI also notes that log searches are available only for a 14-day range.

We have VCN Flow logs enabled on a Subnet. Let’s try to connect an instance created in that subnet and then check the logs whether it has been captured and what all other options or information we can collect from logs.

We have connected to the instance. Now we could see Flow log has started capturing the events.

Let’s try Explore log search also.

The Logging Search supports both Basic mode and Advanced mode. Basic mode lets us use filters directly in the interface, while Advanced mode lets us type custom queries. The default advanced query is:

search "ocid1.tenancy.oc1..<unique_id>" | sort by datetime desc

The Log search page has list of events happened in the particular time frame. By default, it will list events seen in last 5 minutes. We can increase and also choose custom timeframe.  If we expand any event, it will list the details in JSON format.

Important Fields to Check in VCN Flow Logs

There are several fields in a VCN Flow Log record. It will be shown in JSON format. In JSON view, we can expand fields, inspect values, and copy the data.

Some of the most useful ones for troubleshooting are these:

data.action

This tells us whether the traffic was ACCEPT or REJECT. Oracle says ACCEPT means the traffic was accepted by the security lists, and REJECT means it was rejected.

data.sourceAddress

This shows the IP address of the source. This helps us confirm where the traffic came from and which host started the traffic. The source IP address is in IPv4 or IPv6 notation.

data.sourcePort

This shows the source port used by the traffic. This helps us see which source port was used.

data.destinationAddress

This shows the target IP address. The destination IP address is in IPv4 or IPv6 notation.

data.destinationPort

This shows the destination port. This is one of the most useful troubleshooting fields. It tells us which service port the traffic was trying to reach, such as:

·        22 for SSH

·        80 for HTTP

·        443 for HTTPS

·        1521 for Oracle database

data.protocolName

This shows the protocol name such as TCP. It also includes the protocol number in data.protocol.

data.packets and data.bytesOut

These fields help us understand how much traffic was recorded in the capture window.

data.status

This tells us whether the log record is normal or if data was missing. Oracle documents OK, NODATA, and SKIPDATA as possible values.

Lets take an example

·        data.action = REJECT

·        data.sourceAddress = "45.33.12.122"

·        data.destinationAddress = "10.0.0.41"

·        data.destinationPort = 111

·        data.protocolName = TCP

it usually means traffic from 45.33.12.122 to 10.0.0.41 on port 111 was blocked by network rules. It makes clear that the action field shows whether the traffic was accepted or rejected based on VCN security rules.

In the Explore Log search we can filter the search using the attributes for example data.sourceaddress or data.sourceport.

In the above screenshot, we have done the log search for specific destination ipaddress. This helps us quickly narrow the log data without typing complicated queries.

We can use filter the search events by clicking left click on the list.

Filter matching – it will list all events matching to the chosen event in the defined timeframe.

Filter not matching – it will list all events omitting the chosen event in the defined timeframe.

Example use cases: SSH connection is failing

If SSH to a private instance is not working, we can search for records where the destination port is 22. Then we can check:

• source IP
• destination IP
• action = ACCEPT or REJECT

If the action is REJECT, that points us toward NSG or security list rules.

Application port is blocked

If an application should listen on port 8080 or 443, we can filter for that destination port and see whether the traffic was accepted or rejected. The destination port and action fields are especially useful here.

 VCN Flow Logs

In OCI, communication between resources depends on the Virtual Cloud Network (VCN) configuration. Because of this, enabling network logging is important for monitoring traffic, debugging connectivity problems, and troubleshooting network issues.

In this article, we discuss the prerequisites and the enablement of VCN Flow Logs. In the next article, we will see how VCN Flow Logs can be used to troubleshoot network problems. VCN Flow Logs show network traffic details inside OCI and help us understand whether traffic was allowed or rejected. VCN Flow Logs are useful for auditing traffic and for troubleshooting security lists and NSGs.

When a connection does not work, we usually look for did information related to traffic status, source IP and Destination IP got involved in the communication. VCN Flow Logs help us answer these questions. Oracle says they record details about traffic that passes through a VCN and can help troubleshoot security lists and NSGs.

We could also consider flow logs as a Network traffic diary.

Flow logs are stored in the Logging service, so we first need a log group.

Create a Log Group

Logically a log group is like a folder that keeps related logs together.  Log group can be invoked from Observability & Management -> Logging -> Log groups.

We can create a log group by clicking “Create log group” button.

After that, the log group will be visible in OCI.

 

The next step is Create a capture fitler. Capture filter is a networking component that defines rules to selectively include or exclude specific traffic for VCN flow logs. It helps control costs and improve security monitoring by filtering traffic based on protocols, IP addresses, or ports before it is logged or mirrored.

Capture filter can be invoked from Networking -> Network command center -> Capture filters.

The capture filters support:

·        a sampling rate - Helps to control how much network traffic is captured in the flow logs.

·        include rules - Allow to capture only the traffic that matches specific conditions.

·        exclude rules - Helps ignore traffic that we do not want to capture in the flow logs.

·        filters based on CIDR, protocol, and traffic direction - Helps to narrow the captured traffic by source or destination network, type of protocol, and whether the traffic is incoming or outgoing.

 

 

Enable the Flow Log

In the OCI Console, we open Networking and then go to Network Command Center. From there, we open Flow logs.

In the Flow logs page, Click Enable Flow logs button.

Now we review the settings and enable the flow log.

The Flow creation requires a name, destination which is Log group and Filter to customize the logging and then the Enablement Points which is source for the Flow log.

The Enablement point cloud be VCN or Subnet or particular resource like targeting instances, load balancers, or network load balancers.  

VCN – It will enable flow logs to all VNIC registered with the VCN.

Subnet – It enables flow logs to VNIC which are registered with specific subnet.

Resources – We could specifically choose particular Instance, load balancer or Network load balancer.

For our exercise, lets go with subnet option. First let us choose a subnet which is not enabled with flow logging.

Now add enablement points as subnet and Enable the flow logs.

We could see the flow logs has been created for chosen subnet.

The same has been reflected in the subnet page (Subnet deails -> Monitoring)

At this stage the Subnet has been enabled with logging.  We will discuss about Troubleshooting the subnet traffic in the next article.

 OCI Events: Email Notification for Object Storage Updates

Oracle object storage is used in daily tasks like uploading backup data, archiving data, purging old data, etc. It will be very useful if we get notified about the changes happening in object storage. We can achieve this through OCI events. In this article we will go through the steps to configure OCI events for Object storage updates.

Object Storage Bucket → OCI Events Rule → OCI Notifications Topic → Email Alert

Whenever a new object is created in an OCI Object Storage bucket, OCI can generate an event, match it with an Events rule, and send an email notification through the Notifications service. OCI Events is designed to create notification based on resource state changes, and Object Storage supports emitting events for object state changes at the bucket level.

1)     Create an Object Storage Bucket

In the OCI console, open the navigation menu and move to Storage → Buckets. Select the compartment and click Create Bucket. Enter a bucket name and click Create

We will create events to capture the updates in this bucket.

---

2) Enable Event Emission for Object State Changes

For Object Storage to participate in this workflow, the bucket must emit events for object state changes. In the bucket details page, click Emit object events.

Click Enable button.

Now we could see Emit Object Events status is enabled in the console.

This allows OCI to generate an event when an object is created, updated, or deleted in the bucket.

3)  Create an OCI Notifications Topic

Next, create a topic that will receive messages from OCI Events.

In the OCI console, move to Developer Services -> Application Integration -> Notification services.

Click Topics and click Create Topic. Enter a topic name and click Create.

OCI Notifications uses topics as logical channels for publishing messages to subscribers.

4)  Add an Email Subscription

The next step is to add email as a subscriber to the topic.

Click the newly created topic and click Create Subscription.

Select protocol Email and enter email address that has to receive notification and click Create.

 

OCI will send a confirmation email to that address. The subscription remains pending until we confirm it.

5)  Confirm the Email Subscription

The email subscription will send a confirmation email to prescribed email ID. Open the confirmation email sent by OCI Notifications and click the confirmation link.

 

After confirming, In the OCI console, refresh the subscription page and verify the subscription status shows as Active. This step is mandatory, without this confirmation step, the email notifications will not be delivered.

 

6)  Create an OCI Events Rule

Now let’s create the rule that connects Object Storage events to the Notifications.

In the OCI console, choose Observability & Management → Events Service → Rules

Click Create Rule, enter a name and choose the event type related to Object Storage object creates.

For the action, choose Notifications and select the topic created earlier and click Create

7) Upload a File to the Bucket

Let’s test it now. In Object Storage bucket, Click Upload and Choose a file to upload and click Upload.

Once the object is created, OCI should emit the event, the Events rule should match it, and Notifications should send an email to the subscribed address. We can also enable notification for object delete, update.

---

8)  Verify the Email Notification

Check the mail inbox for the email notification generated by OCI. The below notification has been received for deleting an object from bucket.

At this point, we have a working event driven automation flow in your OCI tenancy.

 

 

OCI Logging – Auditing VCN Security list changes

In the previous post, we discussed how to audit VCN Security List changes. In this article, we will review how to audit VCN Route Table changes using OCI Audit service.

Route Tables control how traffic flows within a VCN. Any incorrect modification such as adding an Internet Gateway route or changing a DRG target can impact security posture, connectivity, or cost governance. Therefore, auditing route table changes is critical for enterprise cloud governance.

Login into OCI Console -> Networking -> VCN. It will show list of VCNS, we can choose the desired one.

In the VCN details page, choose Routing, it will list all the route tables associated with the VCN.

In this exercise we have only default route table with single route rule and the route rule is created for external access through Internet Gateway. We will add a route rule for Service Gateway.

Now route rule is added, we will use Audit to identify what changes happened in the route table.

OCI Audit is a native, always-on service that records all API operations across your tenancy. Any modification to a VCN Route Table (creation, update, or deletion) is captured here with full request payload and identity metadata.

Select:

• Compartment → root
• Set appropriate Time Range

Route Tables are network resources under specific compartments. Select the right compartment o see changes across all sub-compartments if required.

Once the timeframe is chosen the audit page will updated with all Event types recorded in that timeframe. Choose UpateRouteTable event type which is appropriate to our requirement.

Other available event types are below.

Event Name = UpdateRouteTable
Event Name = CreateRouteTable
Event Name = DeleteRouteTable

UpdateRouteTable event provides

·       Who made the change (User/Service Principal)

·       When it was made (Timestamp)

·       From which IP address

·       Target Resource OCID

·       Request/Response payload

 

In the JSON output, locate the stateChange section.

Inside stateChange, expand:

• previous
• current

Within these sections, examine routeRules.

By comparing the previous and current routeRules arrays, you can identify exactly what changed.

In our case:

• previous → One route rule
• current → Two route rules

This confirms that a new route rule was added.

In summary, OCI Audit logs provide a reliable and tamper-resistant mechanism to track route table changes, something the OCI Route Table UI itself does not natively provide.

 

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.