UFW vs nftables: how to configure the firewall of a Linux VPS
Published on 2026-10-26 by frfrand
Ubuntu access rules, SSH and API ports with least privilege
They ask you which firewall to configure on an Ubuntu VPS: UFW or nftables. They are not exact rivals. UFW is a simple interface for managing rules; nftables is a more flexible filtering infrastructure within Linux.
Let's turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem arises if one part is misconfigured.
What UFW vs nftables means and when you need it
Layers and backends depend on the distribution. What matters is understanding the effective rules and not combining changes without knowing which system manages them. A firewall controls traffic, but it does not fix API permissions or insecure passwords.
Before changing anything in production, note the current state: IP, domain, port, affected service, and time of the last deploy. An isolated change is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
sudo ufw status verbose
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Antes de habilitar reglas: verificar SSH desde otra sesión
sudo ufw enable
# Diagnóstico de reglas nftables
sudo nft list rulesetDomains, IP addresses, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to preserve administrative access.
How I would do it step by step
- Preparation. List really necessary ports: for a website they are usually 80/443 and restricted administrative access.
- Step 2. Confirm that SSH will still be allowed BEFORE activating a remote firewall.
- Step 3. Choose a management mechanism consistent with the system and document it.
- Step 4. Test from outside the authorized ports and confirm that the base remains closed.
- Verification. Review rules after installing Docker or other tools that change the network.
When finished, check the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
A VPS serves three domains via Nginx. It needs to expose HTTPS, not the internal ports of Django, Redis, or PostgreSQL. The firewall limits attack surfaces, while Nginx sends traffic to the correct internal service.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The mistake I would avoid
Activating UFW remotely without allowing SSH can leave you without access. Docker and other tools can introduce rules that alter expected behavior: check effective filtering, not just the panel screen.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to stop errors from showing.
How does it relate to ArduMaker?
In ArduMaker, combining VPS network rules with team and service access prevents accidentally exposing databases. Register which ports belong to each application.
In a typical case, you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. The tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that come up when you try it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how it is verified, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.