ufw remains inactive at boot time

[Myron Szymanskyj]

I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

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.

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 all the iptable commands to configure the firewall. 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?

-----
root@loki:~# ./ufw-diag.sh
Has python: pass (binary: python3, version: 3.8.10, py3)
Has iptables: pass
Has ip6tables: pass

Has /proc/net/dev: pass
Has /proc/net/if_inet6: pass

This script will now attempt to create various rules using the iptables
and ip6tables commands. This may result in module autoloading (eg, for
IPv6).
Proceed with checks (Y/n)?
== IPv4 ==
Creating 'ufw-check-requirements'... done
Inserting RETURN at top of 'ufw-check-requirements'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
addrtype (LOCAL): pass
addrtype (MULTICAST): pass
addrtype (BROADCAST): pass
icmp (destination-unreachable): pass
icmp (source-quench): pass
icmp (time-exceeded): pass
icmp (parameter-problem): pass
icmp (echo-request): pass

== IPv6 ==
Creating 'ufw-check-requirements6'... done
Inserting RETURN at top of 'ufw-check-requirements6'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
icmpv6 (destination-unreachable): pass
icmpv6 (packet-too-big): pass
icmpv6 (time-exceeded): pass
icmpv6 (parameter-problem): pass
icmpv6 (echo-request): pass
icmpv6 with hl (neighbor-solicitation): pass
icmpv6 with hl (neighbor-advertisement): pass
icmpv6 with hl (router-solicitation): pass
icmpv6 with hl (router-advertisement): pass
ipv6 rt: pass

All tests passed
-----
root@loki:/lib/systemd/system# cat ufw.service
[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
DefaultDependencies=no
Before=network.target
After=NetworkManager.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
# ExecStartPost=/bin/sleep 10
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

-----
root@loki:/lib/systemd/system# cat fail2ban.service
[Unit]
Description=Fail2Ban Service
Documentation=man:fail2ban(1)
After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service
PartOf=firewalld.service

[Service]
Type=simple
ExecStartPre=/bin/mkdir -p /run/fail2ban
ExecStart=/usr/bin/fail2ban-server -xf start
# if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local
# ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
ExecStop=/usr/bin/fail2ban-client stop
ExecReload=/usr/bin/fail2ban-client reload
PIDFile=/run/fail2ban/fail2ban.pid
Restart=on-failure
RestartPreventExitStatus=0 255

[Install]
WantedBy=multi-user.target

-----
root@loki:/etc/default# cat ufw
# /etc/default/ufw
#

# Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
# accepted). You will need to 'disable' and then 'enable' the firewall for
# the changes to take affect.
IPV6=yes

# Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if
# you change this you will most likely want to adjust your rules.
DEFAULT_INPUT_POLICY="DROP"

# Set the default output policy to ACCEPT, DROP, or REJECT. Please note that if
# you change this you will most likely want to adjust your rules.
DEFAULT_OUTPUT_POLICY="ACCEPT"

# Set the default forward policy to ACCEPT, DROP or REJECT. Please note that
# if you change this you will most likely want to adjust your rules
DEFAULT_FORWARD_POLICY="DROP"

# Set the default application policy to ACCEPT, DROP, REJECT or SKIP. Please
# note that setting this to ACCEPT may be a security risk. See 'man ufw' for
# details
DEFAULT_APPLICATION_POLICY="SKIP"

# By default, ufw only touches its own chains. Set this to 'yes' to have ufw
# manage the built-in chains too. Warning: setting this to 'yes' will break
# non-ufw managed firewall rules
MANAGE_BUILTINS=no

#
# IPT backend
#
# only enable if using iptables backend
IPT_SYSCTL=/etc/ufw/sysctl.conf

# Extra connection tracking modules to load. IPT_MODULES should typically be
# empty for new installations and modules added only as needed. See
# 'CONNECTION HELPERS' from 'man ufw-framework' for details. Complete list can
# be found in net/netfilter/Kconfig of your kernel source. Some common modules:
# nf_conntrack_irc, nf_nat_irc: DCC (Direct Client to Client) support
# nf_conntrack_netbios_ns: NetBIOS (samba) client support
# nf_conntrack_pptp, nf_nat_pptp: PPTP over stateful firewall/NAT
# nf_conntrack_ftp, nf_nat_ftp: active FTP support
# nf_conntrack_tftp, nf_nat_tftp: TFTP support (server side)
# nf_conntrack_sane: sane support
IPT_MODULES=""

-----
root@loki:/etc/ufw# lsb_release -rd
Description: Ubuntu 20.04.3 LTS
Release: 20.04

-----
root@loki:/etc/ufw# ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.

[Myron Szymanskyj (myron-s)]

root@loki:/home/myron# journalctl -u ufw.service
-- Logs begin at Wed 2021-12-29 15:30:45 GMT, end at Thu 2021-12-30 13:10:27 GMT. --
-- No entries --

-----

Current status of service. ufw was enabled manually so is actually active. It won't be once I reboot.

root@loki:/home/myron# systemctl status ufw
● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-12-29 15:30:34 GMT; 21h ago
       Docs: man:ufw(8)
   Main PID: 295 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4915)
     Memory: 0B
     CGroup: /system.slice/ufw.service

