ufw does not start automatically at boot

Hi Matt, can you give the output of:

systemctl status ufw

and

journalctl -u ufw.service

Thanks

Hi Seth,

This is what I get:

matt@matt-laptop:~$ sudo ufw status
Status: inactive
matt@matt-laptop:~$ journalctl -u ufw.service
-- Logs begin at Tue 2017-10-24 22:48:54 BST, end at Wed 2017-10-25 00:03:54 BST. --
Oct 24 22:48:54 matt-laptop systemd[1]: Started Uncomplicated firewall.
matt@matt-laptop:~$ systemctl status ufw
● ufw.service - Uncomplicated firewall
   Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2017-10-24 22:48:54 BST; 1h 15min ago
     Docs: man:ufw(8)
  Process: 443 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
 Main PID: 443 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/ufw.service

Oct 24 22:48:54 matt-laptop systemd[1]: Started Uncomplicated firewall.
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

This issue still seems to be a problem in 18.04.

If found a solution:
https://askubuntu.com/questions/1040539/how-do-i-get-ufw-to-start-on-boot/1040584

I edited /lib/systemd/system/ufw.service as follows:

$ diff -u ufw.service.orig ufw.service
--- ufw.service.orig 2018-05-26 13:45:48.696356561 +0100
+++ ufw.service 2018-05-26 14:17:22.030681670 +0100
@@ -2,7 +2,7 @@
 Description=Uncomplicated firewall
 Documentation=man:ufw(8)
 DefaultDependencies=no
-Before=network.target
+After=network-pre.target

 [Service]
 Type=oneshot

According to this page

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

the network-pre.target has this purpose:

"It's primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up"

Making the above change solves the problem so that ufw does seem to start up after boot. Is it a bug that ufw.service is not setup this way to start with?

Wrt:

the network-pre.target has this purpose:

"It's primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up"

I'm not sure network-pre.target existed at the time ufw added a systemd unit, but regardless, this sounds like exactly what we should be doing. Thanks for the triage!

Unfortunately, after a few reboots using these settings it seems this is not the answer. While it does seem to work intermittently, it also sometimes fails. I've also had some issues with network not working at all. I'm not 100% sure that this change is the culprit - but for now I have reverted the change.

It still seems to me likely that there is some issue with the systemd dependencies. With the previous settings ufw never seems to be active after boot.

You need

Before=network-pre.target
Wants=network-pre.target

(Wants is necessary because network-pre.target is a passive target)
(Before=network.target can be removed)

And then network management software needs to have After=network-pre.target. systemd-networkd and NetworkManager are fine, but I do not know about legacy stuff like ifupdown.

BTW, why DefaultDependencies=no is being set?

network-pre.target is systemd 214+. Since Debian Jessie has 215, it is probably safe use it.

I just tried that:

$ diff -u ufw.service.orig ufw.service
--- ufw.service.orig 2018-05-26 13:45:48.696356561 +0100
+++ ufw.service 2018-07-17 16:50:45.545596167 +0100
@@ -2,7 +2,8 @@
 Description=Uncomplicated firewall
 Documentation=man:ufw(8)
 DefaultDependencies=no
-Before=network.target
+Before=network-pre.target
+Wants=network-pre.target

 [Service]
 Type=oneshot

But after a reboot, nothing changed:

$ sudo ufw status
Status: inactive

