14

UFW is not starting for me on boot. My /etc/ufw/ufw.conf file looks like this:

# /etc/ufw/ufw.conf
#

Set to yes to start on boot. If setting this remotely, be sure to add a rule


to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'


ENABLED=yes


Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.


See 'man ufw' for details.


LOGLEVEL=low

So it seems it should start ok. However straight after boot I always get this:

$ sudo ufw status
Status: inactive

Using the "service" script to start it does not seem to work:

$ sudo service ufw start
$ sudo ufw status
Status: inactive

If I force a reload it will work just fine:

$ sudo ufw reload
Firewall reloaded
$ sudo ufw status
Status: active

And after that the "service" script works just fine:

$ sudo ufw status
Status: active
$ sudo service ufw stop
$ sudo ufw status
Status: inactive
$ sudo service ufw start
$ sudo ufw status
Status: active

How do I get ufw to start on boot?

Edit:

I am using Ubuntu 18.04 so systemd is being used. systemctl is-enabled reports as follows:

$ sudo ufw status verbose
Status: inactive
$ sudo systemctl is-enabled ufw.service
enabled

I also tried this:

$ sudo systemctl enable ufw
Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ufw
$ sudo ufw status verbose
Status: inactive

And after a reboot it remains inactive. journalctl -p err reports nothing interesting. journalctl -u ufw reports:

$ journalctl -u ufw
...<snip>...
-- Reboot --
May 26 12:53:36 matt-laptop systemd[1]: Started Uncomplicated firewall.

So it certainly appears that it is attempting to start up ufw...it just seems that it doesn't actually do it!

Zanna
  • 70,465
Matt Caswell
  • 2,250
  • 1
    Did you try ufw enable? https://help.ubuntu.com/community/UFW – PerlDuck May 26 '18 at 09:52
  • 2
    Yes - thanks for the suggestion, but I've tried that. ufw enable successfully starts the firewall and sets ENABLED=yes in ufw.conf (it if isn't already set to "yes"). But this makes no difference. After a reboot ufw is still inactive. – Matt Caswell May 26 '18 at 10:03
  • Same behavior for me... I think it started when I upgraded to 22.04, or maybe 21.10, I can't remember... I am on 23.04 now with still the same problem. – Mathieu J. Jun 12 '23 at 00:43

6 Answers6

16

I came up with a solution of sorts. I made this edit to /lib/systemd/system/ufw.service:

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

[Service]
 Type=oneshot

So, this causes ufw to start after the network is up instead of before it. This seems to do the trick - ufw is always enabled after I boot. I don't know if this is the best way to do things. I worry that there is a small window of time between the network starting and the firewall starting... but at least it starts which is better than before!

Maybe someone can come up with a better solution. Or maybe this is the correct way to do things - in which case is it a bug that it defaults to starting before the network?

Edit:

An even better solution is:

$ 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:

Its primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up.

Which really makes me wonder why it wasn't set to this by default. Setting it to this value seems to solve all my problems.

Zanna
  • 70,465
Matt Caswell
  • 2,250
  • It's curios that the fix in the ufw repo is different: first commit, second commit, result Before=network-pre.target Wants=network-pre.target local-fs.target After=local-fs.target – salmin Oct 09 '22 at 15:57
  • I have the same as @salmin mention under 23.04, but its still broken. I will try flipping it to; Before=network.target Wants=network-pre.target local-fs.target After=network-pre.target – Mathieu J. Jun 12 '23 at 00:46
  • 1
    @MathieuJ. It seems to me that neither the answer above nor the change in ufw repo are relevant to the root cause. Problems I saw were caused not by ufw itself but by other services overriding the iptables after ufw. Modifying Wants/Before/After alters the order of iptables updates and can help in some cases. However the root case is that multiple services fight over iptables control and apply conflicting changes. Good solution is to uninstall/disable/reconfigure them to avoid conflicts. I'm aware of issues with {ipset,iptables,netfilter}-persistent and firewalld pkgs but there could be more – salmin Aug 01 '23 at 17:17
  • I've formatted the above comment as a full answer: https://askubuntu.com/a/1480609/1639205 – salmin Aug 01 '23 at 17:57
