How to Install UFW on Arch Linux

UFW gives Arch users a simpler way to manage netfilter firewall rules when direct iptables or nftables syntax is more than the job needs. To install UFW on Arch Linux, use the official ufw package from Arch’s extra repository, then set default policies and allow any inbound services before turning the firewall on.

On current Arch systems, UFW still depends on the iptables command, and updated hosts commonly report the nf_tables backend through that command. Keep the package installed, but do not run iptables.service, ip6tables.service, or nftables.service at the same time as ufw.service.

Install UFW on Arch Linux

UFW is available in Arch’s official repositories, so a normal Pacman install is the right path for most systems. The Arch package database entry for ufw lists the package in extra, and the Arch Wiki UFW page covers Arch-specific service notes.

Update Arch Linux Before Installing UFW

Refresh package metadata and apply pending upgrades before adding UFW:

sudo pacman -Syu

These commands use sudo for tasks that need root privileges. If your user is not in the sudoers file yet, run the commands as root or follow the guide on how to add and manage sudo users on Arch Linux.

Install UFW with Pacman

Install the official UFW package:

sudo pacman -S ufw

Pacman installs the ufw command and the ufw.service systemd unit. UFW is installed at this point, but it is not enforcing rules until you enable it later.

Verify the UFW Package and Backend

Confirm the installed package, binary ownership, and active iptables backend:

pacman -Q ufw
command -v ufw
pacman -Qo /usr/bin/ufw
ufw version
iptables --version

Relevant output currently includes:

ufw 0.36.2-7
/usr/bin/ufw
/usr/bin/ufw is owned by ufw 0.36.2-7
ufw 0.36.2
Copyright 2008-2023 Canonical Ltd.
iptables v1.8.13 (nf_tables)

The nf_tables line means the installed iptables command is using the nftables backend. That is normal on an updated Arch host and does not require separate UFW commands.

Configure UFW Before Activation

Set your baseline rules before you activate the firewall. Remote systems need an SSH allow or limit rule first, while a local desktop can often start with only the default deny-incoming policy.

Set UFW Default Policies

The usual baseline denies unsolicited incoming traffic and allows outgoing connections:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Expected output:

Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

For a desktop or programming workstation, this baseline is often enough until another device must connect to a local service. Open only the ports you actually need, such as SSH, HTTP, HTTPS, a local development server, or a LAN-only database listener.

Allow or Limit SSH Access

Allow SSH before enabling UFW on a remote machine. Enabling the firewall without an SSH rule can drop your current session and require local console access.

If you have not configured the SSH server yet, finish installing OpenSSH on Arch Linux before enabling the firewall. For default SSH on port 22, use UFW’s rate-limited SSH rule:

sudo ufw limit ssh

Expected output:

Rules updated
Rules updated (v6)

For a custom SSH port, replace 2222 with your real SSH port and keep the protocol explicit:

sudo ufw limit 2222/tcp

Use sudo ufw allow 2222/tcp instead if you need a plain allow rule without UFW’s connection-rate limit.

Preview UFW Rules Before Enabling

Check the rules staged for activation:

sudo ufw show added

After the rate-limited SSH rule, relevant output includes:

Added user rules (see 'ufw status' for running firewall):
ufw limit 22

If this output is empty or does not include your remote access port, add the missing rule before continuing.

Enable UFW and Verify the Service

Enable UFW after the default policies and access rules are in place:

sudo ufw enable

UFW asks for confirmation because the change can affect active SSH sessions:

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Enable the systemd unit so Arch starts UFW during boot:

sudo systemctl enable --now ufw.service

Verify both the service state and the active firewall policy:

systemctl is-enabled ufw.service
systemctl is-active ufw.service
sudo ufw status verbose

Relevant output includes:

enabled
active
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         LIMIT IN    Anywhere
22 (v6)                    LIMIT IN    Anywhere (v6)

If systemctl status ufw.service shows active (exited), that is normal. UFW applies firewall rules and exits instead of running as a long-lived daemon.

Do not enable iptables.service, ip6tables.service, nftables.service, or another firewall manager beside ufw.service. UFW still needs the iptables package, but standalone systemd rule loaders can conflict with UFW-owned rules.

Manage UFW Rules on Arch Linux

Use UFW rules to open only the services that should accept inbound connections. Re-check the numbered status after every delete operation because UFW renumbers rules immediately.

View Active UFW Rules

sudo ufw status numbered

Example output:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         LIMIT IN    Anywhere
[ 2] 22 (v6)                    LIMIT IN    Anywhere (v6)

Allow HTTP and HTTPS

For a web server, allow HTTP and HTTPS by service name:

