I run ufw 0.16.2.4 on 32-bit Ubuntu Hardy. I've been happily using it for a while now, over several kernels, but for some reason, 2.6.32 just does not like it:

mnordhoff@ubuntu:~$ sudo ufw enable
ERROR: problem running init script

And then it eats *all* traffic until I disable it again. (Honestly, IIRC it even blocks localhost.)

Seriously, if I reboot into 2.6.31.5, it'll work; 2.6.32 again and it won't. No other changes to the system between this.

This is on a more-or-less virgin node, with bog-standard /etc/ufw/* and really trivial /var/lib/ufw/* (just TCP 22 and UDP 123).

The only change I've made is enabling IPv6 in /etc/default/ufw. Notably, if I disable it again, it no longer eats my traffic, but it's otherwise exactly the same, including the error messages.

I spent some time trying to track this down, and this is all I got:

mnordhoff@ubuntu:~$ sudo /etc/init.d/ufw restart
* Stopping firewall: ufw... [ OK ]
* Starting firewall: ufw... FATAL: Module nf_conntrack_ftp not found.
FATAL: Module nf_nat_ftp not found.
FATAL: Module nf_conntrack_irc not found.
FATAL: Module nf_nat_irc not found.
iptables-restore: line 71 failed
* Problem running '/etc/ufw/before.rules'... [fail]

Line 71 is the last line of the file -- COMMIT.

(BTW, stopping it from trying to load those modules (they're compiled in on Linode) does remove those "FATAL"s but doesn't change anything else.)

So... any ideas?

Edit: Also, my experience is the same on my not-at-all-virgin production node. Obviously, I didn't do any of the testing there, since it needs networking, but still.

Hmm, I suppose it's most likely an iptables<->kernel problem than ufw, specific since obviously the ufw-created files and the iptables binary that parses them hasn't changed.

iptables did have a release (1.4.6) for 2.6.32 "features", but that's not unusual, so no automatic reason to expect older versions to have issues. But perhaps hardy's iptables is old enough (not even in the 1.4.x series) that something finally got changed that accidentally caused an incompatibility.

I suppose you could try building a local version of iptables 1.4.6 to see if that works differently with the same ufw filter chain. Either that, or manually run the commands in ufw's before.rules one by one to see which one iptables rejects. Probably want to do that over a LISH console

As it happens, the first Linode (also Ubuntu Hardy) I just recently brought up under 2.6.32 was when I switched from ufw to firehol, and haven't encountered any issues. While I know it doesn't address your root question, you might give that a shot just to see if you still have an issue. I chose firehol after looking around a bit to find something for consistent use across more than Ubuntu systems but without wanting anything overly complex, or requiring a GUI to configure.

Of course, if the problem is the kernel interface for a specific filtering feature you are using, in theory any user space tool creating the same filter chain should have the same problem. But firehol constructs the chain differently than ufw, so maybe a different tool would manage to skirt by the problem.

-- David

Heh, it's totally obvious, but I didn't think of it being an iptables issue.

I'll check it out. Looks like a pain, though.

Given that it's unclear just what's failing, it certainly could be.

A quick try with firehol might not be too bad though - given that you're starting from ufw (as I was). Unless you've customized the system default rules or bypassed the ufw command line, odds are that translating your rules to firehol would be fairly trivial. Complicated is no problem for firehol either, but the translation process might be more work. For me, I was using ufw in the first case because it was simple for a basic list of trusted sources or for primary services.

Getting slightly off topic for a ufw-named thread, but a firehol config for a basic setup like ufw supports is also pretty simple - here's one (/etc/firehol.conf) I'm currently using on my 2.6.32 box to permit general web and ftp access to anyone, but anything from trusted source addresses or originating on the node itself.

#!/sbin/firehol

version 5

# Everything built-into the kernel with Linode
FIREHOL_LOAD_KERNEL_MODULES=0

#
# Trusted hosts:
#

TRUSTED="x.y.z.w a.b.c.d e.f.g.h"

#
# Public interface
#

interface eth0 public src not "${UNROUTABLE_IPS}" dst #.#.#.# 
        policy drop
        protection strong

        server icmp accept
        server http accept
        server ftp accept
        server all accept src "${TRUSTED}"

        client all accept

Technically you don't need the "src" and "dst" qualifiers on the interface (#.#.#.# is my public Linode address), it just locks inbound stuff down even a bit further.

Edit /etc/default/firehol to enable, and it'll get installed at startup just like ufw. The above is currently running on a 2.6.32-linode23 host with the stock firehol package in hardy (1.256-3).

-- David

The same behavior occurs with kernel 2.6.32-x86_64 on Ubuntu hardy.

The line 71 error is caused by these lines:

# connection tracking rules
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets
# uncomment to log INVALID packets
-A ufw-before-input -m conntrack --ctstate INVALID -j LOG --log-prefix "[UFW BLOCK INVALID]: "
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP


Given that these fail I've not tried to determine why localhost gets blocked.

node_tux++. Thanks for doing the research I didn't!

So...the problem is conntrack? That narrows it down a lot, and it shouldn't be hard to remove conntracking completely, if necessary.

FWIW, there were no conntrack-related changes to Linode's kernel configuration. Presumably something changed in the kernel itself.

Edit: There were, of course, lots of netfilter and conntrack-related changes in 2.6.32 and even later 2.6.31.x kernels. Whee.

To fix this problem with conntrack you need to switch to the newer iptables module "state".

simply run this against your iptables config file:

perl -pi -e 's/conntrack/state/g' iptables
perl -pi -e 's/ctstate/state/g' iptables

and then try loading that config.

I just deployed a fresh Ubuntu 10.04 and installed all the basics (Apache/MySQL/PHP), and UFW. No fancy changes were made.

Now when I boot I see these four lines (same is original post):

FATAL: Module nf_conntrack_ftp not found.
FATAL: Module nf_nat_ftp not found.
FATAL: Module nf_conntrack_irc not found.
FATAL: Module nf_nat_irc not found.

The solution offered above did not work for me. My IPT section in /etc/default/ufw looks like this:

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

# extra connection tracking modules to load
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc"

So only "conntrack" could be substituted with "state". The warnings when booting remained, except now with "state" instead of "conntrack".

I understand this has something to do with IP4 v. IP6 and what modules to load on boot time, but I still have no clue how to solve this. Any suggestions?

@Arjan:

No, the module bit was not the main issue. It's just because Linode kernels compile all of those things in, so it's impossible to load them as modules -- they already are loaded. You should comment out the last line of /etc/default/ufw or just live with it; the error messages are doing no harm.

_________________
Matt Nordhoff (aka Peng on IRC)

Thanks, that helped. I wasn't sure if it was only a warning or something actually failed.

I upgrade from 8.04 to 10.04 and got the same issue. Have anyone solved the issue? I saved my iptable, but try it above, don't work. Also I disabled the conntrack rule in ufw, also don't work. Any thought?
[/quote]

@MelodyTouch:

Did you actually make those adjustments (replacing "conntrack" and "ctstate" with "state") in all of ufw's configuration files, in both /etc/ufw and /var/lib/ufw?

What error message are you getting?

_________________
Matt Nordhoff (aka Peng on IRC)