Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1407
Control: severity -1 normal
Hi Christoph,
I'm quoting a email from Jamie Strandboge, who is both the
maintainer in Debian and the creator of ufw, and has kindly replied my
question about this bug:
[quote]
...
These rules were not generated by ufw. The current released version of
ufw does not do any management of the nat table. Furthermore,
iptables-restore rules in /etc/ufw/*rules do not contain any '-F's.
...
Now, the 'ufw-framework' man page documents how someone can adjust
/etc/ufw/{before,after}{,6}.rules files to customize the firewall with
iptables-restore directives for things that the ufw cli command does not
expose and it is not uncommon for people to add things to other tables.
The man page does *not* document use of -F in these files and instead
has examples like:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
COMMIT
So I suspect what happened is the reporter used this mechanism to
customize the firewall and accidentally added the second, errant -F.
[/quote]
In any case, the bug exists and it has been reported upstream.
After some test, it seems that the problem is related to the flush of
the rules after adding some of them (do you really want to do that?),
because the next ruleset works well:
*nat
-F PREROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-F POSTROUTING
COMMIT
And the same result will be obtained with:
*nat
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
COMMIT
Because the default iptables-restore behaviour is to flush (delete)
all previous contents of the respective tables.
I think you can workaround the bug rewriting your rules with special
care in the inclusion of '-F' rules.
I think it is correct that the error was initially reported with grave
severity, but after this analysis I think it is appropriate to lower
the severity to normal unless the segfault is discovered in a more
general case.
Regards,
Alberto
