If you have ever opened a port on an Ubuntu server running on Oracle Cloud Infrastructure and found that it still would not work, you have run into one of the most common and confusing aspects of the platform. You allow the port on the server, you double-check your commands, and yet the service remains unreachable. The reason is almost always the same: Oracle Cloud has two separate firewall layers, and a port has to be open in both of them before traffic can pass.
This guide explains how port access works on Oracle Cloud, walks through opening a port correctly in both layers, and covers the troubleshooting steps for when things still do not behave. By the end you will understand exactly why the “I opened the port but it still does not work” problem happens and how to avoid it for good.
The Key Concept: Two Firewalls, Not One
On a typical server elsewhere, opening a port is a single step: you adjust the operating system’s firewall and you are done. Oracle Cloud is different because your traffic passes through two independent gatekeepers before it reaches your application.
The first gatekeeper is the cloud-level firewall. Oracle attaches network security rules to your instance’s virtual network interface, controlled from the Oracle Cloud console. These come in two forms: a security list attached to the subnet, and optionally a network security group attached directly to the instance. This layer decides whether traffic is even allowed onto your instance from the wider internet.
The second gatekeeper is the operating system firewall running inside Ubuntu itself, managed with tools like ufw or iptables. This layer decides whether traffic that has already reached the instance is allowed to reach a specific service.
For a connection to succeed, the port must be open at both layers. If either one blocks it, the connection fails. This is the single most important thing to understand, and it explains the overwhelming majority of port problems on Oracle Cloud. People open the port in one layer, see no change, and assume they did something wrong, when in reality the other layer is silently blocking the traffic.
Step One: Add an Ingress Rule in the Oracle Cloud Console
Start with the cloud-level firewall, because this is the layer people most often forget. You will be adding an ingress rule, which permits incoming traffic to reach your instance. Follow these steps in the Oracle Cloud console.
First, log in to your Oracle Cloud console. Navigate to Compute, then Instances, and click on your Ubuntu instance to open its details page. Scroll down to the Primary VNIC section and click on your subnet. On the subnet page, click on the default security list. This is the ruleset that controls what traffic is allowed to reach instances on that subnet.
Now click Add Ingress Rules and fill in the form with the following values. Set the Source Type to CIDR. Set the Source CIDR to the range that covers all addresses, written as 0.0.0.0/0, which allows traffic from anywhere on the internet. Set the IP Protocol to TCP for standard web and application traffic. Set the Destination Port Range to the port you want to open, such as 80 for plain web traffic. Then click Add Ingress Rules to save.
That single rule opens the port at the cloud layer. If you want to open the secure web port as well, repeat the process with a destination port of 443. For services that use UDP rather than TCP, such as DNS, choose UDP as the protocol instead.
One important caveat applies here. If your instance also uses a network security group, which is an optional extra firewall attached directly to the instance’s network interface, you must add the same rule there too. A network security group can silently block a port even when the security list allows it, so when a port refuses to work despite a correct security list rule, always check whether a network security group is attached and whether it contains the rule you need.
Step Two: Configure the Ubuntu Firewall
With the cloud layer permitting traffic, you now open the port inside Ubuntu. Here there is a detail specific to Oracle Cloud that catches many people off guard: unlike most other hosts, Oracle Cloud’s Ubuntu images use iptables rather than ufw by default, and they ship with a pre-configured ruleset that includes a rule rejecting any incoming traffic not explicitly allowed above it. This is why starting a service is not enough on its own; you have to add an allow rule into the existing iptables chain.
To do this, first SSH into your instance. Then run the following command to insert a rule allowing new TCP connections on port 80:
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPTThen save the change so it persists after a reboot. Without this step, your rule vanishes the next time the server restarts:
sudo netfilter-persistent saveThat is the complete process for the common case. For the secure web port, run the same insert command with 443 in place of 80, then save again.
Understanding the position number
The number 6 in that command is the position in the iptables chain where the rule is inserted. It matters because Oracle’s default ruleset has a reject rule, and your allow rule must sit above it to take effect. On a standard Oracle image the reject rule commonly sits at position six, so inserting there pushes the rejection down below your new allow rule.
If your ruleset differs, you can check the current order before inserting:
sudo iptables -L INPUT -n --line-numbersThis prints the rules with line numbers. Find the rule that rejects traffic, which usually mentions reject-with icmp-host-prohibited, and make sure your allow rule goes above it. If that reject rule sits at a different position, adjust the number in the insert command so your allow rule lands above the rejection rather than below it. This ordering is the entire point: the firewall reads rules top to bottom and acts on the first match, so an allow rule above the rejection is honoured while one below it is never reached.
The ufw alternative
If you have chosen to use ufw on your instance instead of Oracle’s default iptables setup, the equivalent is much simpler. Always allow SSH first so you cannot lock yourself out, then allow your web ports and enable the firewall:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableUse one approach or the other consistently. Mixing raw iptables edits with ufw management on the same server leads to confusion about which rules are actually in effect.
A Serious Warning About Flushing Firewall Rules
There is one mistake that deserves a dedicated warning because it can destroy your access to the server entirely. Avoid running a blanket command that flushes all firewall rules and then saving that empty state as permanent. On a remote server, clearing every rule can instantly cut off your SSH connection, and if the empty configuration is saved as the new permanent state, you can find yourself completely locked out with no way back in except rebuilding the machine.
If you ever need to reset your firewall, do it deliberately and carefully, ensuring SSH access remains permitted throughout, and never combine a full flush with a permanent save while you are connected remotely. Working with ufw and targeted rules, rather than manually flushing the underlying tables, keeps you safe from this class of disaster.
Step Three: Verify the Port Is Actually Open
Once both layers permit the port and the rules are correctly ordered, confirm that everything works. There are a few complementary checks worth running.
First, verify that your service is actually listening on the port from inside the server:
sudo ss -tlnp | grep :443This shows which process, if any, is bound to the port. If nothing is listening, the problem is not the firewall at all but the service itself, which either is not running or is configured to listen on a different port.
Next, test the connection from your own computer, not from the server, since testing from the server bypasses both firewall layers and can give a misleadingly positive result. From your local machine, attempt to reach the port. If the connection succeeds, both layers and the service are working together correctly. If it times out, one of the two firewall layers is still blocking, and the cloud console layer is the more likely culprit. If it is actively refused rather than timing out, the firewall is permitting the traffic but no service is listening.
A Practical Troubleshooting Checklist
When a port refuses to work on Oracle Cloud, run through these checks in order and you will find the cause quickly. Confirm the Oracle console security list has an ingress rule for the port. Check whether a network security group is attached and, if so, that it contains the same rule. Verify Ubuntu’s ufw allows the port. Inspect the raw rule order to make sure no reject rule sits above your allow rule. Confirm the service is genuinely listening on the port from inside the server. Finally, test from an external machine rather than from the server itself. In practice, the two most common causes by far are a missing rule in the Oracle console layer and a service that is not actually listening, so start there.
Common Ports Worth Knowing
A handful of ports come up repeatedly when hosting on Ubuntu. Port 22 carries SSH, your administrative lifeline, which should always be permitted before enabling any firewall. Port 80 carries standard web traffic and port 443 carries secure, encrypted web traffic; a typical website needs both. Port 53 carries DNS and, unusually, uses UDP as well as TCP, so a DNS server needs both protocols opened. Encrypted DNS services use port 853 for DNS over TLS. Whatever the port, the process is identical: open it in the Oracle console layer, open it in Ubuntu’s firewall, mind the rule order, and verify from outside.
Conclusion
Opening a port on Ubuntu running on Oracle Cloud is straightforward once you internalize the central idea that there are two firewall layers, not one. The cloud console controls whether traffic reaches your instance, and Ubuntu’s own firewall controls whether it reaches your service, and both must permit the port. Open it in the Oracle security list, open it with ufw inside Ubuntu, watch out for rule ordering, never flush your rules carelessly on a remote server, and always verify from an external machine. Follow that sequence and the frustrating “I opened the port but it still does not work” problem disappears for good.