Ubuntu 26.04 Tutorial / Restrict Management and Service Access with UFW

Configure UFW after identifying the real management source and service ports. Prepare SSH permissions and console access before enabling it, then test fresh connections from both permitted and denied clients.

Inspect listeners and current rules first

sudo ss -lntup
sudo ss -tn
sudo ufw status verbose
sudo ufw status numbered

Record listener addresses and ports and the actual peer address of your SSH connection. NAT or VPN can change the source observed by the server. If UFW is already active, preserve its policy and rules and add only the required change.

The permitted Linux client in the static IP lab uses 192.168.56.10. Direct management from the Windows host normally originates at 192.168.56.1; substitute that verified source for .10. Compare the server’s ss -tn peer with the client address, and do not use the NAT address or server destination .20 as the source.

Define a baseline for a fresh lab VM

The following baseline assumes a dedicated VM without existing rules, management client 192.168.56.10, and SSH port 22. Substitute verified values. Do not overwrite another system’s established incoming or outgoing policies with this example.

sudo ufw --dry-run allow from 192.168.56.10 to any port 22 proto tcp
sudo ufw allow from 192.168.56.10 to any port 22 proto tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing

A dry run displays proposed rules without granting access. Add the management permission first and keep console login available. A port 22 rule does not protect SSH configured on another port.

Ubuntu’s firewall guide explains UFW behavior, source restrictions, and dry runs.

Allow the required service and enable the firewall

sudo ufw allow from 192.168.56.10 to any port 80 proto tcp
sudo ufw enable
sudo ufw status verbose

Port80 here permits HTTP testing only from the stated client. Do not pre-open an unused service. Read enable’s connection warning and retain the old session until a new SSH connection succeeds from another terminal.

Distinguish IPv6, cloud, and container filtering

Inspect IPv6 settings in /etc/default/ufw and IPv6 listeners in ss. A blocked IPv4 client does not establish blocked IPv6 access. Cloud security groups, routers, and host firewalls are separate layers.

Container engines such as Docker can install their own publishing rules. UFW alone does not establish container exposure. Check host bindings and the engine’s documented firewall integration and test actual access externally.

Test access and reverse individual rules

Use fresh SSH and HTTP connections from the permitted client and the same destination from a denied client. Existing connections may survive stateful filtering and do not prove the new-connection policy. Distinguish a stopped service from a firewall denial.

sudo ufw delete allow from 192.168.56.10 to any port 80 proto tcp
sudo ufw status numbered

The command removes only the added example HTTP rule. Retain needed SSH access. Refresh rule numbers before numbered deletion, and do not reset or disable unrelated policy. Fully restoring a fresh VM that was initially inactive requires reviewing the original policy and complete change record.