Comment 6 for bug 513387

I know the problem, and it was introduced in the fix for bug #459925. What is happening is that ufw now adds stuff to the top of user.rules to make sure that logging state is setup when running /lib/ufw/ufw-init, like on boot. Eg:

In user.rules:
*filter
...
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-logging-forward - [0:0]
...

When we iptables-restore this file, it creates the above 3 logging chains. The problem is that in /lib/ufw/ufw-init-functions we call iptables-restore on user.rules before this:
# setup ufw${type}-after-logging-* chains
if ! $exe -L ufw${type}-after-logging-input -n >/dev/null 2>&1 ; then
  $exe -N ufw${type}-after-logging-input || error="yes"
  $exe -N ufw${type}-after-logging-output || error="yes"
  $exe -N ufw${type}-after-logging-forward || error="yes"
  $exe -A INPUT -j ufw${type}-after-logging-input || error="yes"
  $exe -A OUTPUT -j ufw${type}-after-logging-output || error="yes"
  $exe -A FORWARD -j ufw${type}-after-logging-forward || error="yes"
fi

Therefore the after-logging chains already exist and are not added to the builtin chains. This is a regression in 0.29.1 over 0.29.

The fix is simply to move all the iptables-restore blocks to the end of ufw_start().