OCI Connectivity Diagnosis — Network Security Rules, Host Firewalls and Service Listeners | Data In Hands

Diagnose Oracle Cloud connectivity by separating network security rules, host firewalls and service listeners. The three layers in this guide are diagnostic categories, not three kinds of firewall unique to OCI. Apache Listen is a service setting. DNS, routing, HTTP Host, TLS SNI and certificates, and application responses can also affect the result.

This article documents a real "Connection refused" issue during subdomain deployment — and the systematic way to find which layer is the culprit.

The 3-layer structure

[ Internet request ]

▼

Layer 1: OCI Security List (VCN)

"Is this port allowed in?"

pass ▼

Layer 2: OS Firewall (firewalld)

"Does the OS allow this port?"

pass ▼

Layer 3: Apache configuration

"Is something listening here?"

pass ▼

[ Response ]

1 → 2 → 3 is one possible diagnostic order. The outputs and “pass” labels below are clues from the reported case, not acceptance criteria for the current environment. Connection refused alone does not establish firewall blocking, and a 403 from an IP request does not prove the intended VHost, WAF traversal or successful TLS authentication. -k skips certificate verification.

Real case: port 80 "Connection refused"

The reported outputs show a 403 response over HTTPS (443) and a refused HTTP (80) connection. These alone do not establish service health or identify a blocking layer.

# 443: reported output example
curl -v https://<your-server-ip> -k --connect-timeout 10
# HTTP/1.1 403 Forbidden ← HTTP response observed; intended service/TLS verification is separate

# 80: refused
curl -v http://<your-server-ip> --connect-timeout 10
# Connection refused ← connection failed; determine the cause separately

Layer-by-layer diagnosis

Layer 1 OCI Security List

Check in OCI Console:

Networking → Virtual Cloud Networks → VCN → Subnets → Security Lists
→ Ingress Rules

A port-80 rule was visible in this case, but its presence alone does not establish that the connection is allowed or reachable. Consider the combined allow rules of the security lists associated with the actual VNIC’s subnet and all NSGs that the VNIC belongs to, matching direction, source/destination, protocol, ports, stateful/stateless handling and return-traffic requirements. Check the applicable routing separately. If the endpoint has a ZPR security attribute, its traffic must also satisfy the ZPR policy’s allow conditions.

⚠️ Source and destination ports: For TCP ingress, Source Port Range identifies the sender’s port and Destination Port Range the receiving service’s destination port. In an example where HTTP uses port 80, compare 80 with the destination port. A client normally uses an ephemeral source port; do not assume it equals the service port. Set any source-port restriction according to the actual traffic and policy; an unrestricted source-port range means all source ports. This is not an instruction to change existing rules in bulk.

Layer 2 OS Firewall (firewalld + iptables)

# firewalld services
sudo firewall-cmd --list-services
# dhcpv6-client http https ssh ← service-list example; active zone/rules need separate review

# iptables
sudo iptables -L -n | grep -E "80|DROP|REJECT"
# Filtered-list example from the case; not a complete policy/rules verdict

These outputs alone cannot establish that the host firewall permits this connection. A service listing without a zone targets the default zone, which can differ from the active zone bound to the interface or source. Filtered iptables output does not show the complete ruleset, including chain policies, rule order, jump targets, other tables and IPv6. Hold the verdict until the backend in use and effective runtime policy have been checked, including differences from permanent configuration.

Layer 3 Apache Listen — listener check

# Check what Apache is actually listening on
sudo ss -tlnp | grep -E ":80 |:443 "
# Only 443 observed in the example; required port-80 listener/reachability needs separate review

# Why?
grep -r "Listen" /etc/httpd/conf/ /etc/httpd/conf.d/ | grep -v "#"
# Only: Listen 443 https
# httpd.conf has: #Listen 80 (commented out)

The missing port-80 listener is a clue in this case; WAF usage alone does not establish its cause or required ports. Direct HTTPS does not always need port 80, but HTTP service or an HTTP-01 validation path requires a port-80 reachability review. Do not run the changes below as a universal fix; decide applicability only after a separate review of existing services and the origin protection boundary.

sudo sed -i 's/^#Listen 80$/Listen 80/' /etc/httpd/conf/httpd.conf
sudo apachectl configtest && sudo systemctl restart httpd

# Verify
sudo ss -tlnp | grep ":80 "
# LISTEN 0 511 *:80 *:* ← listener observation example; not end-to-end acceptance

Complete diagnostic checklist

The commands and results below are quick observation clues. Compare DNS answers with the approved direct or proxy route. A rule existing, no matching DROP, LISTEN, Syntax OK or no errors in a log excerpt does not establish end-to-end health or WAF protection.

#	What	Command	Observation and limit
0	DNS	`dig domain +short`	Compare DNS answers with the intended direct/proxy route
1	Security List	Console → Ingress Rules	Rule existence alone does not establish scope or reachability
2a	firewalld	`sudo firewall-cmd --list-services`	Partial service list; check active zone and rules
2b	iptables	`sudo iptables -L -n \| grep DROP`	Filtered output; no DROP does not prove traffic is allowed
3	Apache	`sudo ss -tlnp \| grep ":port "`	Listener observed; external reachability needs separate checks
4	Config	`sudo apachectl configtest`	Syntax-check result; not a service-health guarantee
5	Logs	`sudo tail -20 /var/log/httpd/error_log`	Log excerpt only; absence of errors does not prove health

Special case: OCI WAF

The diagram and table below illustrate one possible configuration, not verified settings of the current account. Using WAF or a DNS CNAME does not automatically block direct origin access. Redirect codes, origin protocol/ports and allowed sources depend on the actual design.

[ User ] → [ OCI WAF (ZENEDGE) ]

▸ HTTP → HTTPS redirect (if configured; status code per policy)
▸ WAF → origin (configured protocol and port)

Behavior	Explanation
Origin port requirements	A WAF redirect alone does not establish that port 80 is unnecessary; review service and validation paths separately
Direct origin access restrictions	WAF use does not block access automatically; separate restrictions are needed for intended sources and paths
DNS routing through WAF	Compare DNS configuration with the Edge policy-provided CNAME; a CNAME itself is not an origin access restriction

Before adding a direct subdomain on the same origin IP, review the existing WordPress Host/SNI and default VHost together with network and application access restrictions. Separately design and authorize any expanded access so the static site does not weaken another site's WAF boundary. This guide does not establish that the current server permits bypass; do not perform unsolicited direct-IP probes.

✅ Key takeaway: A visible port rule alone does not establish external reachability. The three diagnostic categories in this guide distinguish network security rules, host firewalls and service listeners. Apache Listen is not a firewall; routing, DNS, TLS and WAF/origin access restrictions relevant to the request path also need separate review. This guide does not establish which layer is the most frequent cause or guarantee a diagnosis time or resolution.