ufw can't be enabled when iptables-persistent or netfilter-persistent is installed

[Will]

ufw broke after upgrade from Ubuntu 20.04.4 to Ubuntu 22.04.01

sudo ufw enable:

ERROR: problem running ufw-nit
iptables-restore: line 4 failed
ip6tables-restore: line 4 failed

It enables ufw but none of the rules work so all traffic is blocked.

I can temp fix via: sudo /lib/ufw/ufw-init flush-all

Then rules enable fine, well until a reboot anyways in which it breaks again.

ufw version 0.36.1

[Jamie Strandboge (jdstrand)]

What is the out of each of these:

$ cat /proc/version_signature

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

[Will (war59312)]

cat /proc/version_signature:

Ubuntu 5.15.0-46.49-generic 5.15.39

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

Has python: pass (binary: python3, version: 3.10.4, 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)? y
== 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

WARN: detected other firewall applications:
 netfilter-persistent
(if enabled, these applications may interfere with ufw)

All tests passed

[Jamie Strandboge (jdstrand)]

This may be why you are seeing this:

WARN: detected other firewall applications:

netfilter-persistent

If you want to use ufw, you should:

$ sudo apt-get remove --purge netfilter-persistent

Fyi, nothing should have pulled this in as part of the upgrade to 22.04.1, but iptables-peraistent and ipset-peraistent would pull it in. You would want to remove those as well.

[Will (war59312)]

Interesting...

Both iptables-persistent and netfilter-persistent where installed along with ufw for last like 2 years or something.

Only broke after the upgrade to 22.04.

Anyways, uninstalled both.

Sure enough good to go after the reboot, thank you.

Well, at least this report is here in case someone else runs into this same issue.

[Jamie Strandboge (jdstrand)]

iptables-persistent and netfilter-persistent are very simple and will just record the rules they found and reload on reboot. If I were to guess, I would guess that it was either postinst ordering or there was is a race on boot between these and ufw and you happened to notice the race this time.

Glad it is working for you now!

[Mike Tegtmeyer (tegtmeye)]

I believe this is actually broken.

This issue appears to not be the presence of iptables-persistent, it appears that rebooting with UFW enabled does not set up the INPUT, FORWARD, and OUTPUT chains to the UFW-specific ones if any iptable rules existed previously. That is, booting with UFW enabled appears to expect clean iptables.

For me, the following illustrates the problem:

1. Set up a default install: no UFW rules and no iptables-persistent, Do not enable UFW (ufw disable). Clean boot.

2. Install iptables-persistent and have it create default rules.v4 and rules.v6. These should be empty.

3. Enable UFW. If you run 'iptables-save' you will see hooks from the default chains to the UFW-specific ones (ie INPUT->ufw-*, FORWARD->ufw-*, and OUTPUT->ufw-*).

4. Rebooting with or without UFW enabled works fine.

5. Ensure rebooted with UFW disabled and add any rule to /etc/iptables/rules.v4. here, simple forwarding rules:

> cat /etc/iptables/rules.v4
iptables -A FORWARD -i enp1s0f0 -o bond0 -j ACCEPT
iptables -A FORWARD -i bond0 -o enp1s0f0 -m state --state RELATED,ESTABLISHED -j ACCEPT

6. Reboot with UFW disabled. All is well which you can verify with iptables-save

> iptables-save
# Generated by iptables-save v1.8.7 on Sat Jan 14 17:06:36 2023
*filter
:INPUT ACCEPT [106589:162920040]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [53198:3808907]
-A FORWARD -i enp1s0f0 -o bond0 -j ACCEPT
-A FORWARD -i bond0 -o enp1s0f0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sat Jan 14 17:06:36 2023

7. If you enable UFW, all is still well. Notice that these rules appear prior to the UFW chain hooks INPUT->ufw-*, FORWARD->ufw-*, and OUTPUT->ufw-*

> iptables-save
# Generated by iptables-save v1.8.7 on Sat Jan 14 17:08:14 2023
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
... [lots of stuff] ...
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -i enp1s0f0 -o bond0 -j ACCEPT
-A FORWARD -i bond0 -o enp1s0f0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
... [lots of stuff] ...

8. However if you reboot with UFW enabled, the rules from /etc/iptables/rules.v4 are added but the INPUT->ufw-*, FORWARD->ufw-*, and OUTPUT->ufw-* hooks are missing. Since UFW default to DROP and the UFW-specific chains are never run, the network breaks because everything is dropped. For me, rebooting with UFW enabled and running from the console shows these missing:

> iptables-save
# Generat...

[DSmidge (dsmidge)]

I had the same problem: ufw and iptables-persistent were installed at the same time. On 20.04 it worked OK. And on 22.04 ping to 127.0.0.1 was not working, nslookup was not working. Spend 3 hours fixing the problem as I had no idea what the problem was. At the end I was lucky to find this post. :)

[Christian (codiflow)]

I can back this bug but it is different to me then it was described above.

It also appeared for me after inplace-upgrading Debian 10 (buster) to Debian 11 (bullseye).

I never installed "iptables-persistent" and "netfilter-persistent" manually so they must have been installed together with ufw. After the upgrade to Debian 11 the problem started to bring me headaches too.

Issuing "ufw enable" brought up the error "ip6tables-restore: line 4 failed" on the first execution of "ufw enable". The second execution went through without problems responding with "Firewall is active and enabled on system startup". But that not really was the case.

I recognized this bug for the first time because IPv6 download and ping was not working (anymore) after enabling ufw (and it was not a rule issue because outbound traffic was allowed).

A simple test for this was to issue a ping test with IPv6 e.g. with "ping -c 2 -6 www.cyberciti.biz". It only worked with ufw being disabled.

So I've resolved the issue (so far) by doing the following:
- remove iptables-persistent (sudo apt-get remove --purge netfilter-persistent) like mentioned in #3
- reset the firewall (ufw reset) (don't know if this and the following step are necessary)
- set your rules for ufw again
- reboot
- reinstall iptables-persistent (sudo apt-get install iptables-persistent)

Unfortunately I could NOT REPRODUCE this issue ever again. Neither by rebooting nor by enabling / disabling ufw or adding / removing any of the referenced packages.

Hope this helps.

Some technical data:
Linux server 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
Debian GNU/Linux 11 (bullseye)
ufw 0.36

[Jamie Strandboge (jdstrand)]

DSmidge and Christian, to be clear, iptables-persistent and netfilter-persistent are incompatible with ufw since the act of installing them activates them and when they are running they interfere with ufw (I think you knew that based on your comments though, so adding that here for clarity).

This comes up enough with these two pieces of software that I'm considering adding a Breaks to the Debian packaging.