[Shorewall-users] ERROR: Log level INFO requires LOG Target in your kernel and iptables

[Mau]

Hi,

I have 2 Debian testing boxes running a very similar setup (both running
the latest aptosid kernel); on one of them, since the
iptables/libxtables10 packages have been upgraded from 1.4.19.1-1 to
1.4.20-2, shorewall-init can't start shorewall anymore and for this
reason ifupdown also fails triggering firewall up.

Shorewall can be successfully started later on, and ifupdown starts
working too; in /var/log/shorewall-init.log I found a possible reason:

[...]
Aug 30 14:07:32 Shorewall up triggered by lo
Aug 30 14:07:32 Shorewall up triggered by lo
Aug 30 14:07:32 Shorewall up triggered by --all
Aug 30 14:07:36 Processing /etc/shorewall/params ...
Aug 30 14:07:36 Processing /etc/shorewall/shorewall.conf...
Aug 30 14:07:36 Loading Modules...
---> Aug 30 14:07:37 ERROR: Log level INFO requires LOG Target in
your kernel and iptables
Aug 30 14:09:28 Shorewall up triggered by wlan0
Aug 30 14:09:28 up on interface wlan0 ignored
[...]

Trying to downgrade iptables to the previous version seems to fix the issue.

Oddly enough, the other box works perfectly even with the new version of
iptables, and shorewall6 doesn't seem affected on both boxes.

Do you have any hint?

Thanks


Maurizio

[Mau]

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 feature.

I'd like to file a bug report, but I'm wondering whether to file it
against shorewall or against iptables, since its locking/wait mechanism
should probably be enabled by default in order to ensure the iptables
command will really do what is expected to. Any opinions?

Thanks,


Maurizio


[1]
http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

http://git.netfilter.org/iptables/commit/?id=d7aeda5ed45ac7ca959f12180690caa371b5b14b

[Thomas D.]

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 systems have both, IPv4 and IPv6 connection, so I am using
shorewall and shorewall6).

But: If I restart an interface (/etc/init.d/net.eth0 restart), Gentoo
will first stop all depending services, which include shorewall and
shorewall6, bring down the interface, bring up the interface again and
will finally start the previous stopped depending services (=shorewall
and shorewall6) again.

That's the point where I see a failure like yours, sometimes:

shorewall is unable to start because some iptables modules aren't yet
ready. Keep in mind: shorewall was up an running before... without any

# /etc/init.d/net.eth0 restart
* Caching service dependencies ... [ ok ]
* Stopping shorewall6 ... [ ok ]
* Stopping shorewall ... [ ok ]
* Stopping nginx ... [ ok ]
* Unmounting network filesystems ... [ ok ]
* Stopping distccd ... [ ok ]
* Stopping sshd ... [ ok ]
* Bringing down interface eth0
* Running postdown ...
* Removing outgoing IPv6 settings [ ok ]
* Bringing up interface eth0
* Waiting for carrier (10 seconds) ... [ ok ]
* XXX.XXX.XXX.XX1/27 ... [ ok ]
* XXX.XXX.XXX.XX2/29 ... [ ok ]
* XXX.XXX.XXX.XX3/29 ... [ ok ]
* XXX.XXX.XXX.XX4/29 ... [ ok ]
* XXX.XXX.XXX.XX5/29 ... [ ok ]
* XXX.XXX.XXX.XX6/29 ... [ ok ]
* XXX.XXX.XXX.XX7/29 ... [ ok ]
* XXX.XXX.XXX.XX8/29 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::1/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::2/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::3/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::4/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::5/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::6/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::7/64 ... [ ok ]
* ZZZZ:ZZZZ:ZZZZ:ZZZZ::8/64 ... [ ok ]
* Adding routes
* default via XXX.XXX.XXX.254 src XXX.XXX.XXX.XX1 ... [ ok ]
* default via fe80::1 ... [ ok ]
* Waiting for IPv6 addresses ... [ ok ]
* Running postup ...
* Setting label for ZZZZ:ZZZZ:ZZZZ:ZZZZ::1/64
* Setting outgoing IPv6 to ZZZZ:ZZZZ:ZZZZ:ZZZZ::5
* Starting distccd ...
* Starting shorewall6 ...
* Starting shorewall ...
* Mounting network filesystems ... [ ok ]
* Checking nginx' configuration ...
* Starting sshd ... [ ok ]
* Starting nginx ... [ ok ]
ERROR: Log level INFO requires LOG Target in your kernel and iptables [ !! ]
* ERROR: shorewall6 failed to start
ERROR: UNTRACKED state requires Raw Table in your kernel and iptables [ !! ]
* ERROR: shorewall failed to start

