Firewalls with firewalld and ufw

Part A runs on rocky01 (firewalld), with ubu01 as the client that tests each rule. Part B runs on ubu01 (ufw), with rocky01 as the client. Take snapshots of both first (VBoxManage snapshot rocky01 take before-l34 and the same for ubu01).

The test web server is Python’s built-in one on port 8080, so you don’t need to install anything.

1See what firewalld is doing on rocky01

On rocky01, run this:

sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

You should see something like this:

running
public
public (default)
  interfaces: enp0s3

firewalld is running, public is the default zone, and enp0s3 (your only network card) is in it. Any zone with no interface or source is inactive and doesn’t affect traffic at all. --get-zones lists all of them: block, dmz, drop, external, home, internal, nm-shared, public, trusted and work.

✅ Checkpoint: firewalld is running and enp0s3 is in the public zone.

2Read the public zone

Run this:

sudo firewall-cmd --list-all

You should see something like this:

public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: enp0s3
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Only three services are allowed in: ssh (22/tcp), cockpit (9090/tcp, Rocky’s web console) and dhcpv6-client. ports and rich rules are empty. Everything else that starts a new connection is rejected. To see what a service name means, ask firewalld:

sudo firewall-cmd --info-service=ssh

ssh
  ports: 22/tcp
  protocols:
  source-ports:
  modules:
  destination:
  includes:
  helpers:

✅ Checkpoint: You can name the three allowed services and the port behind ssh.

3Start a web server and watch the firewall block it

On rocky01, start the test server:

python3 -m http.server 8080 --directory /tmp >/tmp/http8080.log 2>&1 &
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

200

Now, on ubu01, try the same from outside:

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.10.10.11:8080/
nc -zv -w 3 10.10.10.11 8080

You should see something like this:

curl: (7) Failed to connect to 10.10.10.11 port 8080 after 1 ms: Couldn't connect to server
000
nc: connect to 10.10.10.11 port 8080 (tcp) failed: No route to host

The server works locally (200) and the network is fine, yet ubu01 can’t connect. “No route to host” is firewalld’s reject coming back as ICMP admin-prohibited, and it arrived in 1 ms, so something answered. Compare that with port 22, which is allowed, or with a port where nothing listens, which gives “Connection refused” instead.

Reading these three answers correctly saves a lot of time.

✅ Checkpoint: localhost gets 200, ubu01 gets “No route to host” on port 8080.

4Open port 8080 for good

On rocky01, run this:

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-ports
sudo firewall-cmd --permanent --zone=public --list-ports

You should see this:

success
success
8080/tcp
8080/tcp

--permanent wrote the rule to /etc/firewalld/zones/public.xml, and --reload rebuilt runtime from it, so both copies now list 8080/tcp. Repeat the curl from ubu01:

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.10.10.11:8080/

200

Try it yourself: build the open-a-port commands for firewalld or ufw in the Command Builder.

✅ Checkpoint: ubu01 gets 200, and 8080/tcp shows in both the runtime and the permanent list.

5Allow 8080 from ubu01 only, with a rich rule

On rocky01, swap the open port for a rule that names the source:

sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.10.10.21/32" port port="8080" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-rich-rules

You should see this:

success
success
success
rule family="ipv4" source address="10.10.10.21/32" port port="8080" protocol="tcp" accept

On ubu01, test from its normal address and from a second, temporary address:

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.10.10.11:8080/
sudo ip addr add 10.10.10.22/24 dev enp0s3
curl -sS -m 5 --interface 10.10.10.22 -o /dev/null -w '%{http_code}\n' http://10.10.10.11:8080/
sudo ip addr del 10.10.10.22/24 dev enp0s3

You should see something like this:

200
curl: (7) Failed to connect to 10.10.10.11 port 8080 after 0 ms: Couldn't connect to server
000

From 10.10.10.21 the rich rule matches and the request gets 200. From 10.10.10.22 nothing matches, so the zone rejects it. This is how you open a database or monitoring port to one app server or one monitoring host instead of the whole network.

Rich rules can also log, limit a rate or reject; man firewalld.richlanguage has the full syntax. The extra address you added with ip is gone after the del (and would be gone after a reboot anyway).

