UFW App Profile Missing? It Describes Ports, Not Services

UFW says it cannot find a profile matching OpenSSH, and the search for a cause goes straight to the SSH server. That is the wrong direction: the message is about a named firewall definition, and it says nothing about whether sshd is installed, running or listening. A UFW application profile is a list of ports and protocols with a label on it. Reading the definition takes one command and usually ends the investigation.

Step 1: list the names UFW actually knows

Ask the firewall which names it has before you ask it to allow one. The list comes from the profiles installed on this machine, so a missing name is a fact about this system rather than about the software you were trying to protect. If the name is present, the error came from a typo or a stale alias in your shell history.

ufw app list
ufw app info OpenSSH

The list is short on a default install, and the names are not package names. A profile called OpenSSH can be absent while the openssh-server package is installed, and the reverse is possible too. Use the exact name the list prints; a VPN profile name or a desktop launcher with similar spelling is not a UFW application profile. If the name you want is missing, that is the finding, and the next step is to look at what should supply it.

Step 2: read the definition, not the label

A profile is an INI-style file under /etc/ufw/applications.d, with a name, a title, a description and a ports field. The ports field can list several ports and transports, so the label tells you less than the definition does. The UFW manual documents these fields and the application-update operation. Read the file rather than assuming the name means one familiar port.

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

A definition containing 22/tcp describes TCP port 22 and nothing else. It does not prove that the daemon on this machine listens there, and it does not cover a second port you added later. If the daemon runs elsewhere, the profile is the wrong permission even though its name matches the product. Compare the listener with the definition before you allow either of them.

ss -ltnp 'sport = :22'

Stop if the definition and the listener disagree. Allowing a profile that names a port nobody listens on creates a rule that looks like progress and protects nothing.

Step 3: separate the profile from the running service

Allowing a named profile does not install, start or configure the service, and a running service does not need a packaged profile to be reachable. Those are separate decisions owned by different tools: the package manager, the service manager and the firewall. Treating them as one is how people install an unwanted server to make a symbolic name appear.

For a VPN server the separation continues after the outer listener is allowed. Permission for the encrypted transport port does not enable kernel forwarding, does not add a NAT rule and does not grant tunnel users access to a LAN. Each of those is a separate policy with its own review. A profile named after the VPN product describes only the ports it lists, and the rest of the server configuration is still yours to write.

If the profile is missing and you need one, a reviewed explicit port rule or a local profile under applications.d are both legitimate. Installing a package you did not want is not.

Step 4: keep a way back before you reload the firewall

Before any rule change, confirm you have a second way into the machine: a console, an out-of-band address or a scheduled rollback. Then read the rule set and the default policy, because a default deny with no SSH rule is the classic way to lock yourself out while testing. Change one rule at a time and read the confirmation UFW prints. A saved rule, an active rule and a reachable service are three different observations.

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

After the change, test the permitted connection and one path that should still be denied. The denied test matters as much as the allowed one, because a rule wider than intended passes the first test and fails the second. Record the profile name, the ports it contained and the listener you verified against.

The checklist ends when the name exists or is deliberately replaced, the definition matches the real listener, the service is managed separately, and you have tested both an allowed and a denied path with a recovery route in hand. A name in the list is not any of those things.