Comprehensive Guide to Troubleshooting Linux UFW Firewall Issues

Why Does UFW Say a Port Is Blocked, But It Is Still Reachable?

One possibility is that the connection was already established before the rule changed. UFW is stateful, and existing TCP sessions are allowed to continue even after a deny is applied.

You usually run into this during a scan or a quick external test. ufw status shows the port as blocked, but traffic still flows because the kernel is tracking an active session and honoring it. This is normal behavior, not a bypass.

You can confirm this by looking at current connections.

ss -atp

If you see the port in ESTAB state, that session will persist until it closes. To prove the rule itself is working, terminate the connection and test again.

ss -K dst  dport = 

Once the session is gone, new connection attempts should fail. When they do, it confirms the firewall rule is being enforced, and the earlier reachability was explained by state tracking, which is often the root cause when debugging the UFW firewall.

How Can I Confirm Which Ports are Actually Exposed on a Server?

By testing what the kernel sees and what the network can reach, not what UFW intends to allow or deny. ufw status reflects the configured policy, but it does not tell you whether packets arrive or whether anything is actually listening.

Confirming exposure means stepping outside the abstraction. You need to observe traffic at the socket and packet level, and you need at least one test from outside the host to remove local assumptions.

A port is exposed only when packets arrive, and a listener exists to receive them. Anything else is intent, configuration, or guesswork.

Why Do My UFW Rules Look Correct, But Do Not Match Real Network Behavior?

Because the rule you are reading is not the rule being applied to the packet. This usually comes down to attribution errors rather than syntax mistakes.

Check whether the service is even listening on the protocol you think it is.

ss -tulpen

Verify that the rule exists in the active chains and is evaluated where you expect.

ufw show raw

Confirm which interface and route the packet actually uses to reach the host.

ip route get 

If the protocol does not match, the ingress interface is different, or another rule matches first, the UFW rule you are focused on will never fire. When a rule is shadowed or evaluated after an earlier accept, it becomes invisible to the traffic you are trying to explain, which is where most firewall troubleshooting efforts stall.

How Does Docker Bypass UFW Firewall Rules?

Docker programs its own iptables chains and routes container traffic through them before UFW rules are evaluated. In many cases, UFW never sees the packets at all.

This shows up when a host-level deny looks correct but a containerized service remains reachable. Docker inserts NAT and filter rules that short-circuit the normal UFW path, so traffic can be accepted long before it would hit a UFW-managed chain.

You can see where this happens by inspecting the Docker user chain.

iptables -L DOCKER-USER -n

If traffic is accepted here, it bypasses UFW-managed chains entirely. At that point, the firewall behavior is being defined by Docker’s rule set, not by anything you configured through the UFW CLI.

Why Do UFW Logs Show Ports Instead of Application Profile Names?

Because UFW application profiles only exist at the UFW layer. Once packets reach the kernel, they are evaluated and logged by port, protocol, and address, not by profile labels.

Profiles are a convenience for rule management, not a runtime attribute. Netfilter has no concept of Apache or OpenSSH, only TCP and UDP flows tied to numbers. That distinction disappears as soon as the packet hits the logging path.

Operationally, this matters when reading UFW logging output. The logs confirm that packets moved through the firewall and how they were handled, but they do not reflect which profile you thought you were enforcing. They validate packet flow, not profile intent, which is the correct way to interpret UFW logging.

Why Is a Port Still Open After I Deleted a UFW Rule or Profile?

Because either the traffic is already established, or the traffic is never governed by the rule you removed. There are only two causes that consistently appear in real environments.

The first is existing connections. UFW does not tear down active TCP sessions when a rule or profile is deleted. Those sessions stay alive until they close, by design.

ss -atp

If you see the port tied to ESTAB connections, that traffic will continue regardless of rule changes. Nothing is misconfigured. The kernel is doing exactly what state tracking requires.

