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.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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

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.

1. 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.

2. 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.

3. 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.

4. Allow a TCP port in the active zone immediately.

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

5. Allow a UDP port in the same zone if the application expects UDP traffic.

   $ sudo firewall-cmd --zone=public --add-port=1194/udp
   success

6. 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.

7. 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.

8. 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

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

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.

1. 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.

2. Open the persistent nftables configuration.

   $ sudo vi /etc/nftables.conf

3. 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.

4. 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.

5. 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
   	}
   }

6. 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

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.

1. 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))

   Related: How to check if a Linux service is listening on a port

2. 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.