sudo ufw allow http
sudo ufw allow https

Port numbers work as well and make the protocol explicit:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Allow Port Ranges

When an application needs consecutive ports, include the protocol:

sudo ufw allow 8000:8005/tcp

This permits TCP traffic on ports 8000 through 8005. Avoid broad ranges for development tools unless another host on the network really needs access.

Restrict Access by Source Address

Limit a rule to a trusted subnet or host when only known systems should connect:

sudo ufw allow from 192.168.1.0/24

For a specific host and port, combine the source address with the destination port:

sudo ufw allow from 203.0.113.4 to any port 22 proto tcp

This pattern is safer for SSH, databases, and administration panels than opening the same port to every address.

Restrict Access by Network Interface

On systems with multiple network interfaces, bind a rule to the interface that should receive traffic:

sudo ufw allow in on eth0 to any port 80 proto tcp

Replace eth0 with the interface name shown by ip link.

Deny Specific Connections

Default deny incoming already blocks unmatched traffic, but explicit deny rules are useful for named ports or source addresses you want to document in the rule list:

sudo ufw deny 23/tcp
sudo ufw deny from 203.13.56.121
sudo ufw deny from 203.13.56.0/24

Delete UFW Rules

Delete by number after listing the active rules:

sudo ufw status numbered
sudo ufw delete 3

UFW asks for confirmation:

Deleting:
 allow 443
Proceed with operation (y|n)? y
Rule deleted

You can also delete by repeating the original rule instead of using a number:

sudo ufw delete allow 443/tcp

After deleting by number, run sudo ufw status numbered again before deleting another rule. Rule numbers shift as soon as a rule is removed.

Manage UFW Application Profiles

UFW application profiles group common ports behind names such as SSH, WWW, and Deluge. Arch’s UFW package includes several default profiles, but not every Arch package installs its own UFW profile.

List UFW Application Profiles

sudo ufw app list

Relevant output includes:

Available applications:
  DNS
  Deluge
  SSH
  Telnet
  WWW
  WWW Full
  WWW Secure
  qBittorrent
  svnserve

Inspect a UFW Application Profile

sudo ufw app info SSH

Expected output:

Profile: SSH
Title: SSH server
Description: SSH server

Port:
  22/tcp

Allow a profile when the profile name matches the service you actually run:

sudo ufw allow "WWW Full"

Create Custom UFW Application Profiles

Custom profiles belong in separate files under /etc/ufw/applications.d/. Do not edit package-provided profile files, because package updates can replace them.

sudo nano /etc/ufw/applications.d/myapp

Add a profile in this format:

[MyApp]
title=My Application
description=Custom application on ports 9000-9005
ports=9000:9005/tcp

Save the file, then verify that UFW can read the profile:

sudo ufw app list | grep MyApp

Check IPv6, Logging, and Backend Behavior

These checks help confirm how UFW is applying rules on a current Arch system.

Verify UFW IPv6 Handling

Arch’s UFW configuration enables IPv6 rule generation by default:

grep '^IPV6=' /etc/default/ufw

Expected output:

IPV6=yes

If you intentionally change this setting, reload UFW afterward:

sudo ufw reload

Confirm the iptables and nftables Boundary

Use the backend check when you are unsure whether UFW is working through legacy iptables or the nftables-backed iptables interface:

iptables --version
nft --version

On an updated Arch host, relevant output can include:

