LAB 23 ‐ Troubleshoot ‐ Connection Issue(Recreate security list, Gateway, Route) - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

Troubleshooting Network Connectivity & Validating Infrastructure Dependencies

In this LAB, we perform "Negative Testing" to understand how different network components impact the connectivity of an OCI Compute Instance. By intentionally removing and recreating critical components like Ingress Rules, Internet Gateways, and Route Rules, we validate the essential requirements for a successful PuTTY (SSH) connection.

Scenario 1: Testing Security Lists (Ingress Rules)

Action: Removed the TCP rule (Port 22) from the Ingress Rules.

Observation: PuTTY connection failed immediately.

Conclusion: Ingress Rules act as a mandatory firewall; without Port 22 being open, SSH traffic is blocked at the subnet level.

🔥 Steps for Troubleshooting

  1. Navigate to Networking and select the option Virtual Cloud Networks
  1. Select the compartment where our network is created
  1. Under HUB_NETWORK go to subnet tab and click on [public subnet-HUB_NETWORK], as our instance is hosted on it.
  1. Inside public subnet-HUB_NETWORK go to security tab which is equivalent to firewall and select the option [Default Security List for HUB_NETWORK]
  1. Under Default Security List for HUB_NETWORK select the tab security rules
  1. To form a connectivity via putty this rule is mandatory
  1. As we can see "TCP traffic for ports: 22 SSH Remote Login Protocol" rule is there hence we can login to Putty.
  1. Now if we delete the rule "TCP traffic for ports: 22 SSH Remote Login Protocol" ?

We'll not be able to login

  1. To fix the issue lets add back the rule "TCP traffic for ports: 22 SSH Remote Login Protocol"

Now, let's try to login again

Scenario 2: Testing Internet Gateway and Routing

Action: Removed the Internet Gateway (IGW) and the associated entry in the Route Table.

Observation: PuTTY was unable to establish a connection.

Conclusion: Even if the security port is open, the traffic needs a physical path (Internet Gateway) and a map (Route Table) to reach the instance from the public internet.

🔧 Troubleshooting Routes and Gateways

  1. Inside public subnet-HUB_NETWORK, we'll see the route table

If we delete the route rule, we'll not be able to connect to internet

Now again we won't be able to login to putty.

  1. Navigate to HUB_NETWORK and select the gateway tab and scroll down to Internet Gateways

lets terminate the internet gateway

Now, again we cannot login to putty

  1. Let's create the route table back

If we attempt to create a Route Rule before recreating the Internet Gateway (IGW), we will encounter an issue in the "Target Selection" phase. Since the IGW has been deleted, the dropdown menu for the 'Target' will be empty.

means if there is no gateway, we can't create route table.

The Solution (The Correct Sequence):

To restore connectivity, we must follow a specific order:

First Step: Recreate the Internet Gateway to establish a valid target for external traffic.

Second Step: Update the Route Table by adding a Route Rule (0.0.0.0/0) that points to the newly created Internet Gateway.

Conclusion: We cannot define a path (Route) without a destination (Gateway). Therefore, the presence of the Internet Gateway is a prerequisite for configuring the routing logic.

  1. So first, we recreate the Internet Gateway to establish a valid target for external traffic.

Scroll down for Internet Gateway and click on Create Internet Gateway

  1. As we have internet gateway, let's create route
  1. Now let's try to reconnect via putty and it will be connected.

Final Takeaway: The Connectivity Trinity

"For a successful PuTTY (SSH) connection, the 'Trinity of Networking' must be perfectly aligned. If any of these three components are missing, the connection will fail:"

1. Ingress Rule (The Open Door):

Logic: Port 22 must be open in the Security List. Without this, the 'door' to your server is locked.

2. Internet Gateway (The Road):

Logic: A physical path must exist between the OCI Virtual Cloud Network and the Public Internet. This is the 'road' your data travels on.

3. Route Table Entry (The Map):

Logic: The network must have a specific instruction (0.0.0.0/0) directing traffic to the Internet Gateway. This acts as the 'map' that ensures data is heading in the right direction.

Ingress vs. Egress: The Network Traffic Controllers

In OCI, network security is managed by defining rules for traffic flow. These rules determine how data enters and leaves your resources.

1. Ingress (Inbound Traffic)

Ingress refers to any data packet coming from the outside (Internet or another VCN) into your OCI resource (e.g., a Compute Instance).

Purpose: It acts as a shield to protect your server from unauthorized access.

Real-world Scenario: When you use PuTTY to connect to your server, you are initiating an Ingress request. For this to work, you must open Port 22 in the Ingress Rules of your Security List.

Logic: "Who is allowed to enter my server?"

2. Egress (Outbound Traffic)

Egress refers to any data packet sent from your OCI resource to an external destination (Internet or another subnet).

Purpose: It ensures that your server only communicates with authorized external locations.

Real-world Scenario: When you run a command like sudo yum update on your Linux server, the server sends a request to the internet to download updates. This is Egress traffic.

Logic: "Where is my server allowed to send data?"

Important Note: Stateful Inspection OCI Security Lists are Stateful.

"This means if you allow an Ingress request (e.g., PuTTY on Port 22), the system automatically remembers that connection and allows the response to go back out. You do not need to create a matching Egress rule for the response."

Understanding CIDR 0.0.0.0/0: The "Open Access" Rule

When configuring Ingress and Egress rules, we use the CIDR block 0.0.0.0/0 to define the scope of the network.

What does 0.0.0.0/0 mean?

Definition: It represents the entire IPv4 address space.

In Ingress: If you set the Source CIDR to 0.0.0.0/0, it means anyone from anywhere in the world can attempt to connect to your server (provided the port is open).

In Egress: If you set the Destination CIDR to 0.0.0.0/0, it means your server can reach any destination on the public internet.

Note: Why is it called "Quad Zero"?

"The 0.0.0.0/0 notation is often called 'Quad Zero.' It acts as a wildcard. In our troubleshooting lab, we used this to ensure that our network path was completely open while testing the Internet Gateway and Route Table functionality."

Implementation in Security Rules

Rule Type Source/Destination CIDR Effect
Ingress Source 0.0.0.0/0 Allows traffic from the entire Internet to the specified port (e.g., Port 22 for SSH).
Egress Destination 0.0.0.0/0 Allows the server to send data to any website or service globally (e.g., for OS updates).

💡 Professional Note: While 0.0.0.0/0 is perfect for our learning labs to ensure connectivity, in a real-world Production Environment, we should restrict the Source CIDR to a specific IP range to enhance security.