Warning: journal has been rotated since unit was started, output may be incomplete.

[Jamie Strandboge (jdstrand)]

Thanks for the bug report. A few things:

1. I'm not sure what 'networking stops' means precisely in the context of this bug report. Does 'ufw disable' restore the network? Is the network torn down? Something else (you are using a lot of limit rules instead of allow rules, I wonder if you are hitting limits...)?

2. 'journalctl -u ufw.service' isn't normally going to show you much since the command run from the service isn't very chatty. Better would be to look at /var/log/ufw.log around the time the networking stops. If /var/log/ufw.log doesn't exist on your distro, you should check /var/log/kern.log for firewall denials and then try to resolve them with new/modified firewall rules

3. It isn't clear if you used the check-requirements from https://git.launchpad.net/ufw/tree/tests/check-requirements or the one on the system. Which did you use? (Note, I just made a change to https://git.launchpad.net/ufw/tree/tests/check-requirements that you might want to use)

4. you didn't mention which distro you are using, but the ufw.service file is not what is shipped upstream (or Ubuntu or Debian). This is what has been shipped in Ubuntu and Debian for several years:

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

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

    [Install]
    WantedBy=multi-user.target

  and this is what is upstream (Debian is the same except omits the 'Conflicts') and what should solve some issues (though I'm not sure it would solve your issues:

    [Unit]
    Description=Uncomplicated firewall
    Documentation=man:ufw(8)
    Before=network-pre.target
    Wants=network-pre.target
    Conflicts=iptables.service ip6tables.service nftables.service firewalld.service

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

    [Install]
    WantedBy=multi-user.target

  You may want to adjust the service file to be like the upstream one, then run 'sudo systemctl daemon-reload' and reboot.

[Jamie Strandboge (jdstrand)]

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

This line from your existing fail2ban.service should be sufficient:

After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service

See https://www.freedesktop.org/software/systemd/man/systemd.unit.html for details ("After= is the inverse of Before=, i.e. while Before= ensures that the configured unit is started before the listed unit begins starting up, After= ensures the opposite, that the listed unit is fully started up before the configured unit is started.")

[Jamie Strandboge (jdstrand)]

> 4. you didn't mention which distro you are using

This would be good to know since some distros are using iptables 1.8.x which has two different backends that are in play. Which distro are you using and what is the output of `iptables --version`

[Myron Szymanskyj (myron-s)]

By networking stops means that I can not establish a connection with the Lemaker BananaPi Pro on any port so I can't get a SSHed shell, can't access the VPN server, etc... It behaves like someone has plugged the network cable.

Putting "ufw.service" was a guess, but I've not rebooted the OS yet with that in place.

root@loki:~# iptables --version
iptables v1.8.4 (legacy)
root@loki:~# uname -a
Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux
root@loki:~# fail2ban-client --version
Fail2Ban v0.11.1

OS in use obtained from here: https://www.armbian.com/banana-pi-pro/

I will try a reboot and see what happens. Will report result back here.

[Myron Szymanskyj (myron-s)]

Right after reboot I tried to get the status.

Result is . . . .

root@loki:~# s ufw status
ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

. . . . while fail2ban is setting up its rules.

Anyway... After a reeboot, whatever I've done seems to have worked. I'm assuming adding "ufw.service" to fail2ban.service may have done the trick as has been mentioned on comment 4.

[Myron Szymanskyj (myron-s)]

Sorted out the issue. I've got systemd to also wait for ufw to load when starting fail2ban.

Fail2ban issues a many iptables commands in rapid succession and then it's database of banned IPs is large it takes a considerable amount of time for the firewall to be initialised. In the meanwhile anything issuing iptables commands quite likely fail as is it not possible to have more than one instance of iptables active at any one time.

ufw script completes its tasks quickly so makes sense to force that service to start before the fail2ban service.

[Jamie Strandboge (jdstrand)]

Thanks for the response and glad you got it worked out. It reminds me that I would like to document using fail2ban with ufw more.