I can immediately start shorewall manually (/etc/init.d/shorewall start)
and it will start without any problems. So this looks like a timing
issue, right.

Is this the same you are talking about?


-Thomas

[Mau]

Hi Thomas,

Post by Thomas D.
[...]
shorewall is unable to start because some iptables modules aren't yet
ready. Keep in mind: shorewall was up an running before... without any

ERROR: Log level INFO requires LOG Target in your kernel and iptables [ !! ]
* ERROR: shorewall6 failed to start
ERROR: UNTRACKED state requires Raw Table in your kernel and iptables [ !! ]
* ERROR: shorewall failed to start

The failing modules are exactly the same as here, ipt_LOG (xt_LOG) and
iptable_raw; in my case the firewall fails at boot, while later it
behaves normally; pre-loading those modules at boot doesn't help, and
since I have both shorewall and shorewall6, sometimes fails the first,
sometimes the second. It took me some time to figure out what was
happening the first time I booted and the network didn't work.

I'm testing 3.11 kernel now: all the same. Weird.

Post by Thomas D.
I can immediately start shorewall manually (/etc/init.d/shorewall start)
and it will start without any problems. So this looks like a timing
issue, right.
Is this the same you are talking about?
-Thomas

It looks the very same problem to me.


Maurizio

[Tom Eastep]

Post by Mau
Hi Thomas,

Post by Thomas D.
[...]
shorewall is unable to start because some iptables modules aren't yet
ready. Keep in mind: shorewall was up an running before... without any

ERROR: Log level INFO requires LOG Target in your kernel and iptables [ !! ]
* ERROR: shorewall6 failed to start
ERROR: UNTRACKED state requires Raw Table in your kernel and iptables [ !! ]
* ERROR: shorewall failed to start

The failing modules are exactly the same as here, ipt_LOG (xt_LOG) and
iptable_raw; in my case the firewall fails at boot, while later it
behaves normally; pre-loading those modules at boot doesn't help, and
since I have both shorewall and shorewall6, sometimes fails the first,
sometimes the second. It took me some time to figure out what was
happening the first time I booted and the network didn't work.
I'm testing 3.11 kernel now: all the same. Weird.

Post by Thomas D.
I can immediately start shorewall manually (/etc/init.d/shorewall start)
and it will start without any problems. So this looks like a timing
issue, right.
Is this the same you are talking about?
-Thomas

It looks the very same problem to me.

The new locking code in ip[6]tables 1.4.20 prevents iptables and
ip6tables from running simultaneously unless the -w option is specified
on both. You can work around this problem temporarily by using a
capabilties file:

shorewall show -f capabilities > /etc/shorewall/capabilities
shorewall6 show -f capabilities > /etc/shorewall6/capabilities

I'll have a patch to the compiler available in a day or so.

-Tom

[Steve Wray]

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 hk2server 3.4.0-cloud #1 SMP Thu May 24 05:12:36 EDT 2012 i686
GNU/Linux

Post by Mau
Hi Thomas,

Post by Thomas D.
[...]
shorewall is unable to start because some iptables modules aren't yet
ready. Keep in mind: shorewall was up an running before... without any

