Why Your Ubuntu Instance on Oracle Cloud Still Blocks Ports (And How to Fix It Instantly)

Introduction

Deploying a cloud server should be an empowering experience, promising flexibility and fast results. But for many users spinning up a fresh Ubuntu VM on Oracle Cloud Infrastructure (OCI), an all-too-common frustration arises: SSH works, but HTTP, HTTPS, or any non-22 port stays stubbornly closed, even after meticulously configuring security lists or network security groups to allow them.

If Google or StackOverflow led you here, you’re not alone. This puzzling failure is not caused by Oracle’s cloud platform, nor (entirely) by your network rules. The real snag? Ubuntu’s own internal firewall configuration, usually managed by iptables, silently blocks your ports—regardless of what the cloud allows—leaving your instance inaccessible on anything other than SSH.

This article explains the underlying problem, demystifies the network and firewall behavior involved, walks you through diagnostics, and shows you the immediate one-line fix:

sudo iptables -I INPUT -j ACCEPT

Let’s dig in.

The Big Picture: Networking on OCI and Ubuntu

To understand why your ports aren’t accessible, we need to look at both layers of security:

1. Oracle Cloud’s Virtual Network Security
2. Ubuntu’s Local Firewall Rules

Each enforces its own set of rules, and both must explicitly permit the traffic for a connection to succeed.

1. OCI Network Security: Security Lists, NSGs, and Routes

Every OCI compute instance attaches to a subnet inside a Virtual Cloud Network (VCN). The flow of traffic into and out of your subnet is governed by security lists (SLs) and, optionally, more granular network security groups (NSGs). These act as virtual firewalls on the network layer.

Key points:

• Security lists apply rules to all VNICs in a subnet; NSGs apply to selected resources only.
• Ingress rules specify what incoming traffic is permitted; egress rules control outgoing traffic.
• The default security list generally only allows SSH (port 22) and essential ICMP traffic.
• Even with permissive rules, traffic can still be blocked at the OS level by the instance’s own firewall.

2. Host-Level Firewall: Ubuntu’s iptables Rules

Ubuntu, like most Linux distributions, includes a local firewall managed by iptables (sometimes with frontends like UFW or firewalld, more on that soon). The default OCI Ubuntu server image usually:

• Disables UFW for compatibility on Oracle cloud.
• Leaves iptables rules in place that accept SSH but drop other ports.
• This configuration means: Cloud security lists and local iptables both must allow traffic, or connections will fail.

Diagnosing the Problem: Not All "Closed Ports" Are the Same

Let’s say you’ve:

• Added ingress rules for port 80 (HTTP) and port 443 (HTTPS) in OCI’s security list (or NSG).
• Restarted your instance and confirmed a public IP.
• Installed and started Apache or Nginx (curl localhost on the VM itself works).

But from your own computer, visiting http://<public_ip> times out or refuses the connection.

The Key Symptoms

• SSH (port 22) works from outside.
• Other ports (e.g. 80, 443) do not respond over the Internet—even though your web server is running and listening.

Understanding Error Messages

• "Connection refused"
  This usually means the request reached your server, but no process is listening on the target port.
• "Connection timed out"
  This suggests that traffic is blocked by a firewall somewhere along the path—most commonly, at the OS level or in a cloud security group.

Quick Service Check

On your OCI instance, run:

sudo netstat -tulnp | grep LISTEN

or

sudo ss -tuln

You’ll see which processes are listening, and on which ports.

Where (and Why) the Traffic Gets Blocked

How OCI Routes the Traffic

At the network level, OCI’s VCN and security list must allow traffic. If your ingress rules don’t allow incoming TCP on e.g. port 80 from 0.0.0.0/0, connections will never reach the VM. Assuming you did this correctly, what’s next?

What Happens On the Instance

With a default Ubuntu image:

• UFW is disabled (so toggling it has no effect).
• iptables rules exist—often with a policy like:
  • Allow RELATED, ESTABLISHED
  • Allow SSH (port 22)
  • Reject everything else

So, any packet reaching your instance for port 80 or 443 is explicitly dropped (or rejected) by iptables, even though the cloud network would let it through.

In short: The VM's firewall trumps the cloud network.

A Closer Look: iptables, UFW, and firewalld

Why Isn’t UFW the Answer?

Ubuntu users are often conditioned to manage the firewall with the friendly ufw tool. But OCI disables UFW in its standard Ubuntu image, because:

• Managing iptables via UFW can conflict with Oracle’s cloud requirements or other management tooling.
• Direct iptables configuration is the standard approach on OCI Ubuntu images, as per Oracle docs.

Trying to enable or use UFW usually results in no effect or additional confusion.

firewalld is Sometimes Present

Some guides install firewalld, another user-friendly firewall manager, but OCI’s standard Ubuntu image typically does not include it. If both firewalld and ufw are enabled, firewall rules may conflict, resulting in even more confusion and hidden port blocks (see troubleshooting at [OCI forums][48†source]).

The iptables Reality

The final arbiter is the actual iptables rules in the kernel. Any chain or default policy that blocks non-SSH traffic results in dropped packets—even with cloud firewall rules wide open.

The Quick Fix: Accept All Incoming Traffic

The fastest way to test if your problem is caused by the local firewall is to simply allow all INPUT traffic using iptables:

sudo iptables -I INPUT -j ACCEPT

Why does this work?

• -I tells iptables to insert this rule at the very top of the INPUT chain, before any drops/rejects.
• -j ACCEPT directs iptables to unconditionally accept all inbound packets.
• As a result, all traffic that reaches the VM (after passing the Oracle Cloud’s network policies) is accepted (unless denied by a process or application layer).

