Bug 1723 - Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE
Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in Open...
Status: CLOSED FIXED
Product: OpenVZ
Classification: Unclassified
Component: kernel
zzz-2.6.32-ovz-obsoleted
x86_64 (AMD64) Debian
: P2 major
Assigned To: Cyrill Gorcunov
: 1646 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-17 01:38 EST by Ola Lundqvist
Modified: 2015-03-20 05:36 EDT (History)
8 users (show)

See Also:


Attachments
UNTESTED, proposed patch for bug#1723 (642 bytes, patch)
2010-12-17 19:00 EST, Steven Chamberlain
Details | Diff
UNTESTED patch to use ve_printk in ip6t_LOG (10.72 KB, patch)
2010-12-17 19:13 EST, Steven Chamberlain
Details | Diff
UNTESTED patch to use ve_printk in ip6t_LOG (11.21 KB, patch)
2010-12-17 20:04 EST, Steven Chamberlain
Details | Diff
net, ip6tables: Allow to modify IPv6 netfliter rules inside the VE (13.07 KB, patch)
2010-12-20 13:32 EST, Cyrill Gorcunov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ola Lundqvist 2010-12-17 01:38:33 EST
Hi

This is a forward of a bug report in the Debian bugtracking system. It is onlt partly included below as the original one is rather long.

Please see http://bugs.debian.org/607041 for more relevant information.

Best regards,

// Ola

------ Part of original bug report in Debian bugtracking system below ----

Package: linux-image-2.6.32-5-openvz-amd64
Version: 2.6.32-29

Hi,

I noticed that on kernel 2.6.32-5-openvz-amd64 (Debian 2.6.32-29), the
amd64 build of ip6tables does not work at all in an OpenVZ VE, but the
i386 build does.  Within the OpenVZ host itself though (VE0), both
versions work.  So I'm inclined to say this is more likely a kernel/OpenVZ
bug than a bug in ip6tables.

IPv4 iptables works fine in all cases.

I tested this within a OpenVZ VE, which is an amd64 Debian lenny install,
with an i386 chroot inside of it:


# dpkg-query -Wf '${Package}-${Version}_${Architecture}\n' iptables
iptables-1.4.2-6_amd64

# ip6tables -L
FATAL: Could not load /lib/modules/2.6.32-5-openvz-amd64/modules.dep: No
such file or directory
ip6tables v1.4.2: can't initialize ip6tables table `filter': Permission
denied (you must be root)
Perhaps ip6tables or your kernel needs to be upgraded.


# chroot lenny-i386/ dpkg-query -Wf
'${Package}-${Version}_${Architecture}\n' iptables
iptables-1.4.2-6_i386

# chroot lenny-i386/ ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
...
Comment 1 Steven Chamberlain 2010-12-17 01:49:47 EST
Hi,

I also noticed that the ip6tables -j LOG target logs into the host node rather than the VE.  I think the IPv6 equivalent of the IPv4 log target has not been patched to do this.  At least in the current Debian openvz kernel.

Many thanks.
Comment 2 Pavel Emelyanov 2010-12-17 03:07:59 EST
What kernel is it? 2.6.26 or 2.6.32?
Comment 3 Steven Chamberlain 2010-12-17 03:10:04 EST
Oh I see, Ola set the wrong version when he copied the bug report here...

It's 2.6.32-5-openvz-amd64 (Debian 2.6.32-29)

My full bug report was at http://bugs.debian.org/607041

Thanks!
Comment 4 Pavel Emelyanov 2010-12-17 03:20:58 EST
Cyrill, plz, take a look.
Comment 5 Thorsten Schifferdecker 2010-12-17 04:21:28 EST
see bug #1348

*** This bug has been marked as a duplicate of bug 1348 ***
Comment 6 Steven Chamberlain 2010-12-17 04:27:40 EST
Hi,

I'm sorry I think this issue is different.

I did notice that bug #1348 while investigating this, but decided it was not the same, because:

* that related to much older 2.6.18
* the issue there was the *opposite* behaviour -- ip6tables was working when the container ran the native architecture, only broken when using ip6tables i386 on amd64 or vice-versa
* that issue was due to missing compat functions, but they exist now (and they work, hence i386 ip6tables does work on and amd64 host)
Comment 7 Steven Chamberlain 2010-12-17 19:00:32 EST
Created attachment 1333 [details]
UNTESTED, proposed patch for bug#1723

Hi,

My attached patch (UNTESTED) is my best guess at what's wrong here.  I figure that using i386 ip6tables on and amd64 host, the compat_ functions are used, and those correctly check for CAP_VE_NET_ADMIN.  Native ip6t_{get,set}_ctl were only checking for CAP_NET_ADMIN which I think is why an amd64 host could use ip6tables but an amd64 VE on that host couldn't.  My full Debian bug report included an strace showing getsockopt returning -EPERM and I think this was the reason.

I know very little about how OpenVZ works though, so I'd appreciate any advice on this.

I'll be testing this patch at my earliest opportunity to reboot this affected server.

Thanks.
Comment 8 Steven Chamberlain 2010-12-17 19:13:36 EST
Created attachment 1334 [details]
UNTESTED patch to use ve_printk in ip6t_LOG

Hi again,

Also attaching this patch (UNTESTED) for the other ip6tables issue I mentioned -- the ip6t_LOG target still using printk instead of ve_printk

And I patched one forgotten printk in the IPv4 ipt_LOG, for the packet MARK.

I'll test these at the same time as my patch for this bug #1723.
Comment 9 Steven Chamberlain 2010-12-17 19:52:43 EST
Hi,

Something that I'm still unsure of, is whether each of these functions should test for CAP_VE_NET_ADMIN, or if they should check for CAP_NET_ADMIN 'or' CAP_VE_NET_ADMIN.

Currently there are some differences:


compat_do_ipt_set_ctl:
if (!capable(CAP_NET_ADMIN) && !capable(CAP_VE_NET_ADMIN))

do_ipt_set_ctl:
if (!capable(CAP_NET_ADMIN) && !capable(CAP_VE_NET_ADMIN))

compat_do_ip6t_set_ctl:
if (!capable(CAP_VE_NET_ADMIN))

do_ip6t_set_ctl:
if (!capable(CAP_NET_ADMIN))


As far as I could tell, CAP_VE_NET_ADMIN was enough for it to work.  I don't know when CAP_NET_ADMIN might apply.
Comment 10 Steven Chamberlain 2010-12-17 20:04:48 EST
Created attachment 1335 [details]
UNTESTED patch to use ve_printk in ip6t_LOG