The second cause is rule precedence outside the UFW CLI. Rules defined in UFW’s early chains are evaluated before any deny rules you added or removed later.

grep ACCEPT /etc/ufw/before.rules

Any accept here overrides CLI-level denies. If traffic matches these rules, deleting a UFW rule will not change behavior, because that rule was never in the decision path to begin with.

Why Does Blocking a Client IP Not Stop Access in UFW?

Because the IP you are blocking is not the IP reaching the firewall. NAT, reverse proxies, and load balancers all rewrite source addresses before packets hit UFW.

What UFW evaluates is the post-NAT source. If traffic is coming through a proxy or a managed frontend, the original client address is already gone by the time filtering happens.

You can see this directly by watching traffic arrive.

tcpdump -i any port  -n

The source IP in the capture is the only one UFW can act on. If that address is allowed, blocking the original client IP will have no effect.

Why Do UFW Rules Work After Reload but Fail After Reboot?

Because rule evaluation depends on timing and ownership during startup. After a reload, UFW applies rules to a live, initialized network stack. After a reboot, that order is not guaranteed.

Interfaces may not be up when rules load, or routes may not exist yet. Other tools can insert or rewrite iptables rules later in the boot process, changing evaluation order without touching UFW configuration.

From a diagnostic standpoint, the key is recognizing that this is a sequencing problem, not a syntax one. When behavior changes across reboots without rule changes, something else is influencing when and how the firewall rules are applied.

How Do I Troubleshoot UFW on Production Servers?

By starting with what the server actually sees on the wire, not what the rules claim should happen. On production hosts, traffic almost never enters the way the mental model assumes.

Multiple interfaces shift where rules apply. Reverse proxies collapse many clients into a single private source. Bastion hosts turn inbound access into internal traffic. Internal-only services often get tested on paths they were never exposed to. The rules look right because they are right, just not for the packets you are thinking about.

A typical case is a database port that looks blocked but stays reachable from an application tier. The deny is written for eth0, but the traffic arrives on eth1 from a private address after passing through a proxy. UFW evaluates the packet correctly. It just evaluates a different packet than the admin had in mind.

Once you get used to tracing traffic from the client to the interface and into the kernel, these mismatches stop looking mysterious. That perspective tends to matter more than any individual rule when running UFW for Servers.

What Is the Correct Order to Troubleshoot UFW Issues?

The order matters because each step answers a different question about where traffic is being handled or dropped. Skipping ahead usually creates false conclusions.

1. Check Intent: ufw status verbose (Is the rule actually there, and is the default policy what you think it is?)
2. Check the Socket: ss -tulpen (Is the application actually bound to the port and interface?)
3. Check the Raw Rules: ufw show raw (Is an earlier ACCEPT chain in iptables shadowing your new rule?)
4. Check the Wire: tcpdump -i any port -n (Are packets even reaching the network card?)

If the behavior still persists after disabling UFW entirely, then UFW is not the cause.

5. The Isolation Test: ufw disable (If the problem persists, the issue is upstream—check Cloud Security Groups or your ISP.)

That isolation test is blunt, but it is definitive. When traffic behaves the same way with UFW off, the problem is somewhere else in the path.

Why Does UFW Allow Traffic but Nothing Reaches the Server?

Because the packets never arrive at the host. An allow rule cannot act on traffic that is dropped upstream.

You can confirm this by watching for packets directly.

tcpdump -i any port 

If nothing shows up, the block is happening before the server ever sees the traffic. That usually means a cloud security group, provider firewall, or upstream network control, not UFW.

How Does UFW Fit Into the Linux Firewall Stack?

UFW is a frontend that writes rules. Netfilter is what actually enforces them.

All diagnostics that matter happen at the kernel level because that is where packets are accepted, dropped, or forwarded. UFW only shapes intent and ordering before that point. When behavior and configuration diverge, the kernel view is the authoritative one, which is why effective troubleshooting always anchors on UFW in Linux.