What does this NOT do?

• It does not override the cloud security rules—you still need to allow ports in OCI’s security lists or NSGs.
• It does not open ports for applications that are not listening (i.e. you still need Apache, Nginx, etc. running and listening on the target port).
• It is typically used as a diagnostic or “get it working now” measure; for ongoing security, you should refine the rule to accept only required ports.

Don’t forget:
iptables rules are not persistent by default! A reboot or restart can revert changes.

Step-by-Step: Fixing Port Accessibility on OCI Ubuntu

1. Confirm OCI Security Rules
   • In the OCI Console, for your VCN and subnet, ensure an Ingress Rule allows the desired port (e.g. 80) from the Internet (0.0.0.0/0), protocol TCP.
2. Test Your ConnectionTry connecting via your local browser or curl http://<public_ip> from another machine. If your service is up, you should get a response.

Make the Change PersistentTo avoid losing iptables changes at the next reboot, save the rules:

sudo netfilter-persistent save
# or, for systems without netfilter-persistent
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Confirm that the rule persists by looking at /etc/iptables/rules.v4 or rebooting and checking port access again.

Check, Then Adjust iptablesList your current rules:

sudo iptables -L --line-numbers

You’ll probably see a REJECT all or DROP all rule following the SSH rule. Now, insert the universal accept rule:

sudo iptables -I INPUT -j ACCEPT

This will immediately allow all incoming connections, subject to OCI’s external security rules.

Check That Your Service is Running

sudo netstat -tulnp | grep :80

or

sudo ss -tuln | grep :80

If your web server is listening, you’ll see a line showing 0.0.0.0:80 or similar.

Official Confirmation: Oracle Documentation and Community Experiences

Oracle Docs Confirm the Behavior

Oracle’s official [tutorial for Apache on Ubuntu in OCI][50†source] explicitly includes these commands:

sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
sudo netfilter-persistent save

– because, as they note, “the Ubuntu firewall is disabled by default. However, you still need to update your iptables configuration to allow HTTP traffic.”

Oracle’s own developer blog reinforces this, explaining that managing ports on OCI relies on iptables, not UFW or firewalld on Ubuntu instances, and that new iptables rules must not be appended after a reject rule.

Real User Frustration (Reddit, StackOverflow, and Forums)

Threads like [this Reddit tip][46†source] are filled with users reporting hours or days lost before discovering the iptables block. Many point out the contrast with other cloud platforms (AWS, Azure, GCP), which “just work” once security group rules are open. This difference is the direct result of Oracle’s security model and Ubuntu image defaults, not a “bug” but rather a stricter security posture by default.

Other community solutions, such as switching to firewalld or ufw, often lead to further conflicts or confusion on OCI images because those tools are secondary to the iptables rules enforced by default.

What About Other Distributions or Images?

If you use Oracle Linux or Ubuntu images from other sources, you may see differences:

• Oracle Linux: Local firewall is managed with firewalld; same principle applies—host firewall can block external traffic even if cloud security is permissive.
• Ubuntu images supplied by Oracle: UFW is off, direct iptables editing is expected.
• Minimal or custom images: May have no firewall rules at all (in which case ports are open as long as cloud rules permit).
• If you choose to use UFW or firewalld, ensure you only use one tool at a time and understand that conflicting tool configs can make debugging more difficult.

Security Implications and Best Practices

“sudo iptables -I INPUT -j ACCEPT” disables host-level firewall protection!

• This is OK for quick diagnostics or personal testing, especially when cloud security lists are tightly locked down.
• For production, you should instead permit only required ports at both the cloud and local firewall levels.

For example:

sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT
sudo netfilter-persistent save

You may also wish to remove or adjust any general REJECT/DROP rules that appear before the new rules, since iptables processes rules in order.

Never lock yourself out:
Always keep SSH (port 22) open in both OCI security rules and iptables.

"Connection Refused" vs "Connection Timed Out": A Side Note for Diagnostics

• "Connection refused":
  The VM is reachable—but no process is listening on the target port, or the host firewall actively rejects the packet, sending a TCP RST in response.
• "Connection timed out":
  The packet is dropped silently, often by a firewall rule (cloud or host), and the client gives up after waiting for a reply.

Implication:

• If you get "connection refused," check that your service is running and listening.
• If you get "timed out," check both the instance’s firewall (iptables) and cloud security list rules.

In Summary

The recurring port accessibility problem for Ubuntu on Oracle Cloud boils down to the interaction between cloud-layer security policies and default host-level iptables rules. Unless both layers allow the traffic, your instance will remain unreachable on non-SSH ports.

• Always open necessary ports in OCI network security lists or NSGs.
• Then explicitly permit those ports in iptables.
• Remember to make changes persistent, or they will be lost on reboot.
• For best practice, limit ACCEPT rules to only the ports and protocols you intend to serve.

For quick diagnostics,

sudo iptables -I INPUT -j ACCEPT

can confirm your issue is the host firewall.

References in Context

• Oracle Cloud documentation and tutorials clarify the cloud/host firewall interaction and explicitly advise iptables configuration for Ubuntu on OCI.
• Reddit tipsters and StackOverflow responders confirm the issue and the one-line iptables fix.
• Community forums provide guidance on making iptables changes persistent to survive reboots.
• Official manuals and Linux community blogs explain the technical differences among iptables, UFW, and firewalld for further tuning and troubleshooting.

Final Note

If you want a cloud environment that “just works” by only opening cloud security rules, understand that OCI’s approach is more conservative—it expects you to also configure your VM’s internal firewall. With this awareness, frustration ends and you remain in full control of your server’s exposure.

Be secure, deliberate, and always test changes before deploying to production!