# iptables --version
iptables v1.4.8
the machine is running Debian 6 with some Debian 7 packages including
shorewall, but I can't upgrade iptables to the Debian 6 version without
also upgrading a bunch of system libraries. As its a Xen VPS at a hosting
company I'm reluctant to do that. Wheezy has
On 9/4/2013 6:22 PM, Steve Wray wrote:
> I'm getting this in a case where there is no ip6tables in use. Is there
> a workaround for this? Its using the Shorewall from Debian stable.
>
> # shorewall version
> 4.5.5.3
>
> # shorewall try /etc/shorewall
> ...
>ERROR: Log level INFO requires LOG
I'm getting this in a case where there is no ip6tables in use. Is there a
workaround for this? Its using the Shorewall from Debian stable.
# shorewall version
4.5.5.3
# shorewall try /etc/shorewall
...
ERROR: Log level INFO requires LOG Target in your kernel and iptables
# uname -a
Linux hk2s
On 09/04/2013 08:20 AM, Mau wrote:
> Hi Thomas,
>
> Il 04/09/2013 14:02, Thomas D. ha scritto:
>> [...]
>>
>> shorewall is unable to start because some iptables modules aren't yet
>> ready. Keep in mind: shorewall was up an running before... without any
>> problems:
>>
>>>ERROR: Log level INFO
Hi Thomas,
Il 04/09/2013 14:02, Thomas D. ha scritto:
> [...]
>
> shorewall is unable to start because some iptables modules aren't yet
> ready. Keep in mind: shorewall was up an running before... without any
> problems:
>
>>ERROR: Log level INFO requires LOG Target in your kernel and iptables
On 8/30/2013 7:39 PM, Tom Eastep wrote:
On 8/30/2013 3:24 PM, Thomas Harold wrote:
Questions at this point:
http://shorewall.net/MultiISP.html
#1 Where do variables like SW_ETH0_GATEWAY and SW_ETH0_ADDRESS get defined?
They get defined by the function 'detect_configuration' in the generated
Hi,
good question.
First, I am not sure if I experience the same problem:
On my Gentoo test systems with shorewall-4.5.19 and shorewall-4.5.20
(not yet in tree), both require iptables-1.4.20, I don't see a problem
on boot with shorewall-init (not yet in tree, too) nor shorewall itself
(the test
I made some interesting finds I'd like to share.
iptables 1.4.20 introduced a new locking mechanism to avoid failures
during concurrent invocations [1]; a -w option has been introduced in
order to have iptables wait until lock is released, and it seems that
the issue can be solved by enabling that
