How to allow a port through the firewall in Linux

Allowing the right port through a Linux host firewall lets network traffic reach a listening service without exposing more of the machine than necessary. This is the step that turns a locally running web server, VPN daemon, database listener, or custom application into a reachable network service.

Modern Linux systems usually manage packet filtering through one of three layers: ufw on many Debian and Ubuntu hosts, firewalld on RHEL, CentOS Stream, Fedora, Rocky Linux, and AlmaLinux systems, or direct nftables rules on leaner or more customized installations. The command syntax differs, but the success state is the same in each case: the intended port and protocol appear in the active rules, and the service bound to that port becomes reachable.

Firewall changes require root access and should be applied carefully on remote systems, especially when the same host depends on SSH, a VPN tunnel, or another management path for recovery. Use only one firewall manager on a host at a time, and if the port should stay open after a reboot, make sure the rule is saved in persistent configuration instead of existing only in runtime state.

Methods to allow a port through the firewall in Linux:

Allow a port with ufw
Allow a port with firewalld
Allow a port with direct nftables rules

Steps to allow a port through the firewall in Linux:

Allow a port with ufw

Use this method on systems where ufw is the active firewall manager, which is common on Ubuntu and other Debian-derived hosts. A ufw allow rule is stored immediately and, when ufw is active, takes effect at once; it is also kept across reboots, so the main risk is enabling the firewall on a remote host before the management port is allowed.

Check the current ufw state before changing rules.
```
$ sudo ufw status verbose
Status: inactive
```
If ufw reports Status: inactive, you can still add the rule first and activate it safely in the next step.
Allow the remote management port before enabling ufw on a server, typically 22/tcp for SSH.
```
$ sudo ufw allow 22/tcp
Rules updated
Rules updated (v6)
```
Enabling ufw without an existing SSH allow rule can cut off remote access to the host.
Enable ufw if it is not already active.
```
$ sudo ufw --force enable
Firewall is active and enabled on system startup
```
Use this only once per host. If ufw is already active, continue to the port-specific allow rules.
Allow a TCP port, replacing 8080 with the service port the application actually listens on.
```
$ sudo ufw allow 8080/tcp
Rule added
Rule added (v6)
```
Use /tcp for HTTP, HTTPS, SSH, databases, and most application listeners that use TCP sessions.
Allow a UDP port when the service uses datagrams instead of TCP, replacing 1194 with the real UDP port.
```
$ sudo ufw allow 1194/udp
Rule added
Rule added (v6)
```
VPN and streaming protocols often use UDP, so the protocol must match the application.

Confirm that the new rules are present.

$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 8080/tcp                   ALLOW IN    Anywhere
[ 3] 1194/udp                   ALLOW IN    Anywhere
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 5] 8080/tcp (v6)              ALLOW IN    Anywhere (v6)
[ 6] 1194/udp (v6)              ALLOW IN    Anywhere (v6)

Use the numbered view when you need to inspect rule order or delete a specific entry later.

Remove a ufw rule that no longer needs to be exposed.
```
$ sudo ufw delete allow 8080/tcp
Rule deleted
Rule deleted (v6)
```
Related: How to remove a firewall port allow rule in Linux

Allow a port with firewalld

Use this method on RHEL, CentOS Stream, Fedora, Rocky Linux, AlmaLinux, and other hosts where firewalld manages zones. The important detail is the zone attached to the interface that receives the traffic, because the allow rule must be added to that zone instead of to a guessed default.

Confirm that firewalld is running.
```
$ sudo firewall-cmd --state
running
```
If the command reports not running, start the daemon first with sudo systemctl enable --now firewalld and then recheck the state.
Identify the active zone for the interface that receives the connection.
```
$ sudo firewall-cmd --get-active-zones
public (default)
  interfaces: enp0s5
```
Replace public in the next commands with the zone shown on your host if it is different.

Review the zone before opening new ports.

$ sudo firewall-cmd --list-all
public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: enp0s5
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
##### snipped #####

The services: line shows built-in allowances such as ssh, while the ports: line lists explicit port rules you add yourself.

Allow a TCP port in the active zone immediately.

$ sudo firewall-cmd --zone=public --add-port=8080/tcp
success

Allow a UDP port in the same zone if the application expects UDP traffic.
```
$ sudo firewall-cmd --zone=public --add-port=1194/udp
success
```

Persist the rules across reloads and reboots.

$ sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
success
$ sudo firewall-cmd --permanent --zone=public --add-port=1194/udp
success
$ sudo firewall-cmd --reload
success

Rules added without --permanent exist only in runtime state and disappear on reload or reboot.

Verify the allowed ports in the zone.
```
$ sudo firewall-cmd --zone=public --list-ports
8080/tcp 1194/udp
```
If the port is listed here but clients still cannot connect, check the listening service, the correct zone assignment, and any upstream cloud or network firewall.

Remove an explicit port allow rule when it is no longer needed.

$ sudo firewall-cmd --zone=public --remove-port=8080/tcp
success
$ sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcp
success
$ sudo firewall-cmd --reload
success

Allow a port with direct nftables rules

Use this method only on hosts where nftables is the primary firewall and no higher-level tool such as ufw or firewalld owns the ruleset. Because direct nft changes can be overwritten by those managers, edit the persistent rules file and reload it instead of layering ad hoc commands on top of another firewall service.

Inspect the current ruleset so you know which table and input chain already filter incoming traffic.
```
$ sudo nft list ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ct state established,related accept
		tcp dport 22 accept
	}
}
```
If the ruleset contains chains created by ufw or firewalld, stop here and use that tool instead of editing the nftables backend directly.
Open the persistent nftables configuration.
```
$ sudo vi /etc/nftables.conf
```
Add the new allow rules to the input chain that already accepts loopback, established connections, and required management traffic.
```
table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        iif "lo" accept
        ct state established,related accept
        tcp dport 22 accept
        tcp dport 8080 accept
        udp dport 1194 accept
    }
}
```
Keep existing loopback, established/related, and remote-management rules in place. Replacing the file with a partial snippet can lock you out of the host.
Apply the updated ruleset.
```
$ sudo nft -f /etc/nftables.conf
```
On systems that enable the nftables service, sudo systemctl reload nftables applies the same persisted file through the service manager.

Confirm that the new port rules are active.

$ sudo nft list ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ct state established,related accept
		tcp dport 22 accept
		tcp dport 8080 accept
		udp dport 1194 accept
	}
}

Remove a direct nftables allow rule by deleting the matching line from /etc/nftables.conf and applying the file again.
```
$ sudo nft -f /etc/nftables.conf
```
Direct rule handles can change after reloads, so the persistent file is the stable place to add or remove service ports.

Related: How to remove a firewall port allow rule in Linux

Verify the open port

Allowing the firewall rule does not start the application itself. The service still needs to be listening on the correct address and protocol before another host can reach it.

Confirm that the service is listening on the expected port.

$ sudo ss -ltnup | grep -E ':8080|:1194'
tcp   LISTEN 0      128          0.0.0.0:8080      0.0.0.0:*    users:(("myapp",pid=1842,fd=7))
udp   UNCONN 0      0            0.0.0.0:1194      0.0.0.0:*    users:(("openvpn",pid=2015,fd=6))

Test the port from another system on the expected network path.
```
$ nc -vz server.example.net 8080
Connection to server.example.net 8080 port [tcp/http-alt] succeeded!
```
For UDP services, use a protocol-aware client or the application log instead of relying only on nc. A local loopback test proves the service is listening, while a remote test proves the firewall and the surrounding network path both permit the connection.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.