Nftables on Linux, check the rules before opening a port

A port may seem closed from the outside, then you end up checking the application or the router. Before changing anything, look at the rules actually loaded by nftables. The file /etc/nftables.conf may differ from the active state, and a local firewall alone does not explain the entire network path.

This method allows you to read the ruleset, identify the chain that handles incoming traffic, and test a modification without losing an SSH session. Keep a second connection open if you are intervening remotely.

Start by reading the loaded firewall

The following command changes nothing. It displays the tables, chains, rules, and any counters currently present in the kernel:

sudo nft list ruleset

If the output is long, first list the tables then target the one that interests you:

sudo nft list tables
sudo nft list table inet filter

The inet family can contain both IPv4 and IPv6 rules. A table may also belong to ip, ip6, bridge, or netdev. Do not replace an IPv6 rule with an IPv4 rule assuming that the problem is solved.

In a filtering table, especially look for a base chain with type filter hook input. This is the one that receives traffic destined for the machine. Its line policy drop means that packets that encounter no accept rules will be dropped.

To see the rule identifiers, useful if you need to remove a specific rule later, add -a:

sudo nft -a list chain inet filter input

Do not confuse input, forward, and output. A server that receives an SSH connection typically uses input. A machine routing traffic to another host may block the packet in forward. An application going out to the Internet passes through output.

Check the port and the order of rules

Rules in a chain are evaluated in order. A drop rule placed before the port allowance wins. Look for the protocol, port, and connection state:

sudo nft list chain inet filter input
sudo ss -lntup

For SSH, an expected rule often looks like tcp dport 22 accept. The port may differ if the daemon is listening elsewhere. The output of ss -lntup allows you to verify that a program is actually listening on the expected port and address. An open firewall does not make a stopped service available.

Also look at the rules ct state established,related accept and the loopback interface iif lo accept. They prevent breaking responses to already established connections and local exchanges. If the ruleset has counters, compare them before and after a connection test to see which rule is seeing the traffic.

A denial may remain outside the machine: cloud security group, router, NAT redirection, VLAN, corporate firewall, or service linked only to 127.0.0.1. From another machine, test the port with nc -vz server_address 22 or with your SSH client. On the server, check for listening with ss before making changes to nftables.

Identify the rule that is really blocking

A chain may call another chain with jump or goto. Therefore, the port authorization may not necessarily be visible in the first chain displayed. Review the chain calls, the named sets, and the rules that have a logging prefix. A rule of type counter drop or reject placed before the port often explains the result.

You can follow a targeted packet with nft monitor trace, but this command produces a lot of data on an active machine. Reserve it for a short diagnostic window and filter the traffic by address or port in a temporary rule. Then remove this rule using the handle displayed by nft -a list ruleset.

Do not leave a wide trace or logging rule on an exposed server. It can fill the logs or add noise to the diagnosis. For an initial check, the counters of the chain and a test from another machine are often sufficient.

The active ruleset and the persistent file may diverge

nft list ruleset reads the active state. It does not say which service loaded the rules, nor which file will be reapplied on reboot. On Debian and Ubuntu, usually check /etc/nftables.conf and the state of the service:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

On a distribution that uses firewalld, UFW, Docker, or a hosting tool, several components may write rules. Do not copy a ruleset seen in a tutorial into /etc/nftables.conf if another service is already managing it. First, identify the manager declared by your machine and read the rules again after its reload.

Rules added via the command line often disappear on the next reboot or the next service reload. Conversely, modifying the persistent file changes nothing until it is loaded. This is precisely why you should check both sides before concluding that a port is open.

Backup and test before applying a rule

Keep the current state before any writing. The backup file should remain readable only by the administrator:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Then prepare the modification in a temporary file. nft -c checks the syntax without loading the rules:

sudo nft -c -f /etc/nftables.conf

This check does not prove that the new ruleset will allow you to enter. Keep a second SSH session connected, apply the file in the first, then attempt a new connection from another terminal. If you lose access, the backup session allows you to restore the backup:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# In case of disconnection or erroneous rule:
sudo nft -f /root/nftables-before-change.nft

Avoid running flush ruleset alone on a remote server. It removes all current rules before you have confirmed the replacement file. Load a complete and verified file, then check the active ruleset immediately afterward.

Checks after modification

Restart sudo nft list ruleset and check that the expected table and chain are still present.
Test the service from another machine using the port actually in use.
Check sudo ss -lntup if the port remains inaccessible.
Check the kernel log with sudo journalctl -k -b if your rules log the dropped packets.
After a reboot, ensure that the nftables service properly reloads the persistent file for your distribution.

For simple cases, the article on UFW on Linux is more appropriate. If you need to diagnose the availability of a service before modifying the firewall, also check open ports with ss. The documentation nft(8) details the families, chains, and the -c option.