Why is my Linux firewall blocking a port?

A service starts fine and works on localhost, but remote clients hang or get refused. Work from the client inward: probe the port, check the listener, read the firewalld or ufw ruleset, open the port permanently, then verify with an external scan.

LinuxProcessesnetworkncportnetcatDiagnosticsHigh risk
Probe the port from another machine with netcat before touching anything: if the connection hangs until timeout instead of being refused, a firewall is dropping the traffic — then inspect the ruleset and open the port permanently.

What this covers

A firewalled port is deceptive, because the service itself looks perfectly healthy: it starts, localhost works, logs show nothing wrong. The trick is to walk the path the traffic actually takes — client, listener, then firewall rules — instead of guessing at the firewall. This guide keeps that order, uses firewalld commands for RPM-based distros and ufw for Debian-based ones, and ends with proof from outside the host.

Symptom

?Connections to the app time out or are refused from other hosts, even though the service starts cleanly and responds on 127.0.0.1. Remote clients hang until their client-side timeout; a fresh install or a firewall reload makes the app unreachable again. Often it worked yesterday and stopped after a config change or reboot, with no error in the application log.

Confirm the service is actually listening

Before touching the firewall, check that the app is bound to the port at all. If the port does not appear in the listening sockets, or the process is bound only to 127.0.0.1 instead of 0.0.0.0, no firewall change will help — the problem is the service or its bind address. Note the owning process name and PID so you know you are looking at the right daemon, and whether it is bound to all interfaces or just loopback.

LinuxList all listening ports with ssMedium riskStep 1

Show every TCP and UDP socket in listening state with the owning process name and PID — the modern replacement for netstat.

Command
$ sudo ss -tulpn

Probe the port from another machine

Run netcat in scan mode from a host outside the server; it opens exactly one TCP connection and prints the result. Three outcomes mean three different things: 'succeeded' means the path and the firewall are fine and the problem is elsewhere; 'connection refused' means the packet reached the host but nothing was listening on that port; a hang that ends in a timeout is the classic signature of a packet filter silently dropping the traffic. Only that last case points at the firewall.

The fastest way to answer 'is the firewall blocking me?' — netcat in scan mode attempts one TCP connection and prints whether it succeeded.

Command
$ nc -zv example.com 443

Inspect the firewalld ruleset

This dumps the active zone's services, open ports and rich rules in one go — the firewalld equivalent of reading the whole ruleset. If the port you need is neither in the ports list nor covered by a service or rich rule, the firewall is dropping it. Also note which zone is active and which zone the interface belongs to, because a rule added to the wrong zone will never match the inbound traffic.

One command to dump the default zone's services, open ports, and rich rules — the firewalld equivalent of a ruleset view.

Command
$ sudo firewall-cmd --list-all

Check whether packets reach the host at all

Only needed if the netcat probe timed out and you want proof. Capture on any interface with a filter for the port while a client retries. If you see repeated SYNs and no reply from the server, something on the host is dropping them — almost always the firewall. If you see a SYN answered with a RST, the packet got through and was actively refused, so the service or its bind address is the culprit, not the firewall.

LinuxCapture traffic on a port with tcpdumpMedium riskStep 4Optional

Sniff packets on any interface with a BPF filter — the fastest way to prove whether traffic is even reaching your server.

Command
$ sudo tcpdump -i any -nn port 443

Open the port permanently in firewalld

Use this on Fedora, RHEL and CentOS hosts. The permanent flag writes the rule into the stored configuration and the reload applies it right away, so the port stays open across reboots — a temporary rule would silently disappear next boot. Match the protocol to the service (TCP for HTTP-style apps, UDP for game and DNS-style traffic). Afterwards the port should show up in the allowed ports of the active zone.

Permanently allow a TCP or UDP port through firewalld on Fedora, RHEL, or CentOS so your web app or game server is reachable.

Command
$ sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload
▾ Undo
Undo
$ sudo firewall-cmd --permanent --remove-port=8080/tcp && sudo firewall-cmd --reload

On Ubuntu or Debian, add the rule with ufw

If the host runs ufw instead of firewalld, the firewalld command has no effect and this is the correct fix. Add a rule for the port and protocol you need; the delete form removes it again. Order matters when you are still setting the host up: allow your SSH port before you enable ufw, otherwise enabling the firewall cuts your own remote session immediately.

LinuxAllow a port through the firewall with ufwHigh riskStep 6Optional

Add a UFW rule to permit inbound traffic on a TCP or UDP port, such as SSH on port 22.

Command
$ sudo ufw allow 22/tcp
▾ Undo
Undo
$ sudo ufw delete allow 22/tcp

Verify from outside with a port scan

Run the scan from a host outside the server, not from the server itself — a scan from localhost bypasses most filtering and proves nothing. The port should now appear open and report the expected service version, which confirms the rule is live for remote traffic. If it is still closed, re-check that the rule landed in the zone that owns the inbound interface, and that the permanent change was actually reloaded.

Enumerate every open port and running service version on a machine you administer.

Command
$ nmap -sV -p- 192.168.1.10
!Opening a port exposes the service to every host that can route to it, so open only what you need and restrict source addresses where you can. Keep a second SSH session open while editing firewall rules: a typo, a rule added to the wrong zone, or allowing SSH only after enabling the firewall can lock you out of the machine.

How to confirm it worked

From an outside host, a netcat probe succeeds and a port scan shows the port open with the expected service banner. On the server, the port now appears among the allowed ports of the active firewall zone.

Undo everything

Every command above can be reverted. Run these in order to undo all of it.

Undo everything
$ sudo ufw delete allow 22/tcp
sudo firewall-cmd --permanent --remove-port=8080/tcp && sudo firewall-cmd --reload

Review before running — some steps may not be independent.

Sources

Last verified: 2026-09-22

Related guides