Hardy ufw works on kernel 2.6.31.5, bombs on 2.6.32
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 nfconntrackftp not found.
FATAL: Module nfnatftp not found.
FATAL: Module nfconntrackirc not found.
FATAL: Module nfnatirc 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.
11 Replies
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
I'll check it out. Looks like a pain, though.
@mnordhoff:
I'll check it out. Looks like a pain, though.
:P
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 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.
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.
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.
Now when I boot I see these four lines (same is original post):
FATAL: Module nfconntrackftp not found.
FATAL: Module nfnatftp not found.
FATAL: Module nfconntrackirc not found.
FATAL: Module nfnatirc 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?
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.
@warewolf:
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 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?
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?