✅ Checkpoint: ubu01 gets 200 from 10.10.10.21 and a failure from 10.10.10.22.

6Read the nftables rules underneath

On rocky01, run this:

sudo nft list tables
sudo nft list chain inet firewalld filter_IN_public_allow
sudo nft list chain inet firewalld filter_INPUT

You should see something like this:

table inet firewalld
table inet firewalld {
	chain filter_IN_public_allow {
		tcp dport 22 accept
		ip6 daddr fe80::/64 udp dport 546 accept
		tcp dport 9090 accept
		ip saddr 10.10.10.21 tcp dport 8080 accept
	}
}
table inet firewalld {
	chain filter_INPUT {
		type filter hook input priority filter + 10; policy accept;
		ct state { established, related } accept
		ct status dnat accept
		iifname "lo" accept
		ct state invalid drop
		jump filter_INPUT_POLICIES
		reject with icmpx admin-prohibited
	}
}

This is what the kernel enforces. Your three services became tcp dport 22, udp dport 546 and tcp dport 9090, and the rich rule became one line with ip saddr. The input chain shows the order from the explanation: established traffic first, then the zone rules, then the final reject.

Read nft output when you need proof, but make changes with firewall-cmd, because firewalld rebuilds its table at every reload and anything you add with nft by hand disappears.

✅ Checkpoint: You can find the 8080 rule and the final reject rule in the nft output.

7Switch on ufw on ubu01, SSH first

On ubu01, run this:

sudo ufw status
sudo ufw app list
sudo ufw allow OpenSSH
sudo ufw enable

Answer y to the question. You should see something like this:

Status: inactive
Available applications:
  OpenSSH
Rules updated
Rules updated (v6)
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

The OpenSSH application profile comes with the openssh-server package and means 22/tcp. “Rules updated (v6)” means ufw added the same rule for IPv6. The warning appears because ufw sees you’re on SSH; you already allowed it, so y is safe.

Check the result from the laptop with a new connection (ssh ubu01 hostname) before you close anything.

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

ubu01 also receives rocky01’s logs on TCP 514 since Lesson 29. The default deny now blocks them, so allow that one sender too: sudo ufw allow from 10.10.10.11 to any port 514 proto tcp. rsyslog on rocky01 kept the messages in its disk queue while the port was closed and sends them now. Every service you add to ubu01 later in the course gets its own rule like this.

✅ Checkpoint: ufw is active, the default for incoming is deny, and a new SSH login from the laptop still works.

8Allow, number and delete ufw rules

On ubu01, start the same test server and allow port 8080 from rocky01 only:

python3 -m http.server 8080 --directory /tmp >/tmp/http8080.log 2>&1 &
sudo ufw allow from 10.10.10.11 to any port 8080 proto tcp
sudo ufw status numbered

You should see something like this:

Rule added
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 8080/tcp                   ALLOW IN    10.10.10.11
[ 3] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

On rocky01, test it:

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.10.10.21:8080/

200

Back on ubu01, look at the rule ufw wrote:

sudo nft list chain ip filter ufw-user-input

# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
	chain ufw-user-input {
		tcp dport 22 counter packets 41 bytes 2652 accept
		ip saddr 10.10.10.11 tcp dport 8080 counter packets 1 bytes 60 accept
	}
}

ufw drives iptables, and on Ubuntu iptables is the nft-based version, so ufw’s rules show up in nft as the ufw-* chains. Now delete the 8080 rule by its number, and stop both test servers:

sudo ufw delete 2
sudo ufw status numbered
kill %1

Deleting:
 allow from 10.10.10.11 to any port 8080 proto tcp
Proceed with operation (y|n)? y
Rule deleted
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

Numbers move up after every delete, so run status numbered again before you delete a second rule. On rocky01, stop its test server with kill %1 and remove the rich rule with the same text and --remove-rich-rule, then --reload. ufw stays active on ubu01 with only OpenSSH allowed; later lessons open the ports they need.

✅ Checkpoint: ufw shows only the two OpenSSH rules, rocky01’s public zone has no rich rules, and no python http.server is running on either VM.