ERROR: Log level INFO requires LOG Target in your kernel and

iptables [ !! ]

Post by Mau

Post by Thomas D.

* ERROR: shorewall6 failed to start
ERROR: UNTRACKED state requires Raw Table in your kernel and

iptables [ !! ]

Post by Mau

Post by Thomas D.

* ERROR: shorewall failed to start

The failing modules are exactly the same as here, ipt_LOG (xt_LOG) and
iptable_raw; in my case the firewall fails at boot, while later it
behaves normally; pre-loading those modules at boot doesn't help, and
since I have both shorewall and shorewall6, sometimes fails the first,
sometimes the second. It took me some time to figure out what was
happening the first time I booted and the network didn't work.
I'm testing 3.11 kernel now: all the same. Weird.

Post by Thomas D.
I can immediately start shorewall manually (/etc/init.d/shorewall start)
and it will start without any problems. So this looks like a timing
issue, right.
Is this the same you are talking about?
-Thomas

It looks the very same problem to me.

The new locking code in ip[6]tables 1.4.20 prevents iptables and
ip6tables from running simultaneously unless the -w option is specified
on both. You can work around this problem temporarily by using a
shorewall show -f capabilities > /etc/shorewall/capabilities
shorewall6 show -f capabilities > /etc/shorewall6/capabilities
I'll have a patch to the compiler available in a day or so.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Steve Wray
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 hk2server 3.4.0-cloud #1 SMP Thu May 24 05:12:36 EDT 2012 i686
GNU/Linux

Which iptables version?

-Tom

[Steve Wray]

# 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 iptables 1.4.14 available.

Post by Tom Eastep

Post by Steve Wray
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 hk2server 3.4.0-cloud #1 SMP Thu May 24 05:12:36 EDT 2012 i686
GNU/Linux

Which iptables version?
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Thomas D.]

Hi,

Post by Steve Wray
# uname -a
Linux hk2server 3.4.0-cloud #1 SMP Thu May 24 05:12:36 EDT 2012 i686
GNU/Linux

Seems like you are running a custom kernel.

Have you verified that you kernel has support for LOG target at all?

Check for CONFIG_NETFILTER_XT_TARGET_LOG.


-Thomas

[Steve Wray]

I don't have access to the config file the kernel was built with. How would
I otherwise find out?

I find these kernel modules with 'log' in their names and there doesn't
seem to be a match. If the kernel doesn't have this compiled in does that
mean that shorewall cannot operate and theres no workaround? Because,
honestly, I can live without firewall logging of any kind on this server.

***@hk2server:/lib/modules# find 3.4.0-cloud/ -iname \*log\*
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/ipv4/netfilter/ipt_ULOG.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_nflog.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_ulog.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_log.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/netfilter/xt_NFLOG.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/drivers/md/dm-log.ko
3.4.0-cloud/kernel/net/ipv4/netfilter/ipt_ULOG.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_nflog.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_ulog.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_log.ko
3.4.0-cloud/kernel/net/netfilter/xt_NFLOG.ko
3.4.0-cloud/kernel/drivers/md/dm-log.ko

Post by Thomas D.
Hi,

Post by Steve Wray
# uname -a
Linux hk2server 3.4.0-cloud #1 SMP Thu May 24 05:12:36 EDT 2012 i686
GNU/Linux

Seems like you are running a custom kernel.
Have you verified that you kernel has support for LOG target at all?
Check for CONFIG_NETFILTER_XT_TARGET_LOG.
-Thomas
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Thomas D.]

Hi,

Post by Steve Wray
I don't have access to the config file the kernel was built with. How
would I otherwise find out?

Well, modprobe/modinfo xt_LOG should also give you a hint.

Post by Steve Wray
I find these kernel modules with 'log' in their names and there doesn't
seem to be a match.

I agree,

