Just wanted to let you know that, although this article is a few years old now, this same problem cropped up again after a recent update! Thankfully, this little hackish fix once again solved the problem for me! It cracks me up when I search for a problem on Google, hastily click a link that seems relevant, and then realize the page loading is MY OWN!!! haha. It’s happened once or twice before and it’s still a pretty strange experience, ha.
Just FYI, I’m still using the same Debian server, just a few major releases newer. At some point this problem wasn’t happening and the stock init.d file was fine (yes, Debian has since moved to systemd, but Vuurmuur was still starting via it’s init.d service file under systemd). I’m not sure even how I ended up re-installing Vuurmuur at this point, from source of from a 3rd party Apt repo… I would have to dig thru years of crud in my server’s CHANGELOG to be sure. I seem to recall they released an update that fixed this problem, replacing my previously edited init file. Not quite sure, and maybe I’ll research this issue deeper in the coming days, but for now I’m happy it’s working and happy I chose to save this fix! :P
After receiving a large number of emails from log-check today notifying me of iptables problems I ssh’d in to my server to investigate and found that my trusty (but sadly under-maintained) firewall daemon, Vuurmuur, was failing to start propery! I immediately thought of the most likely cause of the problem (and the cause of most problems encountered when using a program that doesn’t have an officially sanctioned package); a recent system update…
I gather that the long depreciated in-kernel support for conntrack (used by the dated Vuurmuur 0.7 package) has finally had it’s support removed from the latest Linux kernel, or at least no longer compiled in to Debian’s stock kernel. I honestly didn’t research this properly yet… too busy solving the problem, haha. Although Vuurmuur appears to have support for the stand-alone conntrack-tool, it would seem a bug in 0.7 prevents it from using the binary properly. Thus this issue arose after updating.
The quick and dirty fix I found for this problem was pretty simple, just two changes in the init script! [note: this applies to Debian, but should help point anyone else in the right direction too… ‘right’ meaning ‘quick and dirty’, of course].
On Debian, open up the file /etc/init.d/vuurmuur
Comment out the old MODULES_TO_LOAD line and add:
Then, where it launched the daemon, add the ‘-t’ switch so that it reads:
$VUURMUUR_LOCATION/vuurmuur -D -t
which tells it to NOT perform any of the iptable checks when launching the daemon.
Again, this is quick and dirty solution to the problem, and if you aren’t using Vuurmuur from the 3rd party apt source like I am, it’s mostly just a matter of running it with that ‘-t’ command.
Why do I put up with such an out-dated program? Because Vuurmuur is pure minimalist bliss for maintaining iptables rules! Vuurmuur has quite a cult following despite it’s age and being somewhat abandoned, but in it’s defense, aside from a few warts, it’s a rock-solid and well made program that makes like much easier for those of us that hate maintaining a complex iptables script manually and don’t want to run some bloated server-training-wheels suite. Personally I think it should be a standard Linux tool, but maybe I’m biased and spoiled by it a bit.
Anyways, I’m sure this isn’t the most elegant solution, but it works, none the less. Hope this helps someone else out there!
I realize this isn’t the most flattering way to support vuurmuur, but if your interested in learning more about it visit their website here: http://www.vuurmuur.org/trac/