1

I know two ways to start UFW: through systemctl and through ufw itself. For example, when i use systemctl enable ufw, i get this status:

systemctl status ufw

● ufw.service - CLI Netfilter Manager
   Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; vendor preset:>
   Active: active (exited) since Sun 2019-12-01 12:34:29 +05; 6min ago

But ufw itself says:

ufw status verbose

Status: inactive

I can not see rules through it and GUFW utility says that UFW inactive. But if i do:

systemctl disable ufw
systemctl stop ufw
ufw enable
ufw status verbose

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

Then i can use GUFW and look at verbose status and rules in UFW utility.

So what is the difference between starting through systemctl and ufw itself and what is the right way to do it?

  • They are two different things. Systemd controls whether the UFW service itself is loaded and started. ufw enable controls whether the firewall actually does something. So you should have it enabled in both places. – AlexP Dec 1 '19 at 8:25
0

If you do ufw enable, systemctl disable ufw and then reboot the system, what is the ufw status verbose output after the reboot?

I'm guessing that it will be inactive.

If that's true, then the explanation is as follows:

  • ufw enable = enable firewall rules right now, and make a record that the desired state is to have the firewall enabled from now on. (If a firewall management daemon is needed, this will also start it automatically.)

  • ufw disable = disable firewall rules right now, and make a record that the desired state is to have the firewall disabled until commanded otherwise.

  • systemctl start ufw = restore the previously-recorded desired state of the firewall (if the desired state is to have the firewall disabled, there will be nothing to do). Also, start any firewall management daemon if needed, in such a way that the management process will be recognized by systemd as a background process that does not belong to any user session. If you want to have the firewall enabled persistently, you'll want this to happen automatically at boot time, and also have ufw enable set.

  • systemctl stop ufw = stop the firewall management daemon; may or may not also disable any existing firewall rules (use iptables -vnL or nft list tables to check the actual rules in effect within the kernel, independently from ufw).

  • systemctl enable ufw = at any subsequent reboots, run systemctl start ufw automatically as part of the boot process.

  • systemctl disable ufw = at any subsequent reboots, don't do anything to restore the firewall state and don't automatically start the firewall management daemon: go with the kernel default of no firewall rules at all.


For example, if you need to set up new firewall rules remotely and must ensure you won't lock yourself out, you might set systemctl disable ufw, set up an automatic reboot in 15 minutes or so, then add your rules and use ufw enable. If you can still connect to the system, the rules are correct as far as the remote access is concerned; you can set systemctl enable ufw (so the rules will be effective also after a reboot) and remove the timed reboot job.

But if you made a mistake that disables your access, just wait for the reboot job to trigger, and the system will come up with no firewall rules (because of systemctl disable ufw) and you will be able to log back in to fix the rule configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.