Fixed patch for ip6t_LOG, I forgot to add the VE_LOG parameter
Comment 11 Ola Lundqvist 2010-12-18 05:44:28 EST
(In reply to comment #10)
> Created attachment 1335 [details]
> UNTESTED patch to use ve_printk in ip6t_LOG
> 
> Fixed patch for ip6t_LOG, I forgot to add the VE_LOG parameter

Hi Steven

Should both patches be applied or only the latest?

// Ola
Comment 12 Steven Chamberlain 2010-12-18 05:53:36 EST
Hi,

This patch is intended to fix ip6tables:  http://bugzilla.openvz.org/attachment.cgi?id=1333

And this one should fix the ip6tables LOG target:  http://bugzilla.openvz.org/attachment.cgi?id=1335

I've not had a chance to test them.  They apply cleanly (in any order) and everything built okay, and I'll be rebooting that server in about... 16 hours to test both issues.

If they work, and if the OpenVZ developers think the changes are correct, both patches would be desirable for inclusion in Debian as well as OpenVZ's git repository.

Thanks!
Comment 13 Ola Lundqvist 2010-12-18 06:58:53 EST
Thanks Steven. I'll wait for your test then.
Comment 14 Cyrill Gorcunov 2010-12-18 08:46:31 EST
(In reply to comment #12)
> Hi,
> This patch is intended to fix ip6tables: 
> http://bugzilla.openvz.org/attachment.cgi?id=1333
> And this one should fix the ip6tables LOG target: 
> http://bugzilla.openvz.org/attachment.cgi?id=1335
> I've not had a chance to test them.  They apply cleanly (in any order) and
> everything built okay, and I'll be rebooting that server in about... 16 hours
> to test both issues.
> If they work, and if the OpenVZ developers think the changes are correct, both
> patches would be desirable for inclusion in Debian as well as OpenVZ's git
> repository.
> Thanks!

Thanks Steven! I'll check the patches on this weekend.
Comment 15 Steven Chamberlain 2010-12-19 06:06:06 EST
Hi,

It worked!  Both amd64 and i386 ip6tables work now inside VEs, and ip6tables still works on the amd64 host node too.

And with my second patch applied, the ip6t_LOG target works properly now inside VE's.

Issue #1646 appeared to be a duplicate of this.  (Also reported at http://bugs.debian.org/590321 against vzctl, but it was really a kernel bug).
Comment 16 Cyrill Gorcunov 2010-12-20 13:31:11 EST
(In reply to comment #15)
> Hi,
> 
> It worked!  Both amd64 and i386 ip6tables work now inside VEs, and ip6tables
> still works on the amd64 host node too.
> 
> And with my second patch applied, the ip6t_LOG target works properly now inside
> VE's.
> 
> Issue #1646 appeared to be a duplicate of this.  (Also reported at
> http://bugs.debian.org/590321 against vzctl, but it was really a kernel bug).

Steven, both patches look good to me, so I attach a single cumulative one
here instead. Patch is sent for review. Note that I've added you Signed-off-by line since the code came from you. If you not agree -- ping me and SOB will be
removed.

Thanks!
Comment 17 Cyrill Gorcunov 2010-12-20 13:32:08 EST
Created attachment 1339 [details]
net, ip6tables: Allow to modify IPv6 netfliter rules inside the VE
Comment 18 Steven Chamberlain 2010-12-20 20:17:52 EST
Hi Cyrill,

I'm happy with the cumulative patch you've uploaded, and agree to Sign-off on it.

Thank you very much!
Comment 19 Cyrill Gorcunov 2010-12-21 00:33:47 EST
(In reply to comment #18)
> Hi Cyrill,
> 
> I'm happy with the cumulative patch you've uploaded, and agree to Sign-off on
> it.
> 
> Thank you very much!

Thanks Steven!
Comment 20 Ola Lundqvist 2011-01-15 11:18:14 EST
*** Bug 1646 has been marked as a duplicate of this bug. ***
Comment 22 Ola Lundqvist 2011-01-27 01:06:14 EST
Debian kernel team contacted about this.
Comment 23 Kir Kolyshkin 2011-01-27 11:19:46 EST
There is a new test build for debian kernel with all the latest stuff from openvz git applied, you can give it a try. Below is a message from Max Attems:

added latest 07aaa2e9fb25 to 2.6.32-31 (no known upload schedule yet).

have a 2.6.32-31 build for testing here, ola or anyone?
http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb
http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb.sha512sum.asc
Comment 24 Stefan Priebe 2011-06-07 04:25:45 EDT
could it be that ip6table_mangle is still broken?
Comment 25 Cyrill Gorcunov 2011-06-07 04:33:54 EDT
(In reply to comment #24)
> could it be that ip6table_mangle is still broken?

What problem you've faced?
Comment 26 Stefan Priebe 2011-06-07 04:35:35 EDT
I've set up a 64bit HN node running 2.6.32 RHEL6 015.1.

ip6table_mangle is loaded:

~# lsmod | grep ip6table_mangle
ip6table_mangle         3159  0 
ip6_tables             14163  2 ip6table_mangle,ip6table_filter
ipv6                  250940  147 vzrst,ip6t_REJECT,ip6table_mangle

But it isn't usable in a container:
~# /sbin/ip6tables -N foo1X4051
~# /sbin/ip6tables -t mangle -F fooX4051
ip6tables: No chain/target/match by that name

I'm trying to get shorewall running - but it says that mangle isn't usable for
IPv6. It works fine for IPv4.
Comment 27 Cyrill Gorcunov 2011-06-07 04:38:19 EDT
(In reply to comment #26)
> I've set up a 64bit HN node running 2.6.32 RHEL6 015.1.
> 
> ip6table_mangle is loaded:
> 
> ~# lsmod | grep ip6table_mangle
> ip6table_mangle         3159  0 
> ip6_tables             14163  2 ip6table_mangle,ip6table_filter
> ipv6                  250940  147 vzrst,ip6t_REJECT,ip6table_mangle
> 
> But it isn't usable in a container:
> ~# /sbin/ip6tables -N foo1X4051
> ~# /sbin/ip6tables -t mangle -F fooX4051
> ip6tables: No chain/target/match by that name
> 
> I'm trying to get shorewall running - but it says that mangle isn't usable for
> IPv6. It works fine for IPv4.

ip6tables version please and ve.conf for container.
Comment 28 Stefan Priebe 2011-06-07 04:41:41 EDT
entered into CT 101
fw-office:/# ip6tables -V
ip6tables v1.4.2

cat /etc/vz/vz.conf

## Global parameters
VIRTUOZZO=yes
LOCKDIR=/vz/lock
DUMPDIR=/vz/dump
VE0CPUUNITS=1000

## Logging parameters
LOGGING=yes
LOGFILE=/var/log/vzctl.log
LOG_LEVEL=0
VERBOSE=0

## Disk quota parameters
DISK_QUOTA=no
VZFASTBOOT=yes

# The name of the device whose ip address will be used as source ip for VE.
# By default automatically assigned.
#VE_ROUTE_SRC_DEV="eth0"

# Controls which interfaces to send ARP requests and modify APR tables on.
NEIGHBOUR_DEVS=eth0

## Template parameters
TEMPLATE=/vz/template

## Defaults for VEs
VE_ROOT=/vz/root/$VEID
VE_PRIVATE=/vz/private/$VEID
CONFIGFILE="vps.basic"
DEF_OSTEMPLATE="fedora-core-4"

## Load vzwdog module
VZWDOG="no"

## IPv4 iptables kernel modules
IPTABLES="iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_conntrack ipt_state ipt_helper iptable_nat ip_nat_ftp ip_nat_irc ipt_REDIRECT"
##  ipt_MASQUERADE"

## Enable IPv6
IPV6="yes"

## IPv6 ip6tables kernel modules
IP6TABLES="ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT"



cat /etc/vz/conf/101.conf  

VERSION="2"
CLASSID="2"

KMEMSIZE="9223372036854775807:9223372036854775807"
LOCKEDPAGES="9223372036854775807:9223372036854775807"
PRIVVMPAGES="9223372036854775807:9223372036854775807"
SHMPAGES="9223372036854775807"
# NUMPROC: set to 32567:32567 (different to example D)
NUMPROC="32567"
PHYSPAGES="0:9223372036854775807"
# VMGUARPAGES: set as in ve-vps.1024MB.conf-sample (different to example D)
VMGUARPAGES="135168:9223372036854775807"
# OOMGUARPAGES: set as in ve-vps.1024MB.conf-sample (different to example D)
OOMGUARPAGES="104448:9223372036854775807"
NUMTCPSOCK="9223372036854775807"
# NUMFLOCK: set to 9223372036854775807:9223372036854775807 (different to example D)
NUMFLOCK="9223372036854775807:9223372036854775807"
NUMPTY="255"
NUMSIGINFO="1024"
# TCPSNDBUF: set to 9223372036854775807:9223372036854775807 (different to example D)
TCPSNDBUF="9223372036854775807:9223372036854775807"
# TCPRCVBUF: set to 9223372036854775807:9223372036854775807 (different to example D)
TCPRCVBUF="9223372036854775807:9223372036854775807"
OTHERSOCKBUF="9223372036854775807:9223372036854775807"
DGRAMRCVBUF="9223372036854775807:9223372036854775807"
NUMOTHERSOCK="9223372036854775807"
NUMFILE="9223372036854775807"
DCACHESIZE="9223372036854775807:9223372036854775807"
# NUMIPTENT: not mentioned in example D
NUMIPTENT="9223372036854775807"
# AVNUMPROC: not mentioned in example D
AVNUMPROC="32567"

# all following parameters: not mentioned in example D
CPUUNITS="500000"
CPULIMIT="0"
#DISKSPACE="9223372036854775807:9223372036854775807"
#VZCC does not accept 2^63-1 as maximum
DISKSPACE="4294967295:4294967295"
#DISKINODES="9223372036854775807:9223372036854775807"
#VZCC does not accept 2^63-1 as maximum
#VZCC reports DISKINODES in red zone if set to 4294967295
DISKINODES="2147483647:2147483647"
#QUOTATIME="9223372036854775807"
QUOTATIME="2147483647"
QUOTAUGIDLIMIT="200"
OFFLINE_MANAGEMENT="yes"
ONBOOT="yes"
FEATURES="sysfs:on "
CAPABILITY="NET_ADMIN:on SYS_CHROOT:on SYS_TIME:on "
VE_ROOT="/vz/root/$VEID"
VE_PRIVATE="/vz/private/$VEID"
OSTEMPLATE="debian-5.0-x86-minimal"
ORIGIN_SAMPLE="openvz-cluster"
IP_ADDRESS=""
HOSTNAME="XXX"
NAMESERVER="XXX"
NETIF="ifname=eth0,bridge=vzbr0,mac=00:18:51:0E:04:58,host_ifname=veth101.0,host_mac=00:18:51:D3:43:64;ifname=eth2,bridge=vzbr2,mac=00:18:51:76:82:9F,host_ifname=veth101.2,host_mac=00:18:51:9E:80:2D;ifname=eth3,bridge=vzbr3,mac=00:18:51:95:9D:A7,host_ifname=veth101.3,host_mac=00:18:51:A9:27:6E;ifname=eth4,bridge=vzbr4,mac=00:18:51:A8:5F:42,host_ifname=veth101.4,host_mac=00:18:51:69:23:F0"
DEVICES="c:10:200:rw "
Comment 29 Cyrill Gorcunov 2011-06-07 04:46:10 EDT
ok, vzctl version please ;)
Comment 30 Stefan Priebe 2011-06-07 04:48:35 EDT
~# vzctl --version
vzctl version 3.0.26.3
Comment 31 Cyrill Gorcunov 2011-06-07 04:52:31 EDT
(In reply to comment #30)
> ~# vzctl --version
> vzctl version 3.0.26.3

Thanks, I'll check.
Comment 32 Stefan Priebe 2011-06-07 05:09:39 EDT
Thank you too ;-) If you need more informations - please ask. I also tested a 64bit container doesn't make any difference.
Comment 33 Steven Chamberlain 2011-06-07 10:03:43 EDT
For what it's worth, I can't reproduce that issue on 64-bit Debian 2.6.32-34squeeze1, vzctl version 3.0.24, with either a 32- or 64-bit userland in the VE.

All of these operations seemed to work as expected for me:

ip6tables -t mangle -N TEST
ip6tables -t mangle -A TEST -j RETURN
ip6tables -t mangle -L
ip6tables -t mangle -D TEST -j RETURN
ip6tables -t mangle -F TEST
ip6tables -t mangle -X TEST
ip6tables -t mangle -L

I don't have either of these in my ve.conf though:

FEATURES="sysfs:on "
CAPABILITY="NET_ADMIN:on SYS_CHROOT:on SYS_TIME:on "



...aahha!  Just noticed something funny...  Stefan, could you check this:

> ~# /sbin/ip6tables -N foo1X4051
> ~# /sbin/ip6tables -t mangle -F fooX4051
> ip6tables: No chain/target/match by that name

Surely that added foo1X4051 to the wrong table (to the default table '-t filter' instead), and it should have been this:
# ip6tables -t mangle -Nfoo1X4051

Otherwise, maybe 'ip6tables -L' with '-t filter' and '-t mangle' might show something.
Comment 34 Cyrill Gorcunov 2011-06-07 10:10:49 EDT
(In reply to comment #33)
> For what it's worth, I can't reproduce that issue on 64-bit Debian
> 2.6.32-34squeeze1, vzctl version 3.0.24, with either a 32- or 64-bit userland
> in the VE.
> 
> All of these operations seemed to work as expected for me:
> 
> ip6tables -t mangle -N TEST
> ip6tables -t mangle -A TEST -j RETURN
> ip6tables -t mangle -L
> ip6tables -t mangle -D TEST -j RETURN
> ip6tables -t mangle -F TEST
> ip6tables -t mangle -X TEST
> ip6tables -t mangle -L
> 
> I don't have either of these in my ve.conf though:
> 
> FEATURES="sysfs:on "
> CAPABILITY="NET_ADMIN:on SYS_CHROOT:on SYS_TIME:on "

The container access without NET_ADMIN:on will be patched (I already noticed this miss).

> 
> 
> 
> ...aahha!  Just noticed something funny...  Stefan, could you check this:
> 
> > ~# /sbin/ip6tables -N foo1X4051
> > ~# /sbin/ip6tables -t mangle -F fooX4051
> > ip6tables: No chain/target/match by that name
> 
> Surely that added foo1X4051 to the wrong table (to the default table '-t
> filter' instead), and it should have been this:
> # ip6tables -t mangle -Nfoo1X4051
> 
> Otherwise, maybe 'ip6tables -L' with '-t filter' and '-t mangle' might show
> something.

Ouch, I somehow missed ip6tables options messed in first place ;)
So... Is there error at all (since from kernel sources except permissions
I don't see problems yet). Hm?
Comment 35 Stefan Priebe 2011-06-07 10:28:03 EDT
Oh man really crazy *uff*. I got the output from shorewall and messed it up.

I now started a more specific session. So i'm really really sorry for that.

# /etc/init.d/shorewall6 start
Starting "Shorewall6 firewall": not done (check /var/log/shorewall6-init.log).

Jun  7 16:23:43    ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system
   ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system

Shorewall is executing the following stuff to determine this sitation:
/sbin/ip6tables -L shorewall -n
/sbin/ip6tables -N fooX8608
/sbin/ip6tables -N foo1X8608
/sbin/ip6tables -A fooX8608 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
/sbin/ip6tables -A fooX8608 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/ip6tables -F fooX8608
/sbin/ip6tables -X fooX8608
/sbin/ip6tables -F foo1X8608
/sbin/ip6tables -X foo1X8608
/sbin/ip6tables -t mangle -F fooX8608
/sbin/ip6tables -t mangle -X fooX8608

What fails isn't mangle it's the state and conntrack ;-( 
~/# /sbin/ip6tables -N fooX8608
~/# /sbin/ip6tables -A fooX8608 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables: Invalid argument
~/# /sbin/ip6tables -A fooX8608 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables: Invalid argument

But these commands work fine on HN.

~#: lsmod|grep state
xt_state                1327  0 
nf_conntrack           44151  11 vzrst,nf_nat_irc,nf_nat_ftp,iptable_nat,xt_helper,xt_state,xt_conntrack,nf_conntrack_irc,nf_conntrack_ftp,nf_nat,nf_conntrack_ipv4
x_tables               12862  21 ip6t_REJECT,ip6_tables,xt_tcpudp,ipt_REDIRECT,iptable_nat,xt_helper,xt_state,xt_conntrack,xt_length,ipt_LOG,xt_hl,xt_tcpmss,xt_TCPMSS,ipt_REJECT,xt_DSCP,xt_dscp,xt_multiport,xt_limit,ip_tables,xt_mac,ipt_MASQUERADE
Comment 36 Cyrill Gorcunov 2011-06-07 10:33:43 EDT
(In reply to comment #35)
> Oh man really crazy *uff*. I got the output from shorewall and messed it up.
> 
> I now started a more specific session. So i'm really really sorry for that.
> 

ok, no problem ;)

> # /etc/init.d/shorewall6 start
...

Will check, this is different issue.
Comment 37 Stefan Priebe 2011-06-07 10:40:30 EDT
Thanks Cyrill and i'm really really sorry.
Comment 38 Cyrill Gorcunov 2011-06-07 10:49:57 EDT
(In reply to comment #37)
> Thanks Cyrill and i'm really really sorry.

no problem, don't worry ;)
Comment 39 Sergey Bronnikov 2015-03-20 05:36:07 EDT
Bug was fixed more than one year ago and there were no complains from reporter after fix. We believe bug fix helped and mark bug as closed.