4

The fix is simple; we need to tell the operating system to load ufw after the netfilter-persistent

Run this command:

sudo nano /lib/systemd/system/ufw.service

And add this text:

[Unit]
 Description=Uncomplicated firewall
 Documentation=man:ufw(8)
 DefaultDependencies=no
 Before=network.target
 After=netfilter-persistent.service

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


[Install]
 WantedBy=multi-user.target

Source: UFW service not loading after a reboot

Zanna
  • 70,465
Evgeniy Osipov
  • 41
  • 1
    or for the same effect but to survive systemd updates: mkdir /etc/systemd/system/ufw.service.d and then echo -e "[Unit]\nAfter=netfilter-persistent.service" >/etc/systemd/system/ufw.service.d/extend.conf – scoobydoo Oct 13 '21 at 06:17
2

I have a vanilla version of Debian, not Ubuntu, but this was the best post I could find to get ufw to load at startup. The suggestions here did not work for me but provided enough clues for me to eventually get it working.

In the end I only had to change one line. Everything else I left alone.

  • Edit the UNIT section in the ufw.service file.
  • Change Before=network.target to After=network-online.target

Saved it, rebooted and ufw was running

Note that if you disable ufw and reboot it will be disabled. If ufw is enabled and you reboot, it will be enabled.

Zanna
  • 70,465
Dry Bones
  • 21
0

A common problem occurs when the ufw service is enabled and initializes successfully (i.e. updates the iptables) after the reboot, but then the iptables get overridden by some other service later in the chain.

If that's the case, you will see a successful ufw start in system logs and an inactive firewall afterwards.

$ journalctl -b -u ufw.service
-- Logs begin at Sun 2023-02-26 ...
Jul 20 10:02:56 ... systemd[1]: Finished Uncomplicated firewall.

$ ufw status
Status: inactive

Modifying Before/After/Wants in the service config as suggested in other answers changes the order in which services start. So it helps if the problematic services moves before the ufw.

However the root cause remains: multiple services fight over the iptables control and apply conflicting changes. A better solution is to find and uninstall/deactivate/reconfigure the problematic service. Known offenders include {ipset,iptables,netfilter}-persistent and firewalld but likely there are many more in the wild.

You can try reviewing installed packages that depend on iptables (and potentially alter it) like this:

$ apt-cache rdepends --installed iptables

Or examine services started after the ufw in systemd logs.

Other stackexchange answers on the topic:

If you find other packages/services that effectively disable the ufw please post them in the comments, it is greatly appreciated.

PS A similar and even trickier issue of this kind is caused by docker. It doesn't visibly deactivate the ufw but creates additional rules that can expose all your containers to the external network. This problem is described at length here: https://github.com/chaifeng/ufw-docker

salmin
  • 101
0

Only this solution is work (add to crontab):

@reboot sleep 120 && /usr/sbin/ufw reload
Alex
  • 1
  • 1
-3

Edit the file:

/etc/ufw/ufw.conf

Set to yes to start on boot. If setting this remotely, be sure to add a rule to allow your remote connection before starting ufw. Eg: ufw allow 22/tcp

ENABLED=yes
ufw allow 22/tcp

Please use the ufw command to set the loglevel. Eg:

ufw logging medium

See 'man ufw' for details.

LOGLEVEL=low
user68186
  • 33,360
Dundee Internet Services
  • 1
  • /etc/ufw/ufw.conf

    Set to yes to start on boot. If setting this remotely, be sure to add a rule

    to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'

    ENABLED=yes ufw allow 22/tcp

    Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.

    See 'man ufw' for details.

    LOGLEVEL=low

     – Dundee Internet Services Jul 02 '19 at 15:23
  • 3
    What, exactly, do you mean by “Set to yes to start on boot.”?  The OP’s /etc/ufw/ufw.conf file already says ENABLED=yes.  Should they add a line to request start on boot?  What, exactly, should it say?  Please do not respond in comments; [edit] your answer to make it clearer and more complete. – G-Man Says 'Reinstate Monica' Jul 02 '19 at 15:50