# modinfo xt_LOG
filename: /lib/modules/3.4.60/kernel/net/netfilter/xt_LOG.ko
alias: ip6t_LOG
alias: ipt_LOG
description: Xtables: IPv4/IPv6 packet logging

This is missing on you system.

Not sure if it is possible to replace the usage of xt_LOG in shorewall
with ULOG or NFLOG. I guess Tom is able to answer that.

Post by Steve Wray
If the kernel doesn't have this compiled in does
that mean that shorewall cannot operate and theres no workaround?
Because, honestly, I can live without firewall logging of any kind on
this server.

Yup... and it's good that you cannot live without logging.

Can't you contact support or the person/company who/which created the
system/kernel image you are using?


-Thomas

[Tom Eastep]

Post by Thomas D.
Hi,

Post by Steve Wray
I don't have access to the config file the kernel was built with. How
would I otherwise find out?

Well, modprobe/modinfo xt_LOG should also give you a hint.

Post by Steve Wray
I find these kernel modules with 'log' in their names and there doesn't
seem to be a match.

I agree,
# modinfo xt_LOG
filename: /lib/modules/3.4.60/kernel/net/netfilter/xt_LOG.ko
alias: ip6t_LOG
alias: ipt_LOG
description: Xtables: IPv4/IPv6 packet logging
This is missing on you system.
Not sure if it is possible to replace the usage of xt_LOG in shorewall
with ULOG or NFLOG. I guess Tom is able to answer that.

Replacing LOG with ULOG is described at
http://www.shorewall.net/shorewall_logging.html#ULOG

-Tom

[Steve Wray]

I tested with iptables -N foo ; iptables -A foo -j ULOG and that was fine,
so it looks like the kernel does have ULOG support. So I followed the
recipe in the doc to convert to ULOG;

***@hk2server:/etc/shorewall# grep -v ^\# * | egrep '\$LOG|ULOG|LOGFILE'
params:LOG=ULOG
shorewall.conf:LOGFILE=/var/log/messages
shorewall.conf:MACLIST_LOG_LEVEL=$LOG
shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG
shorewall.conf:RFC1918_LOG_LEVEL=$LOG
shorewall.conf:LOGUNCLEAN=$LOG

No rules or policies are configured to log. Its running ulogd

Still getting the same error

***@hk2server:/etc/shorewall# shorewall try /etc/shorewall/
Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168)
Loading Modules...
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918' interface/host
option is no longer supported
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Compiling /usr/share/shorewall/action.Drop for chain Drop...
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
Compiling /usr/share/shorewall/action.Invalid for chain Invalid...
Compiling /usr/share/shorewall/action.NotSyn for chain NotSyn...
Compiling /usr/share/shorewall/action.Reject for chain Reject...
Compiling /etc/shorewall/policy...
ERROR: Log level INFO requires LOG Target in your kernel and iptables

Post by Tom Eastep

Post by Thomas D.
Hi,

Post by Steve Wray
I don't have access to the config file the kernel was built with. How
would I otherwise find out?

Well, modprobe/modinfo xt_LOG should also give you a hint.

Post by Steve Wray
I find these kernel modules with 'log' in their names and there doesn't
seem to be a match.

I agree,
# modinfo xt_LOG
filename: /lib/modules/3.4.60/kernel/net/netfilter/xt_LOG.ko
alias: ip6t_LOG
alias: ipt_LOG
description: Xtables: IPv4/IPv6 packet logging
This is missing on you system.
Not sure if it is possible to replace the usage of xt_LOG in shorewall
with ULOG or NFLOG. I guess Tom is able to answer that.

