ufw: default IPv6 policy not set on boot when IPV6=no

Thank you for using Ubuntu and taking the time to report a bug. Enabling IPv6 by default at this point in time is IMO not a good idea generally, as it is not in widespread use. IPv6 users can easily enable it if needed. This issue can of course be revisited when IPv6 is more widely deployed.

When IPv6=no, and a user runs 'ufw enable' (perhaps running disable before), the chains are default DROP as stated in the documentation. However, there is a bug in the initscript that doesn't set IPv6 up correctly on boot. This will be addressed in a future release.

IPv6 is enabled by default in Ubuntu *in general* though.

What I did:
sudo ufw enable
sudo ufw default deny
iptables -nL
ip6tables -nL

iptables shows DROP on in and forward. ip6tables shows ALLOW on all.

Then:
Edit the /etc/default/ufw to say IPV6=yes
ip6tables -nL

DROP on inbound and forward. ALLOW on out.

Is it intentional as documented in the manpage, or is it a bug as implied in /etc/default/ufw? They disagree on what this line does.

The intent is to have default IPV6=no. With this setting, only IPV6 on loopback is accepted, otherwise DROP. the 'ufw enable' command does do this properly, but the bug is that /etc/init.d/ufw does not, so on reboot you get default ACCEPT rather than the documented (and intended) default DROP with allowed loopback.

SRU Request

I. ufw in it's default configuration uses IPV6=no in /etc/default/ufw. The intended and documented behavior of this setting is to use a default DROP policy with connections allowed on the loopback interface only. The current version does not do this when using the /etc/init.d/ufw script, which means that though IPV6=no, the default policy for the INPUT, OUTPUT and FORWARD chains is ACCEPT on boot.

II. this has been fixed in 0.18.2 (will be uploaded after alpha freeze). /etc/init.d/ufw has been adjusted to set the default policy of DROP when IPV6=no (/usr/sbin/ufw uses the /etc/init.d/ufw when running 'enable', so enable will still work as before).

III. debdiff is attached that addresses this bug and bug #194844 (also SRU candidate)

IV. TEST CASE (need a kernel which supports ipv6 and ip6_tables (basically, any but -virtual):

  1. make sure /etc/default/ufw has 'IPV6=no'
  2. sudo ufw enable
  3. sudo ip6tables -n -L (shows default DROP policy with allowed connections on loopback)
  4. sudo /etc/init.d/ufw force-reload
  5. sudo ip6tables -n -L (shows default ACCEPT policy, should be same as in step 3)

V. The regression potential is considered low. While the default behavior on boot has changed (to be what is documented), in practice users will have used 'ufw enable' to enable the firewall and tested that the rules work as expected. 'ufw enable' sets the default policy to DROP, so user's would have noticed IPv6 connectivity being blocked at this stage, and adjusted the rules accordingly. It was only after a reboot that the IPv6 policy is changed to the more lenient ACCEPT policy.

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package ufw - 0.18.2

---------------
ufw (0.18.2) intrepid; urgency=low

  * fix confusing error output when ipv6 or ip6_tables is not available.
    Patch from trunk. (LP: #194844)
  * fix initscript not setting default ipv6 policy when IPV6=no (LP: #251355)
  * update ucf checksums to include those from 0.16.2
  * bump version

 -- Jamie Strandboge <email address hidden> Fri, 11 Jul 2008 18:38:58 -0400

Confirmed 0.16.2.3 fixes the above test case. Also, using IPV6=yes continues to work as expected (ie ufw6-* chains are all appropriately added) as does the /etc/init.d/ufw exiting appropriately when ufw is disabled via 'sudo ufw disable'.

Confirmed fixed on a freshly updated 8.04.1 amd64 install, thanks.

(Mackenzie and I noticed this one while at HOPE.)

Copied to hardy-updates.