On latest Ubuntu 18.04 I have an inconsistent state of ufw on reboots (sometimes even ssh doesn't work):
root@us-proxy1:~# uname -a
Linux us-proxy1 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@us-proxy1:~# dpkg -l |grep ufw
ii ufw 0.35-5 all program for managing a Netfilter firewall

When I login via console, 'ufw status' looks ok, but still not all services work. 'systemctl status ufw is FAILED'. Restarting the Firewall solves the issue, but always logging into a server via console if ssh doesn't work is not acceptable. I will try the workaround mentioned above.
Errors always happen on COMMIT of ruleset:

root@us-proxy1:~# journalctl -u ufw.service
-- Logs begin at Thu 2018-07-19 13:09:26 UTC, end at Mon 2018-07-23 08:27:50 UTC. --
Jul 19 13:09:27 guest systemd[1]: Started Uncomplicated firewall.
-- Reboot --
Jul 19 14:12:46 us-proxy1 ufw-init[415]: iptables-restore: line 77 failed
Jul 19 14:12:47 us-proxy1 ufw-init[415]: Problem running '/etc/ufw/before.rules'
Jul 19 14:12:47 us-proxy1 systemd[1]: ufw.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 14:12:47 us-proxy1 systemd[1]: ufw.service: Failed with result 'exit-code'.
Jul 19 14:12:47 us-proxy1 systemd[1]: Failed to start Uncomplicated firewall.
-- Reboot --
Jul 19 14:54:06 us-proxy1 ufw-init[421]: iptables-restore: line 44 failed
Jul 19 14:54:07 us-proxy1 ufw-init[421]: Problem running '/etc/ufw/user.rules'
Jul 19 14:54:07 us-proxy1 systemd[1]: ufw.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 14:54:07 us-proxy1 systemd[1]: ufw.service: Failed with result 'exit-code'.
Jul 19 14:54:07 us-proxy1 systemd[1]: Failed to start Uncomplicated firewall.
Jul 19 15:09:51 us-proxy1 systemd[1]: Starting Uncomplicated firewall...
Jul 19 15:09:51 us-proxy1 ufw-init[1985]: Firewall already started, use 'force-reload'
Jul 19 15:09:51 us-proxy1 systemd[1]: Started Uncomplicated firewall.
-- Reboot --
Jul 19 15:21:17 us-proxy1 ufw-init[413]: ip6tables-restore: line 138 failed
Jul 19 15:21:17 us-proxy1 ufw-init[413]: Problem running '/etc/ufw/before6.rules'
Jul 19 15:21:17 us-proxy1 systemd[1]: ufw.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 15:21:17 us-proxy1 systemd[1]: ufw.service: Failed with result 'exit-code'.
Jul 19 15:21:17 us-proxy1 systemd[1]: Failed to start Uncomplicated firewall.
Jul 19 15:22:29 us-proxy1 systemd[1]: Starting Uncomplicated firewall...
Jul 19 15:22:29 us-proxy1 ufw-init[1424]: Firewall already started, use 'force-reload'

I changed this:
-Before=network.target
+Before=network-pre.target
+Wants=network-pre.target

and get following:
Jul 23 09:40:53 us-proxy1 ufw-init[424]: ip6tables-restore: line 4 failed
Jul 23 09:40:53 us-proxy1 systemd[1]: ufw.service: Main process exited, code=exited, status=1/FAILURE
Jul 23 09:40:53 us-proxy1 systemd[1]: ufw.service: Failed with result 'exit-code'.
Jul 23 09:40:53 us-proxy1 systemd[1]: Failed to start Uncomplicated firewall.

When I look at /lib/ufw/ufw-init-functions:
 147 printf "*filter\n"\
    148 ":INPUT DROP [0:0]\n"\
    149 ":FORWARD DROP [0:0]\n"\
    150 ":OUTPUT DROP [0:0]\n"\
    151 "-A INPUT -i lo -j ACCEPT\n"\
    152 "-A OUTPUT -o lo -j ACCEPT\n"\
    153 "COMMIT\n" | ip6tables-restore || error="yes"

This might be realted to loopback interface not beeing configured ? So ufw starts too early ?

If I use in /lib/systemd/system/ufw.service:
-Before=network.target
+After=network.target

ufw starts without errors, so there seem to be dependencies in the network.target, that are not allowing ufw-init-functions to complete successfully.

Also tested:
After=network-pre.target
Wants=network-pre.target

This works as well, so this seems to be the appropriate config ? Maybe @marcosfrm has a typo in his recommendation ?

Sorry after some more reboots the problem persists with:
After=network-pre.target
Wants=network-pre.target

So only working setup for me at the moment is:
After=network.target

I just tried:
After=network.target

After 5 reboot tests I got mixed results:
The first two reboots failed to start networking at all and ufw reported its status as "inactive" immediately after boot.
The next two reboots networking started successfully, and ufw reported as active.
The final reboot, networking again did not start and ufw status was "inactive"

For those experiencing this issue, can you adjust /lib/ufw/ufw-init to use this:

#!/bin/sh -x

on its first line instead of:

#!/bin/sh

Then reboot and until you see the issue. When you do, please use `journalctl --no-pager --unit=ufw` and attach the results.

Thanks!

I made the change to /lib/ufw/ufw-init as requested and confirmed that after reboot I was still hitting the issue (Ubuntu 18.04.1 LTS):

$ sudo ufw status
Status: inactive

Attached is the requested journalctl output.

@Matt, there aren't any errors in your journalctl output that I can see.

Without removing the change to /lib/ufw/ufw-init yet, can you reboot until you see the problem, and then before you correct the issue, can you attach the output of all of the following:

1. journalctl --no-pager > /tmp/journal.full
2. dpkg -l > /tmp/dpkg.list
3. sudo tar -zcf /tmp/ufw.tar.gz /lib/ufw/ /etc/default/ufw /etc/ufw/ /usr/share/ufw/
4. sudo ufw show raw > /tmp/ufw.raw

I rebooted and confirmed that ufw still reports itself as inactive. Attached are the requested files. Note: I only included the last 25000 lines from journal.full - otherwise I would have to upload 250Mb!

@Matt you have both ufw and firewalld installed and running. You should disable/remove firewalld. Marking this as 'Invalid' for now, but please feel free to report back if you still see a bug in ufw after addressing firewalld.

Hi,

I can confirm this bug still exists on Ubuntu 18.04 and in my case none of the above solutions have been successful.

The following workaround has solved it for me:

Edit /etc/crontab and add the following line:
@reboot root ufw enable

It has worked every time on 5 reboots I have done to test.

I also had this problem still once in a while and had a look at it again. I think in my case the problem is the package sshguard, which also adds firewall rules on startup and in some cases might interfere with ufw startup.
I added /etc/systemd/system/sshguard.service.d/after_ufw.conf with content:
[Unit]
After=ufw.service

and so far this seems to work.
I guess any package using iptables on boot should be using some kind of systemd dependency to ufw ?

This bug occurs in Ubuntu 20.04 too but I could bypass it by using the suggested fix in comment #23

@Muhammad - can you run:

$ sudo /usr/share/ufw/check-requirements

and paste the results?

I also have this Bug on "Raspbian GNU/Linux 10 (buster)". I solved it with the following changes:

-Before=network.target
+After=network.target

-ExecStart=/lib/ufw/ufw-init start quiet
+ExecStart=/usr/sbin/ufw --force enable

-ExecStop=/lib/ufw/ufw-init stop
+ExecStop=/usr/sbin/ufw --force disable

I had to change the start and stop commands, without it sometimes doesn't work. I Tested this changes with 25 reboots without any problems.

@Maintainers: Please publish this (or another) fix as soon as possible in the repositories because this is a major security vulnerability. I also suggest to request a CVE number.

Best regards
Fabian Fröhlich

This bug still exist since i was a kid. now in 2021 its still exist in Ubuntu 20.04 (LTS) . Will reupdate the status 10 years from now.

@Fabian - your change both makes the firewall start after networking, brings python into the boot process (which can slow down boot) and changes the intent of 'systemctl stop ufw' from unloading the firewall to disabling the firewall in the moment and forever in the future, which is inappropriate ('systemctl stop' is supposed to stop the service until someone runs 'systemctl start' again or reboot. 'systemctl disable' is meant to prevent the service from starting on reboot. This might be fine for your system, but it would not be appropriate as a default in ufw or distributions. Also, this bug is in upstream ufw and you are reporting an issue on Raspbian, who would supply the packaging for ufw. If you still feel the change should be made, I suggest filing a bug with Raspbian so they can change their packaging of ufw.

@cajicas215 - your comment is not helpful. If you look at the other comments in this bug, there has been nothing to fix in ufw. I suggest looking at the comments in this bug and seeing if any of the issues others have seen apply to you. If not, please report a new bug with steps to reproduce.

I've looked at this issue again in reference to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 and while I still cannot reproduce, I plan to change to the following (I won't ship the commented out lines of course):

[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
#DefaultDependencies=no
#Before=network.target
Before=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

This removes DefaultDependencies=no so that 'sysinit' will be pulled in and changes the single 'Before=network.target' to instead have Before=network-pre.target and Wants=network-pre.target. This won't help people who have different firewall software installed (like some of the comments), but should make startup more robust (eg, for those needing something from sysinit) while still allowing it to come up before the network.

This bug was fixed in the package ufw - 0.36.1-3

---------------
ufw (0.36.1-3) unstable; urgency=medium

  * debian/ufw.service (LP: #1726856, Closes: 990834):
    - use Before and Wants on network-pre.target. Per systemd documentation,
      "network-pre.target is a target that may be used to order services
      before any network interface is configured. Its primary purpose is for
      usage with firewall services". Because network-pre.target is a passive
      unit, "services that want to be run before the network is configured
      should place Before=network-pre.target and also set
      Wants=network-pre.target to pull it in"
    - remove DefaultDependencies=no so that we pull in default dependencies
      for "basic system initialization". While ufw is meant to come up before
      networking, there is no reason why it shouldn't come up after sysinit.
      This should help make ufw startup more robust on systems that need
      something from sysinit.

 -- Jamie Strandboge <email address hidden> Tue, 02 Nov 2021 13:27:42 +0000

This introduced an ordering cycle, and hence broke networking, see https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039

I have the same issue on an computer with NVME. Maybe the boot is too fast? The fix and all workarounds (cron) haven't helped.

Im using Ubuntu 20.04 by the way.

To make clear what I meant: I think the dependencies aren't defined right such that some services are starting to early.

Running "/usr/bin/sleep 10 && /usr/sbin/ufw enable" via cron works for me

Same problem here. Also when I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up.

ufw 0.36

Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed?

Here is my theory. It takes a while for fail2ban to issue the myriad of iptable commands of the fail2ban database it large. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity.

This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost.

How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts?

@Stefan, I suggest you try the fix that is in Debian. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834#27

@Myron, yours sounds like a different issue. I suggest you file a new bug, downloading https://git.launchpad.net/ufw/tree/tests/check-requirements and including the output of 'sudo sh /path/to/check-requirements'.

@jdstrand I've created a new bug report as you suggested:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029

Reading through the comments that precede mine, it does look like the issues I'm encountering are more-or-less the same so may be the same bug.

@jdstran The fix of Debian doesn't help. I use fail2ban too. But if fail2ban.service is disabled and masked then the issue still happens.