Linux firewalls control which network traffic a machine accepts, sends or forwards. UFW, firewalld and nftables approach that job differently: UFW favours straightforward host rules, firewalld organises access around zones and services, and native nftables gives administrators direct control over the underlying ruleset.
The right choice depends less on which tool has the longest feature list and more on who will maintain the policy. A small web server needs different administration from a gateway with several networks. If you are setting up your first Linux server, start with the firewall manager your distribution supports, then build a policy you can explain, test and restore.
How UFW, firewalld and nftables fit together
These tools do not represent three independent security barriers. Linux performs packet filtering inside the kernel through its Netfilter infrastructure. Userspace tools create and manage the rules that the kernel evaluates.
The distinction matters because a friendly interface can still use nftables underneath. UFW manages rules through the iptables and ip6tables interfaces; on Ubuntu, those interfaces can use the nftables compatibility backend. That does not make UFW a native nftables configuration manager. Ubuntu’s documentation on nftables and firewall management warns against combining UFW with independently managed native nftables rules.
| Tool | Administration model | Good fit | Main responsibility |
|---|---|---|---|
| UFW | Readable rules for ports, protocols, addresses and interfaces | A host with a modest service list | Keep exceptions narrow and inspect what profiles permit |
| firewalld | Zones, service definitions and traffic policies | Systems with different network trust boundaries | Check zone assignments and runtime versus permanent settings |
| Native nftables | Explicit tables, chains, rules and sets | Custom filtering, gateways and centrally managed policies | Own rule structure, deployment, persistence and recovery |
Choose one primary owner for the host firewall policy. Do not treat installing several firewall managers as defence in depth. Their interaction needs deliberate design, especially when container or virtual machine software also manages networking.
A firewall is also only one part of server security. Keep security updates and automatic patching in place rather than treating blocked ports as permission to leave services unmaintained.
Understand the traffic path before writing rules
Three traffic directions explain most host firewall decisions. Input is traffic delivered to the Linux machine itself. Output is traffic generated by local processes. Forwarded traffic passes through the machine on its way elsewhere. The Netfilter packet processing hooks separate these paths.
An SSH connection to the host belongs to its input path. A package download starts as host output. Traffic crossing a Linux gateway belongs to forwarding. Container networking can introduce forwarding too, so an input policy alone is not a complete description of a container host’s exposure.
Stateful filtering adds connection context. A policy can permit a connection initiated by the server and allow its reply traffic without allowing arbitrary new inbound connections. This is why “deny unsolicited incoming traffic” does not normally mean “break every download”. Established and related traffic still needs appropriate treatment in the ruleset.
Write the intended access in plain English before translating it into firewall settings: which service, which protocol, which destination and which clients? “Allow administration from the management network” is a useful requirement. “Open port 22” leaves the source boundary unstated. Pair network restrictions with SSH keys and access controls; a permitted network connection is not an authenticated administrator.
UFW: straightforward host firewall management
UFW stands for Uncomplicated Firewall. Its interface suits a machine whose policy can be expressed as a short collection of rules: permit administration from approved addresses, permit public web traffic, and refuse other unsolicited connections.
The packaged installation defaults documented in the Ubuntu UFW manual deny incoming and forwarded traffic and allow outgoing traffic, but UFW starts disabled. Those installation defaults do not prove the state of an existing server. Images, provisioning tools and earlier administrators may have changed it.
UFW rules can include source addresses, destination addresses, interfaces and protocols. Use those controls to express the actual requirement. If a monitoring service should accept connections only from one monitoring server, do not grant the entire local network access just because the wider rule is easier to remember.
Application profiles provide named collections of ports and protocols. Inspect a profile before allowing it: a profile covering both HTTP and HTTPS grants more access than one covering HTTPS alone. A profile is a firewall definition, not a process supervisor or an application permission system.
UFW also provides numbered rule views and logging controls. Its ordinary status display shows UFW managed user rules rather than every detail of the complete filtering configuration. That distinction becomes relevant when investigating rules outside the usual interface.
For a small server, favour a short, documented policy over a growing pile of exceptions. Review old permissions when removing software. A rule that once supported a temporary dashboard should not remain indefinitely simply because nothing currently listens on that port.
firewalld: zones, services and separate configuration states
firewalld is a running management service that organises firewall policy around network context. Its documented default backend is nftables, although administrators should verify the configuration of the installed system rather than infer it from the distribution name. The backend setting is defined in the firewalld configuration manual.
Zones describe access boundaries
A zone groups traffic under a shared policy. Interfaces and source addresses can be associated with zones, allowing a machine to apply different permissions to different networks. Service definitions collect the ports and protocols needed for named services. The relationship between zones, services and their configuration is covered in Red Hat’s firewalld administration documentation.
Consider a server with a public interface and a private management interface. The intended policy might permit HTTPS through the public interface and administration through the management interface. Before adding either permission, check where the traffic is actually classified. A correct service allowance in the wrong zone does not implement the intended boundary.
Do not use a zone’s name as evidence of safety. Inspect its allowed services, ports, sources, interfaces and target. For network connections controlled by NetworkManager, include the connection’s zone assignment in the review rather than examining firewalld alone.
Also distinguish permission to reach the host from permission to pass through it. A gateway needs an explicit forwarding design. Do not assume that putting interfaces into differently named zones fully describes every permitted traffic path.
Runtime changes are not automatically permanent
firewalld maintains separate runtime and permanent configurations. Runtime settings govern the active firewall. Permanent settings supply the configuration loaded at startup or reload. An unsaved runtime change disappears on reload; changing permanent configuration alone does not immediately alter the running policy. These behaviours are documented in the firewalld configuration concepts.
This separation supports a useful workflow: test a change in runtime, verify the required connections, then persist the approved result. Alternatively, prepare the permanent configuration and activate it during a planned change. Whichever method you choose, record it so another administrator knows which state is authoritative.
Review before copying runtime settings into permanent storage. Otherwise, a temporary troubleshooting exception can become part of the saved policy. Equally, check the permanent state before reloading: a reload is not a universal undo button if the saved configuration has already changed.
nftables: direct control over the filtering policy
Native nftables configuration gives you direct responsibility for the ruleset rather than expressing policy through UFW or firewalld. The userspace utility is named nft; nftables refers to the filtering framework and commonly to its configuration approach.
Tables organise objects, chains contain rules, and base chains attach processing to network hooks. Rules evaluate matching conditions and perform actions. Named sets let rules refer to collections of addresses or ports without repeating a separate rule for every member.
The inet address family can handle IPv4 and IPv6 in shared tables, although address matches still need the appropriate family. Rule evaluation also requires care: acceptance in one base chain does not prevent another applicable chain from dropping the packet. The official nftables reference manual defines these structures and verdict semantics.
That control suits an administrator maintaining several address groups, routing boundaries or reusable policy components. It also creates more decisions. A ruleset needs clear organisation, explicit defaults and comments that explain intent. A table called “filter” does not, by its name alone, attach anything to the packet path.
Atomic deployment does not validate your intent
nftables supports loading a batch of configuration changes atomically, avoiding a partially applied sequence of individual updates. The nftables documentation on atomic rule replacement describes this deployment model.
Atomicity is not protection against a mistaken policy. A perfectly valid batch can remove administration access just as completely as an invalid change can fail to load. Check configuration validity, review the access logic and keep a tested recovery route.
Persistence needs separate attention. Confirm which configuration file or generated policy your distribution loads, which service loads it, and what happens during startup. The guide to managing Linux services with systemd covers service activation and boot behaviour. Rules present in the kernel now are not proof that the same rules will return after a reboot.
Build the policy around the server’s actual job
For a conventional host, a sensible starting design is to refuse unsolicited inbound connections while allowing only documented services and necessary network control traffic. Treat forwarding separately. Decide on outbound restrictions from the machine’s requirements, not from a desire to make every policy default read “deny”.
Public web server
Suppose the server provides a website through Nginx. The proposed policy might allow public HTTPS, allow HTTP only where the deployment requires it, and restrict administration to an approved network or VPN. A database used only by the local application should not receive a public firewall exception. Coordinate the policy with the application’s listening addresses and your Nginx and HTTPS configuration.
Be precise about protocols. A TCP permission does not grant UDP access on the same port number. If a deployment uses an additional transport, document and test it rather than opening both protocols automatically.
Private service or backup host
A private service should have a named audience. That might be an application subnet, a management network or a short list of clients. Avoid treating every private address as trusted. A network can contain guests, compromised machines and services with no reason to reach one another.
Outbound filtering deserves a dependency inventory. Include name resolution, time synchronisation, package repositories, monitoring and backup destinations where required. Before tightening egress, check that offsite backups and recovery tests will still work. Test an actual backup operation, not just whether its management page opens.
Apply firewall changes without losing remote access
A remote firewall change should have a recovery plan before it has an activation time. Keep a working console or provider recovery channel available. A backup configuration is useful only if you have a way to restore it when the network path fails.
- Record the current state. Identify the active manager, existing rules, listening services, interface addresses and any upstream filtering.
- Confirm the administration path. Record the server port, client source address and interface involved. Account for VPNs, jump hosts and address translation.
- Prepare the required allowance. Put the intended administration permission in place before activating restrictive defaults. Enabling UFW can affect existing connections, so do not rely on the current session surviving.
- Test a fresh connection. Keep the original session open where possible, then connect again through the intended path. Test both permitted and prohibited access.
- Verify persistence. Check the saved policy and perform a controlled reload or reboot test when recovery access and a maintenance window are available.
Use a tested rollback mechanism for changes that could cut off access. If rollback is scheduled, confirm that it can restore the previous working configuration without depending on the connection being changed. Cancel it only after the replacement policy passes its checks.
Restrict who can modify firewall configuration. Give administrators the permissions they need through a deliberate users, groups and sudo policy, and record the purpose of changes. A brief note such as “permit monitoring from the collector” is more useful than “temporary fix”, especially six months later.
IPv6 needs an explicit review
Do not stop testing after IPv4 works. Check whether the host has usable IPv6 addresses, whether services listen on them, and whether the intended restrictions apply to that path too. A hostname may lead clients to either address family.
Shared inet tables can reduce duplicated policy, but they do not make every IPv4 address condition meaningful for IPv6. Address based administration permissions need a deliberate decision for each family in use.
Do not block all ICMPv6 in an attempt to make the server less visible. IPv6 depends on control messages for functions including neighbour discovery and reporting packets that are too large for a path. RFC 4890’s ICMPv6 filtering recommendations distinguish necessary network operation from traffic that can be filtered. Breaking connectivity is not a useful form of hardening.
Containers and virtual machines change the exposure check
A container host needs more than a review of ordinary host input rules. Docker creates firewall rules for bridge networking, port publishing and isolation. Published container traffic can be diverted before reaching the host input rules UFW normally manages. Docker’s packet filtering and firewall documentation describes this interaction and its integration with firewalld.
Do not assume that a UFW deny rule protects every published container port. Inspect the actual publication, the listening address and the forwarding path, then test from another machine. Do not disable Docker’s firewall management as a quick repair; its networking relies on those rules unless you supply a suitable replacement design.
Keep the intended network audience explicit in your Docker or Podman setup. An application needed only by another container may not need a host published port at all. Check the networking mode and behaviour of the runtime you actually use rather than transferring Docker assumptions to every container system.
Apply the same reasoning to KVM and QEMU virtual machines. Determine whether traffic reaches the host, is routed through it, or reaches a guest through a bridge. Include guest firewall policy in the review instead of assuming host input filtering covers every arrangement.
Troubleshoot the connection, not just the firewall status
“Firewall active” confirms very little about whether a service is reachable. Work through the connection path and gather evidence before broadening a rule.
Check the service and destination
Confirm that the application is running and listening on the expected address, port and protocol. Check that the client uses the intended destination. A service bound only to loopback should not be repaired by opening the firewall more widely.
Separate connection establishment from application behaviour. If a connection succeeds but authentication fails, inspect the service logs and credentials. If HTTPS connects but the wrong site responds, investigate the web server configuration. Use journalctl for service troubleshooting rather than treating every error as a dropped packet.
Inspect the applicable policy
With UFW, review rule scope and order, not just the existence of an allow entry. With firewalld, inspect the zone handling the traffic and compare runtime with permanent settings. With native nftables, follow the applicable chains and their verdicts. Include rules managed by container or virtualisation software where relevant.
Use counters and targeted logging to narrow the fault. Record the test time, client address, destination and protocol so the event can be matched to evidence. Avoid leaving verbose packet logging enabled without checking its volume and retention; include log storage in routine CPU, memory, disk and network monitoring.
Test from the right place
A local connection does not reproduce the path taken by a remote client. Test from an authorised network and, where appropriate, from a network that should be blocked. Include IPv4 and IPv6 when both are in use.
Also inspect upstream controls such as a router firewall or cloud security policy. Host and network filtering should support the same access design, but success or failure at one layer does not establish what happened at another. Avoid disabling the entire firewall as your first diagnostic step.
Choose the tool you can maintain reliably
Choose UFW when the host policy is short and its readable rules meet the requirement. Choose firewalld when zones, named services and network context make the policy easier to administer. Choose native nftables when direct rule ownership provides a clear benefit and you can maintain its deployment and recovery process.
For an existing system, preserve a working management approach unless there is a reason to replace it. Migration should begin with an inventory of required access, not a translation of every old exception. Some rules deserve retirement rather than a new syntax.
The useful result is a policy with a clear owner, narrow permissions, verified traffic paths and a known recovery method. Whatever interface you choose, test what the machine actually accepts—and check again after changes that affect networking.