Sometimes in Oracle Cloud Infrastructure (OCI), servers are not reachable using ping.

This issue usually occurs because ICMP traffic is blocked in the Security List or Network Security Group (NSG).

By default, OCI controls inbound and outbound traffic using Security Rules.
If the required ICMP rule is missing or deleted, the server will not respond to ping requests.

In this practical, we will troubleshoot the issue by creating a custom Security List and manually allowing ICMP traffic.

• Open OCI Console

• Navigate to:

Networking → Virtual Cloud Networks (VCN)

• Select your VCN

• Navigate to:

Security → Security Lists

• Open the default Security List

• Delete the existing ICMP ingress rule if available

This will simulate the issue where the server becomes unreachable through ping.

Click:

Create Security List

Click:

Add Ingress Rule

• Navigate to:

Subnet → Security Lists

• Remove the old Security List if required

• Attach the new custom Security List

• Save the changes

Run the following command from your local machine or another server:

ping <Public-IP>

ping 129.x.x.x

If the ICMP rule is configured correctly, the server will respond successfully.

• Server becomes reachable using ping

• ICMP traffic is successfully allowed through the custom Security List

The server was not reachable because ICMP traffic was blocked in the Security List.

After creating a custom Security List and allowing ICMP ingress traffic, the ping issue was resolved successfully.

This troubleshooting is commonly used in OCI networking practicals and real-time cloud administration tasks.

Steps to create security list

1. Go to Networking click on VCN select the network compartment and click on security option

2. Click on 'create security list' and give the name of Security list and click on create security list

3. A custom Security List (SL) has been created successfully.

4. Now attach the custom Security List (SL) to the public subnet and remove the default Security List. This helps avoid conflicts, as the subnet may otherwise have multiple security rules applied and it can become unclear which rules are allowing or blocking the traffic. Using only the required custom Security List makes the network configuration cleaner and easier to manage.

Under the Hub Network, go to the Subnets tab and select the subnet named Public Subnet Hub-Network

5. Under Public Subnet Hub-Network select the tab security and click on add security list

6. Now from the dropdown select the custom security list that you have created and click on add security list

7. Now Custom security list has been added to the public subnet

8. Now remove the default Security list

9. Default security list has been removed now

10. Let's try to establish PuTTY connectivity.

As shown below, the connectivity is not working because the default Security List associated with the Public Subnet Hub-Network was deleted, and the newly attached Security List does not contain the required ingress rules.

11. Now we will add an ingress rule to allow incoming traffic.

Navigate to the custom Security List (SL) and add the required ingress rule.

12. Navigate to security rules and click on add Ingress rule

13. The Source CIDR should be the IP address or network range from which access to the server needs to be allowed. Select the TCP protocol and specify Port 22, which is used to establish an SSH connection.

14. Now, let's try reconnecting using PuTTY. As shown below, the connectivity is working successfully.

15. Let's try to ping Google. As shown below, the request is failing because only inbound traffic has been allowed, while outbound traffic is still blocked.

16. Now, let's add an egress rule to allow outgoing traffic.

Set the Destination CIDR to 0.0.0.0/0 to allow traffic to all IP addresses, and select the ICMP protocol to permit ping traffic.

17. Now, let's try pinging Google again. As shown below, the connectivity is working successfully. However, some packet loss can be observed because the network connection was temporarily interrupted when outbound traffic was blocked.

18. Now, let's try pinging again. As shown below, there is no packet loss because outbound traffic is already allowed, resulting in uninterrupted network connectivity.