Replacing LOG with ULOG is described at
http://www.shorewall.net/shorewall_logging.html#ULOG
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Steve Wray
I tested with iptables -N foo ; iptables -A foo -j ULOG and that was
fine, so it looks like the kernel does have ULOG support. So I followed
the recipe in the doc to convert to ULOG;
params:LOG=ULOG
shorewall.conf:LOGFILE=/var/log/messages
shorewall.conf:MACLIST_LOG_LEVEL=$LOG
shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG
shorewall.conf:RFC1918_LOG_LEVEL=$LOG
shorewall.conf:LOGUNCLEAN=$LOG
No rules or policies are configured to log. Its running ulogd
Still getting the same error
Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168)
Loading Modules...
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918'
interface/host option is no longer supported
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Compiling /usr/share/shorewall/action.Drop for chain Drop...
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
Compiling /usr/share/shorewall/action.Invalid for chain Invalid...
Compiling /usr/share/shorewall/action.NotSyn for chain NotSyn...
Compiling /usr/share/shorewall/action.Reject for chain Reject...
Compiling /etc/shorewall/policy...
ERROR: Log level INFO requires LOG Target in your kernel and iptables

Please post the contents of your policy file.

-Tom

[Steve Wray]

$FW $FW ACCEPT - -
$FW net ACCEPT - -
net $FW ACCEPT - -

Post by Steve Wray

Post by Steve Wray
I tested with iptables -N foo ; iptables -A foo -j ULOG and that was
fine, so it looks like the kernel does have ULOG support. So I followed
the recipe in the doc to convert to ULOG;

'\$LOG|ULOG|LOGFILE'

Post by Steve Wray
params:LOG=ULOG
shorewall.conf:LOGFILE=/var/log/messages
shorewall.conf:MACLIST_LOG_LEVEL=$LOG
shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG
shorewall.conf:RFC1918_LOG_LEVEL=$LOG
shorewall.conf:LOGUNCLEAN=$LOG
No rules or policies are configured to log. Its running ulogd
Still getting the same error
Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168)
Loading Modules...
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918'
interface/host option is no longer supported
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Compiling /usr/share/shorewall/action.Drop for chain Drop...
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
Compiling /usr/share/shorewall/action.Invalid for chain Invalid...
Compiling /usr/share/shorewall/action.NotSyn for chain NotSyn...
Compiling /usr/share/shorewall/action.Reject for chain Reject...
Compiling /etc/shorewall/policy...
ERROR: Log level INFO requires LOG Target in your kernel and iptables

Please post the contents of your policy file.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Steve Wray
$FW $FW ACCEPT - -
$FW net ACCEPT - -
net $FW ACCEPT - -

With those policies, why have a firewall?

At any rate, please 'shorewall check -T' and forward the output.

Thanks,
-Tom

[Steve Wray]

Believe it or not, the firewall is doing something. Mostly its rate
limiting and sanity checking. We are working toward a more robust firewall
but our application is pretty sensitive to closed ports and doesn't have a
connection tracking module. Shorewall is definitely helping, even at this
stage though, on our other servers. This is the only one with any shorewall
problem.

Here is the output as requested;

WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168) at
/usr/share/shorewall/Shorewall/Config.pm line 3601
Shorewall::Config::process_shorewall_conf(0, 0) called at
/usr/share/shorewall/Shorewall/Config.pm line 3935
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918' interface/host
option is no longer supported at /usr/share/shorewall/Shorewall/Config.pm
line 4223
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
ERROR: Log level INFO requires LOG Target in your kernel and iptables at
/usr/share/shorewall/Shorewall/Config.pm line 964
Shorewall::Config::fatal_error('Log level INFO requires LOG Target
in your kernel and iptables') called at
/usr/share/shorewall/Shorewall/Config.pm line 3376
Shorewall::Config::require_capability('LOG_TARGET', 'Log level
INFO', 's') called at /usr/share/shorewall/Shorewall/Config.pm line 2532
Shorewall::Config::validate_level('info') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5174
Shorewall::Chains::log_rule_limit('info', 'HASH(0xa56eb60)',
'sfilter', 'DROP', '', '', 'add', '') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5256
Shorewall::Chains::log_rule('info', 'HASH(0xa56eb60)', 'DROP', '')
called at /usr/share/shorewall/Shorewall/Misc.pm line 713
Shorewall::Misc::add_common_rules(0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 696
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
Checking...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Checking /etc/shorewall/zones...
Checking /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Checking /usr/share/shorewall/action.Drop for chain Drop...
Checking /usr/share/shorewall/action.Broadcast for chain Broadcast...
Checking /usr/share/shorewall/action.Invalid for chain Invalid...
Checking /usr/share/shorewall/action.NotSyn for chain NotSyn...
Checking /usr/share/shorewall/action.Reject for chain Reject...
Checking /etc/shorewall/policy...

Post by Tom Eastep

Post by Steve Wray
$FW $FW ACCEPT - -
$FW net ACCEPT - -
net $FW ACCEPT - -

With those policies, why have a firewall?
At any rate, please 'shorewall check -T' and forward the output.
Thanks,
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Steve Wray
Believe it or not, the firewall is doing something. Mostly its rate
limiting and sanity checking. We are working toward a more robust
firewall but our application is pretty sensitive to closed ports and
doesn't have a connection tracking module. Shorewall is definitely
helping, even at this stage though, on our other servers. This is the
only one with any shorewall problem.
Here is the output as requested;
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168) at
/usr/share/shorewall/Shorewall/Config.pm line 3601
Shorewall::Config::process_shorewall_conf(0, 0) called at
/usr/share/shorewall/Shorewall/Config.pm line 3935
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918'
interface/host option is no longer supported at
/usr/share/shorewall/Shorewall/Config.pm line 4223
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
ERROR: Log level INFO requires LOG Target in your kernel and iptables
at /usr/share/shorewall/Shorewall/Config.pm line 964
Shorewall::Config::fatal_error('Log level INFO requires LOG
Target in your kernel and iptables') called at
/usr/share/shorewall/Shorewall/Config.pm line 3376
Shorewall::Config::require_capability('LOG_TARGET', 'Log level
INFO', 's') called at /usr/share/shorewall/Shorewall/Config.pm line 2532
Shorewall::Config::validate_level('info') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5174
Shorewall::Chains::log_rule_limit('info', 'HASH(0xa56eb60)',
'sfilter', 'DROP', '', '', 'add', '') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5256
Shorewall::Chains::log_rule('info', 'HASH(0xa56eb60)', 'DROP',
'') called at /usr/share/shorewall/Shorewall/Misc.pm line 713
Shorewall::Misc::add_common_rules(0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 696
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134

S_FILTER_LOG_LEVEL defaults to 'info', so you need to change iot.

-Tom

[Tom Eastep]

Post by Tom Eastep

Post by Steve Wray
Believe it or not, the firewall is doing something. Mostly its rate
limiting and sanity checking. We are working toward a more robust
firewall but our application is pretty sensitive to closed ports and
doesn't have a connection tracking module. Shorewall is definitely
helping, even at this stage though, on our other servers. This is the
only one with any shorewall problem.
Here is the output as requested;
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168) at
/usr/share/shorewall/Shorewall/Config.pm line 3601
Shorewall::Config::process_shorewall_conf(0, 0) called at
/usr/share/shorewall/Shorewall/Config.pm line 3935
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918'
interface/host option is no longer supported at
/usr/share/shorewall/Shorewall/Config.pm line 4223
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
ERROR: Log level INFO requires LOG Target in your kernel and iptables
at /usr/share/shorewall/Shorewall/Config.pm line 964
Shorewall::Config::fatal_error('Log level INFO requires LOG
Target in your kernel and iptables') called at
/usr/share/shorewall/Shorewall/Config.pm line 3376
Shorewall::Config::require_capability('LOG_TARGET', 'Log level
INFO', 's') called at /usr/share/shorewall/Shorewall/Config.pm line 2532
Shorewall::Config::validate_level('info') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5174
Shorewall::Chains::log_rule_limit('info', 'HASH(0xa56eb60)',
'sfilter', 'DROP', '', '', 'add', '') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5256
Shorewall::Chains::log_rule('info', 'HASH(0xa56eb60)', 'DROP',
'') called at /usr/share/shorewall/Shorewall/Misc.pm line 713
Shorewall::Misc::add_common_rules(0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 696
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134

S_FILTER_LOG_LEVEL defaults to 'info', so you need to change iot.

The attached simple patch will catch cases like this.

patch /usr/share/shorewall/Shorewall/Config.pm < DEFAULT_LOG.patch

It applies with an offset on 4.5.5.3.

-Tom

[Steve Wray]

Sorry, Tom, doesn't work for me. I also searched the whole Shorewall
install for any files containing S_FILTER_LOG_LEVEL and couldn't find any.

# patch /usr/share/shorewall/Shorewall/Config.pm < DEFAULT_LOG.patch
patching file /usr/share/shorewall/Shorewall/Config.pm
Hunk #1 succeeded at 2601 (offset -917 lines).

# shorewall try /etc/shorewall/
Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168)
Loading Modules...
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918' interface/host
option is no longer supported
ERROR: Log level INFO requires LOG Target in your kernel and iptables

# shorewall check -T /etc/shorewall/
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168) at
/usr/share/shorewall/Shorewall/Config.pm line 3601
Shorewall::Config::process_shorewall_conf(0, 0) called at
/usr/share/shorewall/Shorewall/Config.pm line 3935
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918' interface/host
option is no longer supported at /usr/share/shorewall/Shorewall/Config.pm
line 4223
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
ERROR: Log level INFO requires LOG Target in your kernel and iptables at
/usr/share/shorewall/Shorewall/Config.pm line 964
Shorewall::Config::fatal_error('Log level INFO requires LOG Target
in your kernel and iptables') called at
/usr/share/shorewall/Shorewall/Config.pm line 3376
Shorewall::Config::require_capability('LOG_TARGET', 'Log level
INFO', 's') called at /usr/share/shorewall/Shorewall/Config.pm line 2532
Shorewall::Config::validate_level('info') called at
/usr/share/shorewall/Shorewall/Config.pm line 2603
Shorewall::Config::default_log_level('SFILTER_LOG_LEVEL', 'info')
called at /usr/share/shorewall/Shorewall/Config.pm line 4228
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at
/usr/share/shorewall/compiler.pl line 134
Checking...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...

Post by Tom Eastep

Post by Tom Eastep

Post by Steve Wray
Believe it or not, the firewall is doing something. Mostly its rate
limiting and sanity checking. We are working toward a more robust
firewall but our application is pretty sensitive to closed ports and
doesn't have a connection tracking module. Shorewall is definitely
helping, even at this stage though, on our other servers. This is the
only one with any shorewall problem.
Here is the output as requested;
WARNING: Option EXPORTPARAMS=Yes is deprecated
/etc/shorewall/shorewall.conf (line 168) at
/usr/share/shorewall/Shorewall/Config.pm line 3601
Shorewall::Config::process_shorewall_conf(0, 0) called at
/usr/share/shorewall/Shorewall/Config.pm line 3935
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
WARNING: RFC1918_LOG_LEVEL=ULOG ignored. The 'norfc1918'
interface/host option is no longer supported at
/usr/share/shorewall/Shorewall/Config.pm line 4223
Shorewall::Config::get_configuration(0, 0, 0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 623
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134
ERROR: Log level INFO requires LOG Target in your kernel and iptables
at /usr/share/shorewall/Shorewall/Config.pm line 964
Shorewall::Config::fatal_error('Log level INFO requires LOG
Target in your kernel and iptables') called at
/usr/share/shorewall/Shorewall/Config.pm line 3376
Shorewall::Config::require_capability('LOG_TARGET', 'Log level
INFO', 's') called at /usr/share/shorewall/Shorewall/Config.pm line 2532
Shorewall::Config::validate_level('info') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5174
Shorewall::Chains::log_rule_limit('info', 'HASH(0xa56eb60)',
'sfilter', 'DROP', '', '', 'add', '') called at
/usr/share/shorewall/Shorewall/Chains.pm line 5256
Shorewall::Chains::log_rule('info', 'HASH(0xa56eb60)', 'DROP',
'') called at /usr/share/shorewall/Shorewall/Misc.pm line 713
Shorewall::Misc::add_common_rules(0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 696
Shorewall::Compiler::compiler('script', '', 'directory',
'/etc/shorewall/', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called
at /usr/share/shorewall/compiler.pl <http://compiler.pl> line 134

S_FILTER_LOG_LEVEL defaults to 'info', so you need to change iot.

The attached simple patch will catch cases like this.
patch /usr/share/shorewall/Shorewall/Config.pm < DEFAULT_LOG.patch
It applies with an offset on 4.5.5.3.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Steve Wray
Sorry, Tom, doesn't work for me. I also searched the whole Shorewall
install for any files containing S_FILTER_LOG_LEVEL and couldn't find any.

Steve,

The compiler supports that option and is defaulting its value to 'info'.
What I suggest you do is:

shorewall update

That will create a new shorewall.conf file that
contains all of the options supported by your version.
Your old file will be renamed shorewall.conf.bak.

Modify the new shorewall.conf file as needed.

-Tom

[Tom Eastep]

Post by Steve Wray
I don't have access to the config file the kernel was built with. How
would I otherwise find out?
I find these kernel modules with 'log' in their names and there doesn't
seem to be a match. If the kernel doesn't have this compiled in does
that mean that shorewall cannot operate and theres no workaround?
Because, honestly, I can live without firewall logging of any kind on
this server.
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/ipv4/netfilter/ipt_ULOG.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_nflog.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_ulog.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/bridge/netfilter/ebt_log.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/net/netfilter/xt_NFLOG.ko
3.4.0-cloud/3.4.0-cloud-i386/kernel/drivers/md/dm-log.ko
3.4.0-cloud/kernel/net/ipv4/netfilter/ipt_ULOG.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_nflog.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_ulog.ko
3.4.0-cloud/kernel/net/bridge/netfilter/ebt_log.ko
3.4.0-cloud/kernel/net/netfilter/xt_NFLOG.ko
3.4.0-cloud/kernel/drivers/md/dm-log.ko

You can replicate the test for the LOG target that the rules compiler
performs as follows:

iptables -N foo
iptables -A foo -j LOG
iptables -F foo
iptables -X foo

If the second command fails, then you have no LOG target support.

-Tom

[Mau]

Hi Tom,

Post by Tom Eastep

[...]

The new locking code in ip[6]tables 1.4.20 prevents iptables and
ip6tables from running simultaneously unless the -w option is specified
on both. You can work around this problem temporarily by using a
shorewall show -f capabilities > /etc/shorewall/capabilities
shorewall6 show -f capabilities > /etc/shorewall6/capabilities
I'll have a patch to the compiler available in a day or so.
-Tom

I also suspect that the concurrency bug addressed in iptables 1.4.20
caused some problem in the past: with shorewall apparently working,
sometimes psad complained there was no LOG target in the firewall.

The latest 4.5.21-Beta1 version seems to perfectly fix all the iptables
related issues in my case; I'd only like to suggest some cosmetic
improvement on the shorewall-init boot messages on Debian:

Initializing "Shorewall-based firewalls": Compiling...
/var/lib/shorewall/firewall is up to date -- no compilation required
echo_notdone
Compiling...
/var/lib/shorewall6/firewall is up to date -- no compilation required
echo_notdone
done.

Thanks a lot,


Maurizio

[Thomas D.]

Post by Mau
The latest 4.5.21-Beta1 version seems to perfectly fix all the iptables
related issues in my case;

Same here for Gentoo: 4.5.21-Beta1 fixes the restart problem.


-Thomas