iptables v1.8.13 (nf_tables)
nftables v1.1.6 (Commodore Bullmoose #7)

Do not remove the iptables package just because the backend is nf_tables. UFW depends on the command interface even when nftables owns the kernel-side rule backend.

Enable UFW Logging

Set a logging level when you need firewall events for troubleshooting or audits:

sudo ufw logging medium

Expected output:

Logging enabled

Level	What It Logs
low	Blocked packets
medium	Blocked packets and new connections
high	More packet detail, including rate-limited traffic
full	Verbose firewall logging for short troubleshooting windows

On Arch with systemd, read UFW log entries from the kernel journal. Use grep for a quick filter or the tail command when you need broader log-following examples.

sudo journalctl -k | grep UFW

A blocked packet line commonly includes fields such as SRC, DPT, and PROTO. Treat the interface name, source address, destination port, and protocol as the stable parts to inspect; timestamps, MAC addresses, and packet IDs vary by host.

Disable UFW logging when you no longer need it:

sudo ufw logging off

Install GUFW on Arch Linux

GUFW is also available from Arch’s extra repository. It provides a GTK interface for desktop users who prefer managing UFW rules through a graphical tool.

sudo pacman -S gufw

Launch GUFW from your application menu or from a terminal with:

gufw

GUFW depends on the same UFW backend. Any rules you create in the graphical interface still affect the system firewall, so review them with sudo ufw status numbered before deleting or replacing rules from the terminal.

Handle Docker and Other Firewall Managers

UFW should be the only firewall manager controlling the host rules. If you plan to switch to Firewalld on Arch Linux, disable UFW first rather than running both managers together.

Docker needs a separate caution. Docker can add its own firewall rules for published container ports, so sudo ufw status may not fully describe which container ports are reachable. If you use Docker on Arch Linux with UFW, test container exposure from another host after changing either Docker or UFW rules.

For Docker-specific integration, the ufw-docker package is in the AUR, not the official Arch repositories. Review the PKGBUILD, the upstream ufw-docker project, and your Docker network layout before using it on a server, because it edits UFW’s rule files to account for Docker’s own networking rules.

Reset, Disable, or Remove UFW

Disabling UFW keeps your rule files in place. Resetting UFW removes custom rules and restores installed defaults. Removing the package is best reserved for systems moving to another firewall manager.

Disable UFW Temporarily

sudo ufw disable

Expected output:

Firewall stopped and disabled on system startup

Re-enable the same rules later with sudo ufw enable.

Reset UFW Rules

Resetting UFW removes current allow, deny, and limit rules, including SSH access. Use local console access or another confirmed recovery path before resetting a remote server.

sudo ufw reset

UFW backs up rule files such as before.rules before restoring installed defaults:

Resetting all rules to installed defaults. This may disrupt existing ssh
connections. Proceed with operation (y|n)? y
Backing up 'user.rules' to '/etc/ufw/user.rules.20260508_191131'
Backing up 'before.rules' to '/etc/ufw/before.rules.20260508_191131'
Backing up 'after.rules' to '/etc/ufw/after.rules.20260508_191131'
Backing up 'user6.rules' to '/etc/ufw/user6.rules.20260508_191131'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20260508_191131'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20260508_191131'

If you manually edited /etc/ufw/before.rules, a reset backs up that file but does not keep the edits active. Reapply only the rules you still need, or move application-specific port definitions into a separate file under /etc/ufw/applications.d/.

Remove UFW from Arch Linux

Disable UFW and its service first:

sudo ufw disable
sudo systemctl disable --now ufw.service

If you installed GUFW, remove it before removing UFW because gufw depends on ufw:

sudo pacman -Rns gufw

Remove UFW:

sudo pacman -Rns ufw

Confirm that the package and command are gone:

pacman -Q ufw
hash -r
command -v ufw || echo "ufw removed from PATH"

Expected output after removal:

error: package 'ufw' was not found
ufw removed from PATH

Pacman can leave generated backups or local rule files under /etc/ufw/. Remove that directory only when you are certain you no longer need custom firewall rules, application profiles, or reset backups:

sudo rm -rf /etc/ufw/

Removing UFW leaves the host without this firewall policy. Configure an alternative such as nftables, iptables rules, or Firewalld before depending on network exposure from that system.

Troubleshoot UFW on Arch Linux

UFW Service Active but Firewall Inactive

The systemd unit can be enabled while UFW’s rule set is still inactive. Check both states:

systemctl is-active ufw.service
sudo ufw status

If the service is active but UFW reports Status: inactive, enable the firewall rules:

sudo ufw enable

UFW Does Not Start at Boot

Enable the systemd unit and check the simple service state first:

sudo systemctl enable --now ufw.service
systemctl is-enabled ufw.service
systemctl is-active ufw.service

Expected output:

enabled
active

If the service still fails, inspect the unit logs:

sudo journalctl -xeu ufw.service

UFW Rules Do Not Affect Traffic

First confirm UFW is active, then inspect rule order:

sudo ufw status verbose
sudo ufw status numbered

UFW processes rules by order. If a broad deny rule appears before a specific allow rule, delete and recreate the affected rules in the right order. If the traffic belongs to Docker, check Docker’s published-port rules separately because Docker can bypass normal UFW assumptions.

Remote SSH Locked Out After Enabling UFW

Recover from local console access, then add the SSH rule before turning UFW back on:

sudo ufw disable
sudo ufw limit ssh
sudo ufw enable

For a non-default SSH port, use the matching custom-port rule instead of sudo ufw limit ssh.

Conclusion

UFW on Arch Linux works well when the setup order is deliberate: update the system, install the official package, set a deny-incoming baseline, protect SSH before activation, and keep ufw.service as the only active firewall manager. For stronger login protection after the firewall is in place, pair the host with Fail2Ban on Arch Linux and keep exposed services limited to the exact addresses and ports they need.