Why Traffic Is Still Blocked Even When Firewall Rules Look Correct

When a service appears unreachable even though firewall rules seem correct, the problem often lies in the position, order, state, or context of the rules rather than their content. The article presents a step‑by‑step methodology that starts with three simple connectivity tests: curl to 127.0.0.1, curl to the host's own IP, and an external curl. These tests identify whether the failure occurs on the local loopback, the host interface, or the external path.

If the external test fails, the next step is to capture packets on the server with tcpdump -i any -nn 'tcp port 8080' to verify whether the SYN packet reaches the kernel and whether a SYN‑ACK is returned. The presence or absence of the reply directs the investigation toward cloud security groups, VPC ACLs, OS firewall zones, default policies, conntrack table limits, or reverse‑path filtering (rp_filter).

The guide then details how to inspect the OS firewall using firewall-cmd --zone=public --list-all, iptables -L -n -v, or nft list ruleset, checking for correct zone bindings, rule order, and default DROP policies. It explains how stateful firewalls rely on the conntrack table and how a full table or mis‑configured rp_filter can silently drop packets.

Application‑level checks include confirming that the process is listening on 0.0.0.0:8080 with ss -lntp or lsof -i :8080, and verifying SELinux/AppArmor logs for AVC denials. The article also covers Docker environments, showing that container port mappings bypass the INPUT chain and require inspection of the nat table and the DOCKER-USER chain, with examples such as iptables -I DOCKER-USER -p tcp --dport 8080 -j ACCEPT.

Verification is performed by adding a rule, reloading the firewall, and confirming external access with multiple curl attempts while simultaneously observing the full three‑way handshake in tcpdump. The article provides a decision‑tree diagram to guide the troubleshooting flow, risk reminders for high‑impact actions, rollback procedures, and automation scripts for continuous monitoring.

Overall, the article emphasizes a "one‑layer‑at‑a‑time" approach, ensuring that each potential barrier—from cloud security groups to kernel conntrack limits—is examined and validated before concluding that the firewall configuration is the root cause.