The Shorewall team is pleased to announce the availability of Shorewall 4.5.17.
----------------------------------------------------------------------------
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) When INLINE was used in the tcrules file and no target
(''-j'' part)
is included in the free-form part of the rule, an invalid
iptables rule was generated.
2) Thanks to Roberto Sanchez, many typos in the manpages have been
corrected.
3) A number of issues have been corrected in the Debian and
Redhat/Fedora Shorewall-init SysV init scripts:
a) Settings in ${SHAREDIR}/vardir are now handled correctly.
b) Exit status is now returned correctly.
c) Stale lock files are avoided.
4) When the compiled firewall script is run directly, it no longer
attempts to copy itself onto itself using the ''cp''
utility.
5) An optimizer defect that could leave unreferenced chains in the
configuration has been corrected.
6) Unreferenced chains in the IPV6 nat table are now omitted.
7) Rules with trivial exclusion (a single net or ipset preceded by
''!'') now generate the iptables matches in the correct
order. Previously, the exclusion match(es) was(were) placed at the
end. This is important in rules that auto-increment nfacct objects.
8) Previously, conntrack helpers were enabled by the ''stop''
command. Now, these helpers are only enabled by the
''clear''
command.
9) Previously, an interface label (e.g., dev:N) could be specified
as the ''physical'' interface in /etc/shorewall/interfaces.
This
is now disallowed.
10) The Perl function ''shorewall'' was not previously exported
by
Shorewall::Config, with the result that the function had
to be called as Shorewall::Config::shorewall(...). the function is
now exported and can be called from ?BEGIN PERL blocks as simply
shorewall(...).
11) Previously, two ICMPv6 type names were mis-translated.
address-unreachable was translated to 1/2; should be 1/3
port-unreachable was translated to 1/3; should be 1/4
These translations have been corrected.
12) If a TPROXY IPv6 address was specified in /etc/shorewall6/tcrules
using the [<address>]/vlsm form (e.g.,
''TPROXY(0x100,3129,[2001:470:b:227::44]/64)'') then an
''Invalid Address''
error was issued. This has been corrected.
----------------------------------------------------------------------------
I I. K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
1) On systems running Upstart, shorewall-init cannot reliably secure
the firewall before interfaces are brought up.
----------------------------------------------------------------------------
I I I. N E W F E A T U R E S I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) Route types ''blackhole'', ''unreachable''
and ''prohibit'' are no longer
copied to provider routing tables by default when
USE_DEFAULT_RT=No. You may cause them to be copied by including
''blackhole'', ''unreachable'' and/or
''prohibit'' in the COPY list along
with interface names.
2) Previously, the generated script always added a host route to a
provider''s gateway in the provider''s routing table.
Beginning with
this release, the ''noautosrc'' provider option can be used
to
inhibit this behavior. ''noautosrc'' must be used with care
since the
absense of such a route can cause start/restart runtime failures.
3) A ''-c'' (conditional) option has been added to the
''compile'' command.
This option causes compilation to proceed if:
a) The specified (or defaulted) firewall script does not exist; or
b) A file on the CONFIG_PATH (including any directory specified in
the command) is newer than the existing script.
4) A new interface option has been added.
destonly
Causes the compiler to omit rules to handle traffic arriving on
the interface.
5) It is now possible to use ''all+'' in the SOURCE and DEST
columns of
/etc/shorewall[6]/policy file. It has the same meaning as in the
rules file in that it can override default intra-zone ACCEPT
policies.
6) Beginning with this release, most special handling of
''Auth'' (TCP
port 113) has been removed. In particular, the Drop default action
will no longer default to silently REJECTing Auth requests but will
rather simply process them like other tcp packets.
7) Traditionally, Shorewall has treated the loopback interface
(''lo'')
as follows:
- It deals with firewall-to-firewall, firewall-to-vserver,
vserver-to-firewall, and vserver-to-vserver traffic.
- All filtering is done in the OUTPUT flow; all traffic arriving on
''lo'' is silently accepted.
- If no firewall-to-firewall policy or rules are defined, then
a simple ACCEPT rule is also included in the OUTPUT chain for
''lo'' (after any vserver-oriented jumps).
Beginning with this release, the handling of firewall-to-firewall
traffic can be altered by adding a zone of type
''loopback''.
- ''loopback'' zones must be associated with the loopback
device in
the interfaces and/or hosts file.
/etc/shorewall/zones
#ZONE TYPE
loop loopback
/etc/shorewall/interfaces
?FORMAT 2
#ZONE INTERFACE OPTIONS
loop lo ...
When this is done, the ACCEPT jumps for ''lo'' in the
INPUT and
OUTPUT chains are omitted and replaced with jumps to the loop2fw
and fw2loop (loop-fw and fw-lop) chains respectively. This
provides a model similar to other zones for fireall-to-firewall
traffic.
8) A new ''local'' zone TYPE has been added to
/etc/shorewall[6]/zones.
A ''local'' zone is similar to an ''ipv4''
(''ipv6'') zone, except that
rules and policies to/from a ''local'' zone may only be
to/from the
firewall zone and vserver zones.
Thank you for using Shorewall,
-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 \________________________________________________
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It''s a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> 8) A new ''local'' zone TYPE has been added to /etc/shorewall[6]/zones. > A ''local'' zone is similar to an ''ipv4'' (''ipv6'') zone, except that > rules and policies to/from a ''local'' zone may only be to/from the > firewall zone and vserver zones. >When I have something like: zones ~~~~~ local local interfaces ~~~~~~~~~~ local eth1 - lo ignore policy ~~~~~~ local $FW DROP $FW local DROP all+ all+ DROP shorewall generates: -A INPUT -i lo -j ACCEPT [...] -A OUTPUT -o eth1 -j ACCEPT [...] -A OUTPUT -o lo -j fw2fw which is wrong. The "-o eth1" rule above should be a jump to "fw2local" and the last rule should be "-o lo -j ACCEPT". ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On May 31, 2013, at 5:40 PM, Dash Four <mr.dash.four@googlemail.com> wrote:> > Tom Eastep wrote: >> 8) A new ''local'' zone TYPE has been added to /etc/shorewall[6]/zones. >> A ''local'' zone is similar to an ''ipv4'' (''ipv6'') zone, except that >> rules and policies to/from a ''local'' zone may only be to/from the >> firewall zone and vserver zones. >> > When I have something like: > > zones > ~~~~~ > local local > > interfaces > ~~~~~~~~~~ > local eth1 > - lo ignore > > policy > ~~~~~~ > local $FW DROP > $FW local DROP > all+ all+ DROP > > > shorewall generates: > > -A INPUT -i lo -j ACCEPT > [...] > -A OUTPUT -o eth1 -j ACCEPT > [...] > -A OUTPUT -o lo -j fw2fw > > which is wrong. The "-o eth1" rule above should be a jump to "fw2local"I''m not reproducing that -- if I change my $FW->local policy to DROP, the net change is: -A fw-loc -m conntrack --ctstate RELATED -j +fw-loc -A fw-loc -j ACCEPT -A fw-local -m conntrack --ctstate RELATED -j +fw-local --A fw-local -j ACCEPT +-A fw-local -j Drop +-A fw-local -j DROP -A fw-local1 -m conntrack --ctstate RELATED -j +fw-local1 -A fw-local1 -j ACCEPT -A fw-loop1 -m conntrack --ctstate RELATED -j +fw-loop1> and the last rule should be "-o lo -j ACCEPT". >No -- all+ all+ DROP means that the fw->fw policy is DROP. That is probably enforced in the fw2fw chain. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On May 31, 2013, at 5:40 PM, Dash Four <mr.dash.four@googlemail.com> wrote: > > >> Tom Eastep wrote: >> >>> 8) A new ''local'' zone TYPE has been added to /etc/shorewall[6]/zones. >>> A ''local'' zone is similar to an ''ipv4'' (''ipv6'') zone, except that >>> rules and policies to/from a ''local'' zone may only be to/from the >>> firewall zone and vserver zones. >>> >>> >> When I have something like: >> >> zones >> ~~~~~ >> local local >> >> interfaces >> ~~~~~~~~~~ >> local eth1 >> - lo ignore >> >> policy >> ~~~~~~ >> local $FW DROP >> $FW local DROP >> all+ all+ DROP >> >> >> shorewall generates: >> >> -A INPUT -i lo -j ACCEPT >> [...] >> -A OUTPUT -o eth1 -j ACCEPT >> [...] >> -A OUTPUT -o lo -j fw2fw >> >> which is wrong. The "-o eth1" rule above should be a jump to "fw2local" >> > > I''m not reproducing that -- if I change my $FW->local policy to DROP, the net change is: > > -A fw-loc -m conntrack --ctstate RELATED -j +fw-loc > -A fw-loc -j ACCEPT > -A fw-local -m conntrack --ctstate RELATED -j +fw-local > --A fw-local -j ACCEPT > +-A fw-local -j Drop > +-A fw-local -j DROP > -A fw-local1 -m conntrack --ctstate RELATED -j +fw-local1 > -A fw-local1 -j ACCEPT > -A fw-loop1 -m conntrack --ctstate RELATED -j +fw-loop1 >Well, I am still getting this.>> and the last rule should be "-o lo -j ACCEPT". >> >> > > > No -- all+ all+ DROP means that the fw->fw policy is DROP. That is probably enforced in the fw2fw chain. >I have asked shorewall to ignore "lo" - doesn''t that mean shorewall should *not* enforce anything for that interface (and let all the traffic through that interface "pass")? In addition, I am getting two separate sets of warnings during startup: rules ~~~~~ SECTION RELATED # MUST be last as *_DISPOSITION does not accept custom actions IFLOG(-,log1,-,drop,DROP) all all gives me: WARNING: The rule(s) generated by this entry are unreachable and have been discarded /etc/shorewall/action.ILOG (line 38) from /etc/shorewall/action.IFLOG (line 31) from /etc/shorewall/rules (line 106) [...ad nauseum ...] then... WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' /etc/shorewall/action.IFLOG (line 29) from /etc/shorewall/tunnels (line EOF) WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' /etc/shorewall/action.IFLOG (line 31) from /etc/shorewall/tunnels (line EOF) [...again, ad nauseum ...] My /etc/shorewall/tunnels is empty. Also, despite my best efforts, the xt_CT helper messages have *not* gone away, even though I''ve set net.netfilter_nf_conntrack_helper to 0 in my sysctl.conf (I even tried setting this as a kernel parameter). ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Dash Four wrote:> In addition, I am getting two separate sets of warnings during startup: > > rules > ~~~~~ > SECTION RELATED > # MUST be last as *_DISPOSITION does not accept custom actions > IFLOG(-,log1,-,drop,DROP) all all > > gives me: > > WARNING: The rule(s) generated by this entry are unreachable and have > been discarded /etc/shorewall/action.ILOG (line 38) > from /etc/shorewall/action.IFLOG (line 31) > from /etc/shorewall/rules (line 106) > [...ad nauseum ...] > > then... > > WARNING: The SOURCE zone is off-firewall and the DEST zone is > ''loopback'' /etc/shorewall/action.IFLOG (line 29) > from /etc/shorewall/tunnels (line EOF) > WARNING: The SOURCE zone is off-firewall and the DEST zone is > ''loopback'' /etc/shorewall/action.IFLOG (line 31) > from /etc/shorewall/tunnels (line EOF) > [...again, ad nauseum ...] > > My /etc/shorewall/tunnels is empty. > > Also, despite my best efforts, the xt_CT helper messages have *not* > gone away, even though I''ve set net.netfilter_nf_conntrack_helper to 0 > in my sysctl.conf (I even tried setting this as a kernel parameter).Forgot to mention - the above warnings are from shorewall on a different machine (with different configuration). ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
> Forgot to mention - the above warnings are from shorewall on a > different machine (with different configuration).Another query I forgot to add: my INPUT chain contains the now-familiar "Drop"/LOG/DROP set of rules, but I have Reject/LOG/reject in the OUTPUT as well as FORWARD chains instead. What is the reason for this difference and is there a way to control that behaviour? ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 06:45 AM, Dash Four wrote:> > Tom Eastep wrote: >> On May 31, 2013, at 5:40 PM, Dash Four <mr.dash.four@googlemail.com> wrote: >> >> >>> Tom Eastep wrote: >>> >>>> 8) A new ''local'' zone TYPE has been added to /etc/shorewall[6]/zones. >>>> A ''local'' zone is similar to an ''ipv4'' (''ipv6'') zone, except that >>>> rules and policies to/from a ''local'' zone may only be to/from the >>>> firewall zone and vserver zones. >>>> >>>> >>> When I have something like: >>> >>> zones >>> ~~~~~ >>> local local >>> >>> interfaces >>> ~~~~~~~~~~ >>> local eth1 >>> - lo ignore >>> >>> policy >>> ~~~~~~ >>> local $FW DROP >>> $FW local DROP >>> all+ all+ DROP >>> >>> >>> shorewall generates: >>> >>> -A INPUT -i lo -j ACCEPT >>> [...] >>> -A OUTPUT -o eth1 -j ACCEPT >>> [...] >>> -A OUTPUT -o lo -j fw2fw >>> >>> which is wrong. The "-o eth1" rule above should be a jump to "fw2local" >>> >> >> I''m not reproducing that -- if I change my $FW->local policy to DROP, the net change is: >> >> -A fw-loc -m conntrack --ctstate RELATED -j +fw-loc >> -A fw-loc -j ACCEPT >> -A fw-local -m conntrack --ctstate RELATED -j +fw-local >> --A fw-local -j ACCEPT >> +-A fw-local -j Drop >> +-A fw-local -j DROP >> -A fw-local1 -m conntrack --ctstate RELATED -j +fw-local1 >> -A fw-local1 -j ACCEPT >> -A fw-loop1 -m conntrack --ctstate RELATED -j +fw-loop1 >> > Well, I am still getting this.Then please forward a configuration (with capabilities file) that shows the problem. Thanks.> >>> and the last rule should be "-o lo -j ACCEPT". >>> >>> >> >> >> No -- all+ all+ DROP means that the fw->fw policy is DROP. That is probably enforced in the fw2fw chain. >> > I have asked shorewall to ignore "lo" - doesn''t that mean shorewall > should *not* enforce anything for that interface (and let all the > traffic through that interface "pass")? >No -- from ''man shorewall-interfaces'': ignore[=1] When specified, causes the generated script to ignore up/down events from Shorewall-init for this device. Additionally, the option exempts the interface from hairpin filtering. When ''=1'' is omitted, the ZONE column must contain ''-'' and ignore must be the only OPTION. Beginning with Shorewall 4.5.5, may be specified as ''ignore=1'' which only causes the generated script to ignore up/down events from Shorewall-init; hairpin filtering is still applied. In this case, the above restrictions on the ZONE and OPTIONS columns are lifted.> In addition, I am getting two separate sets of warnings during startup: > > rules > ~~~~~ > SECTION RELATED > # MUST be last as *_DISPOSITION does not accept custom actions > IFLOG(-,log1,-,drop,DROP) all all > > gives me: > > WARNING: The rule(s) generated by this entry are unreachable and have > been discarded /etc/shorewall/action.ILOG (line 38) > from /etc/shorewall/action.IFLOG (line 31) > from /etc/shorewall/rules (line 106) > [...ad nauseum ...] > > then... > > WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' > /etc/shorewall/action.IFLOG (line 29) > from /etc/shorewall/tunnels (line EOF) > WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' > /etc/shorewall/action.IFLOG (line 31) > from /etc/shorewall/tunnels (line EOF) > [...again, ad nauseum ...] > > My /etc/shorewall/tunnels is empty.I''ll make no progress on that one without seeing the action.IFLOG definition.> > Also, despite my best efforts, the xt_CT helper messages have *not* gone > away, even though I''ve set net.netfilter_nf_conntrack_helper to 0 in my > sysctl.conf (I even tried setting this as a kernel parameter).Do you have any ''notrack'' rules? If not, you could simply omit xt_CT from your kernel configuration. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 06/01/2013 06:45 AM, Dash Four wrote: > >> Well, I am still getting this. >> > > Then please forward a configuration (with capabilities file) that shows > the problem. Thanks. >I''ll do that later.>>>> and the last rule should be "-o lo -j ACCEPT". >>>> >>>> >>>> >>> No -- all+ all+ DROP means that the fw->fw policy is DROP. That is probably enforced in the fw2fw chain. >>> >>> >> I have asked shorewall to ignore "lo" - doesn''t that mean shorewall >> should *not* enforce anything for that interface (and let all the >> traffic through that interface "pass")? >> >> > > No -- from ''man shorewall-interfaces'': > > ignore[=1] > > When specified, causes the generated script to ignore up/down events > from Shorewall-init for this device. Additionally, the option exempts > the interface from hairpin filtering. When ''=1'' is omitted, the ZONE > column must contain ''-'' and ignore must be the only OPTION. > > Beginning with Shorewall 4.5.5, may be specified as ''ignore=1'' which > only causes the generated script to ignore up/down events from > Shorewall-init; hairpin filtering is still applied. In this case, the > above restrictions on the ZONE and OPTIONS columns are lifted. >Right, so if I want shorewall to "ignore" a specific interface, I need to explicitly set its policies to "ACCEPT", would that be sufficient?>> In addition, I am getting two separate sets of warnings during startup: >> >> rules >> ~~~~~ >> SECTION RELATED >> # MUST be last as *_DISPOSITION does not accept custom actions >> IFLOG(-,log1,-,drop,DROP) all all >> >> gives me: >> >> WARNING: The rule(s) generated by this entry are unreachable and have >> been discarded /etc/shorewall/action.ILOG (line 38) >> from /etc/shorewall/action.IFLOG (line 31) >> from /etc/shorewall/rules (line 106) >> [...ad nauseum ...] >> >> then... >> >> WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' >> /etc/shorewall/action.IFLOG (line 29) >> from /etc/shorewall/tunnels (line EOF) >> WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' >> /etc/shorewall/action.IFLOG (line 31) >> from /etc/shorewall/tunnels (line EOF) >> [...again, ad nauseum ...] >> >> My /etc/shorewall/tunnels is empty. >> > > I''ll make no progress on that one without seeing the action.IFLOG > definition. >IFLOG is the "inline" equivalent of FLOG, which I have posted before: action.FLOG ~~~~~~~~~~~ ?IF $1 NFLOG($1,0,1) ?ENDIF ?IF $2 ?SET @chain $3 ? $3 : " " ?SET @disposition $4 ? $4 : " " LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?END IF ?IF $5 $5 ?END IF>> Also, despite my best efforts, the xt_CT helper messages have *not* gone >> away, even though I''ve set net.netfilter_nf_conntrack_helper to 0 in my >> sysctl.conf (I even tried setting this as a kernel parameter). >> > > Do you have any ''notrack'' rules? If not, you could simply omit xt_CT > from your kernel configuration. >My "conntrack" is empty and I have explicitly disabled all helpers in my kernel - that''s the first thing I did in order to get rid of these obnoxious messages. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 7:22 AM, Dash Four <mr.dash.four@googlemail.com> wrote:> > Tom Eastep wrote: >> >> No -- from ''man shorewall-interfaces'': >> >> ignore[=1] >> >> When specified, causes the generated script to ignore up/down events >> from Shorewall-init for this device. Additionally, the option exempts >> the interface from hairpin filtering. When ''=1'' is omitted, the ZONE >> column must contain ''-'' and ignore must be the only OPTION. >> >> Beginning with Shorewall 4.5.5, may be specified as ''ignore=1'' which >> only causes the generated script to ignore up/down events from >> Shorewall-init; hairpin filtering is still applied. In this case, the >> above restrictions on the ZONE and OPTIONS columns are lifted. >> > Right, so if I want shorewall to "ignore" a specific interface, I need > to explicitly set its policies to "ACCEPT", would that be sufficient?Yes. Simply insert ''$FW $FW ACCEPT'' before your all+ all+ rule.> >>> In addition, I am getting two separate sets of warnings during startup: >>> >>> rules >>> ~~~~~ >>> SECTION RELATED >>> # MUST be last as *_DISPOSITION does not accept custom actions >>> IFLOG(-,log1,-,drop,DROP) all all >>> >>> gives me: >>> >>> WARNING: The rule(s) generated by this entry are unreachable and have >>> been discarded /etc/shorewall/action.ILOG (line 38) >>> from /etc/shorewall/action.IFLOG (line 31) >>> from /etc/shorewall/rules (line 106) >>> [...ad nauseum ...] >>> >>> then... >>> >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' >>> /etc/shorewall/action.IFLOG (line 29) >>> from /etc/shorewall/tunnels (line EOF) >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is ''loopback'' >>> /etc/shorewall/action.IFLOG (line 31) >>> from /etc/shorewall/tunnels (line EOF) >>> [...again, ad nauseum ...] >>> >>> My /etc/shorewall/tunnels is empty. >>> >> >> I''ll make no progress on that one without seeing the action.IFLOG >> definition. >> > IFLOG is the "inline" equivalent of FLOG, which I have posted before: > > action.FLOG > ~~~~~~~~~~~ > ?IF $1 > NFLOG($1,0,1) > ?ENDIF > ?IF $2 > ?SET @chain $3 ? $3 : " " > ?SET @disposition $4 ? $4 : " " > LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) > ?END IF > ?IF $5 > $5 > ?END IFI''ll take a look.> >>> Also, despite my best efforts, the xt_CT helper messages have *not* gone >>> away, even though I''ve set net.netfilter_nf_conntrack_helper to 0 in my >>> sysctl.conf (I even tried setting this as a kernel parameter). >>> >> >> Do you have any ''notrack'' rules? If not, you could simply omit xt_CT >> from your kernel configuration. >> > My "conntrack" is empty and I have explicitly disabled all helpers in my > kernel - that''s the first thing I did in order to get rid of these > obnoxious messages.Try hacking your shorewall-init SysV init script to set netfilter_nf_conntrack_helper to zero during ''start'' and see if that does the trick. If so, I can provide an option to do the same. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 07:22 AM, Dash Four wrote:> IFLOG is the "inline" equivalent of FLOG, which I have posted before: > > action.FLOG > ~~~~~~~~~~~ > ?IF $1 > NFLOG($1,0,1) > ?ENDIF > ?IF $2 > ?SET @chain $3 ? $3 : " " > ?SET @disposition $4 ? $4 : " " > LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) > ?END IF > ?IF $5 > $5 > ?END IF >The above doesn''t compile -- ?END IF should be ?ENDIF at the very least. I have taken the standard two-interface example and modified it as follows: actions ------- #ACTION OPTIONS COMMENT (place ''# '' below the ''C'' in # v a comment describing the IFLOG inline action.IFLOG ------------ ?IF $1 NFLOG($1,0,1) ?ENDIF ?IF $2 ?SET @chain $3 ? $3 : " " ?SET @disposition $4 ? $4 : " " LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?ENDIF ?IF $5 $5 ?ENDIF rules: ------ #SECTION ALL #SECTION ESTABLISHED SECTION RELATED IFLOG(-,log1,-,drop,DROP) all all #SECTION INVALID #SECTION UNTRACKED SECTION NEW The resulting configuration compiles with no warnings whatsoever. teastep@mint14 ~/shorewall/trunk/Shorewall/Perl $ shorewall check -r . Checking... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... 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... Adding Anti-smurf Rules Adding rules for DHCP Checking TCP Flags filtering... Checking UPnP Checking Kernel Route Filtering... Checking Martian Logging... Checking Accept Source Routing... Checking /etc/shorewall/providers... Checking /etc/shorewall/masq... Checking MAC Filtration -- Phase 1... Checking /etc/shorewall/rules... Checking /etc/shorewall/tunnels... Checking MAC Filtration -- Phase 2... Applying Policies... Generating Rule Matrix... Optimizing Ruleset... What am I missing? -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 08:10 AM, Tom Eastep wrote:> > The resulting configuration compiles with no warnings whatsoever. > > teastep@mint14 ~/shorewall/trunk/Shorewall/Perl $ shorewall check -r . > Checking... > Processing /etc/shorewall/params ... > Processing /etc/shorewall/shorewall.conf... > 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... > Adding Anti-smurf Rules > Adding rules for DHCP > Checking TCP Flags filtering... > Checking UPnP > Checking Kernel Route Filtering... > Checking Martian Logging... > Checking Accept Source Routing... > Checking /etc/shorewall/providers... > Checking /etc/shorewall/masq... > Checking MAC Filtration -- Phase 1... > Checking /etc/shorewall/rules... > Checking /etc/shorewall/tunnels... > Checking MAC Filtration -- Phase 2... > Applying Policies... > Generating Rule Matrix... > Optimizing Ruleset... >I copied output from the wrong system but the result is the same: Checking... Processing /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/shorewall.conf... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/zones... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/interfaces... Determining Hosts in Zones... Locating Action Files... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/policy... Adding Anti-smurf Rules Adding rules for DHCP Checking TCP Flags filtering... Checking Kernel Route Filtering... Checking Martian Logging... Checking Accept Source Routing... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/masq... Checking MAC Filtration -- Phase 1... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules... Checking MAC Filtration -- Phase 2... Applying Policies... Checking /usr/share/shorewall/action.Reject for chain Reject... Checking /usr/share/shorewall/action.Broadcast for chain Broadcast... Checking /usr/share/shorewall/action.Drop for chain Drop... Generating Rule Matrix... Optimizing Ruleset... -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 06/01/2013 07:22 AM, Dash Four wrote: > > >> IFLOG is the "inline" equivalent of FLOG, which I have posted before: >> >> action.FLOG >> ~~~~~~~~~~~ >> ?IF $1 >> NFLOG($1,0,1) >> ?ENDIF >> ?IF $2 >> ?SET @chain $3 ? $3 : " " >> ?SET @disposition $4 ? $4 : " " >> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >> ?END IF >> ?IF $5 >> $5 >> ?END IF >> >> > > The above doesn''t compile -- ?END IF should be ?ENDIF at the very least. >Yeah, I did a quick cut-and-paste from one of my previous posts to save myself the hassle.> I have taken the standard two-interface example and modified it as follows: > > [...] > > What am I missing? >Define a loopback zone on ''lo'' and see what happens, which is what these warnings were all about. I am assuming the "all all" catch-all statement does something to that ''loopback'' zone, which shorewall doesn''t like, hence the warnings. I did not have these warnings before I explicitly defined the loopback zone (I had it as ipv4 before that). ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 08:23 AM, Dash Four wrote:> > > Tom Eastep wrote: >> On 06/01/2013 07:22 AM, Dash Four wrote: >> >> >>> IFLOG is the "inline" equivalent of FLOG, which I have posted before: >>> >>> action.FLOG >>> ~~~~~~~~~~~ >>> ?IF $1 >>> NFLOG($1,0,1) >>> ?ENDIF >>> ?IF $2 >>> ?SET @chain $3 ? $3 : " " >>> ?SET @disposition $4 ? $4 : " " >>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>> ?END IF >>> ?IF $5 >>> $5 >>> ?END IF >>> >>> >> >> The above doesn''t compile -- ?END IF should be ?ENDIF at the very least. >> > Yeah, I did a quick cut-and-paste from one of my previous posts to save > myself the hassle. > >> I have taken the standard two-interface example and modified it as follows: >> >> [...] >> >> What am I missing? >> > Define a loopback zone on ''lo'' and see what happens, which is what these > warnings were all about. > > I am assuming the "all all" catch-all statement does something to that > ''loopback'' zone, which shorewall doesn''t like, hence the warnings. I did > not have these warnings before I explicitly defined the loopback zone (I > had it as ipv4 before that).Still no joy: zones ----- fw firewall net ipv4 loc ipv4 loop loopback interfaces ---------- net eth0 \ dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 loc eth1 tcpflags,nosmurfs,routefilter,logmartians loop lo teastep@gateway:~/shorewall/regressionLibrary/4.5.17$ shorewall check IFLOG/ Checking... Processing /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/shorewall.conf... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/zones... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/interfaces... Determining Hosts in Zones... Locating Action Files... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/policy... Adding Anti-smurf Rules Adding rules for DHCP Checking TCP Flags filtering... Checking Kernel Route Filtering... Checking Martian Logging... Checking Accept Source Routing... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/masq... Checking MAC Filtration -- Phase 1... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules... Checking MAC Filtration -- Phase 2... Applying Policies... Checking /usr/share/shorewall/action.Reject for chain Reject... Checking /usr/share/shorewall/action.Broadcast for chain Broadcast... Checking /usr/share/shorewall/action.Drop for chain Drop... Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/stoppedrules... Shorewall configuration verified teastep@gateway:~/shorewall/regressionLibrary/4.5.17$ -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 08:37 AM, Tom Eastep wrote:> On 06/01/2013 08:23 AM, Dash Four wrote: >> >> >> Tom Eastep wrote: >>> On 06/01/2013 07:22 AM, Dash Four wrote: >>> >>> >>>> IFLOG is the "inline" equivalent of FLOG, which I have posted before: >>>> >>>> action.FLOG >>>> ~~~~~~~~~~~ >>>> ?IF $1 >>>> NFLOG($1,0,1) >>>> ?ENDIF >>>> ?IF $2 >>>> ?SET @chain $3 ? $3 : " " >>>> ?SET @disposition $4 ? $4 : " " >>>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>>> ?END IF >>>> ?IF $5 >>>> $5 >>>> ?END IF >>>> >>>> >>> >>> The above doesn''t compile -- ?END IF should be ?ENDIF at the very least. >>> >> Yeah, I did a quick cut-and-paste from one of my previous posts to save >> myself the hassle. >> >>> I have taken the standard two-interface example and modified it as follows: >>> >>> [...] >>> >>> What am I missing? >>> >> Define a loopback zone on ''lo'' and see what happens, which is what these >> warnings were all about. >> >> I am assuming the "all all" catch-all statement does something to that >> ''loopback'' zone, which shorewall doesn''t like, hence the warnings. I did >> not have these warnings before I explicitly defined the loopback zone (I >> had it as ipv4 before that). > > Still no joy: > > zones > ----- > fw firewall > net ipv4 > loc ipv4 > loop loopback > > interfaces > ---------- > > net eth0 \ > dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 > loc eth1 tcpflags,nosmurfs,routefilter,logmartians > loop lo > > teastep@gateway:~/shorewall/regressionLibrary/4.5.17$ shorewall check IFLOG/ > Checking... > Processing > /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/shorewall.conf... > Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/zones... > Checking > /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/interfaces... > Determining Hosts in Zones... > Locating Action Files... > Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/policy... > Adding Anti-smurf Rules > Adding rules for DHCP > Checking TCP Flags filtering... > Checking Kernel Route Filtering... > Checking Martian Logging... > Checking Accept Source Routing... > Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/masq... > Checking MAC Filtration -- Phase 1... > Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules... > Checking MAC Filtration -- Phase 2... > Applying Policies... > Checking /usr/share/shorewall/action.Reject for chain Reject... > Checking /usr/share/shorewall/action.Broadcast for chain Broadcast... > Checking /usr/share/shorewall/action.Drop for chain Drop... > Checking > /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/stoppedrules... > Shorewall configuration verified > teastep@gateway:~/shorewall/regressionLibrary/4.5.17$ >I *can* reproduce it if I modify action.IFLOG as follows: ?IF $5 $5 ?ENDIF ?IF $1 NFLOG($1,0,1) ?ENDIF ?IF $2 ?SET @chain $3 ? $3 : " " ?SET @disposition $4 ? $4 : " " LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?ENDIF Here, the second line generates an unqualified ''DROP'' rule so the following rules are unreachable: Checking /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules... WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) WARNING: The rule(s) generated by this entry are unreachable and have been discarded /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/action.IFLOG (line 10) from /home/teastep/shorewall/regressionLibrary/4.5.17/IFLOG/rules (line 19) -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 06:47 AM, Dash Four wrote:> > Dash Four wrote: >> In addition, I am getting two separate sets of warnings during startup:>> >> WARNING: The SOURCE zone is off-firewall and the DEST zone is >> ''loopback'' /etc/shorewall/action.IFLOG (line 29) >> from /etc/shorewall/tunnels (line EOF) >> WARNING: The SOURCE zone is off-firewall and the DEST zone is >> ''loopback'' /etc/shorewall/action.IFLOG (line 31) >> from /etc/shorewall/tunnels (line EOF) >> [...again, ad nauseum ...] >> >> My /etc/shorewall/tunnels is empty.Please post the output of these warnings with the ''T'' option. 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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 06/01/2013 08:37 AM, Tom Eastep wrote: > > > I *can* reproduce it if I modify action.IFLOG as follows: > > > ?IF $5 > $5 > ?ENDIF > ?IF $1 > NFLOG($1,0,1) > ?ENDIF > ?IF $2 > ?SET @chain $3 ? $3 : " " > ?SET @disposition $4 ? $4 : " " > LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) > ?ENDIF >You are (partially) right. I do have an extra check for the 5th parameter at the very beginning and issue a "Drop" (not DROP!): ?IF $5 eq ''Drop'' $5 ?ENDIF The above statement is conditional upon $5 being equal to "Drop" and when I call this action with "IFLOG(-,log1,-,drop,DROP) all all" that surely won''t satisfy the "if" above as "DROP" ain''t "Drop", unless shorewall makes case insensitive comparisons (if so, that certainly wasn''t the case before). ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 9:00 AM, Dash Four <mr.dash.four@googlemail.com> wrote:> > Tom Eastep wrote: >> On 06/01/2013 08:37 AM, Tom Eastep wrote: >> >> >> I *can* reproduce it if I modify action.IFLOG as follows: >> >> >> ?IF $5 >> $5 >> ?ENDIF >> ?IF $1 >> NFLOG($1,0,1) >> ?ENDIF >> ?IF $2 >> ?SET @chain $3 ? $3 : " " >> ?SET @disposition $4 ? $4 : " " >> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >> ?ENDIF >> > You are (partially) right. I do have an extra check for the 5th > parameter at the very beginning and issue a "Drop" (not DROP!): > > ?IF $5 eq ''Drop'' > $5 > ?ENDIF > > The above statement is conditional upon $5 being equal to "Drop" and > when I call this action with "IFLOG(-,log1,-,drop,DROP) all all" that > surely won''t satisfy the "if" above as "DROP" ain''t "Drop", unless > shorewall makes case insensitive comparisons (if so, that certainly > wasn''t the case before).The warning is new in 4.5.17 -- the logic surrounding ?IF has not changed. So please send the real action.IFLOG contents and the actual rule in the RELATED section. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 9:05 AM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jun 1, 2013, at 9:00 AM, Dash Four <mr.dash.four@googlemail.com> wrote: > >> >> Tom Eastep wrote: >>> On 06/01/2013 08:37 AM, Tom Eastep wrote: >>> >>> >>> I *can* reproduce it if I modify action.IFLOG as follows: >>> >>> >>> ?IF $5 >>> $5 >>> ?ENDIF >>> ?IF $1 >>> NFLOG($1,0,1) >>> ?ENDIF >>> ?IF $2 >>> ?SET @chain $3 ? $3 : " " >>> ?SET @disposition $4 ? $4 : " " >>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>> ?ENDIF >>> >> You are (partially) right. I do have an extra check for the 5th >> parameter at the very beginning and issue a "Drop" (not DROP!): >> >> ?IF $5 eq ''Drop'' >> $5 >> ?ENDIF >> >> The above statement is conditional upon $5 being equal to "Drop" and >> when I call this action with "IFLOG(-,log1,-,drop,DROP) all all" that >> surely won''t satisfy the "if" above as "DROP" ain''t "Drop", unless >> shorewall makes case insensitive comparisons (if so, that certainly >> wasn''t the case before). > > > The warning is new in 4.5.17 -- the logic surrounding ?IF has not changed. > > So please send the real action.IFLOG contents and the actual rule in the RELATED section.Also, if you have defined your own action.Drop, then I would need to see it too. Because if it terminates with an unconditional DROP and has no CONTINUE rules, then the jump to ''Drop'' will terminate the current chain and any additional rules in that chain are unreachable. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 8:46 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 06/01/2013 06:47 AM, Dash Four wrote: >> >> Dash Four wrote: >>> In addition, I am getting two separate sets of warnings during startup: > >>> >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is >>> ''loopback'' /etc/shorewall/action.IFLOG (line 29) >>> from /etc/shorewall/tunnels (line EOF) >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is >>> ''loopback'' /etc/shorewall/action.IFLOG (line 31) >>> from /etc/shorewall/tunnels (line EOF) >>> [...again, ad nauseum ...] >>> >>> My /etc/shorewall/tunnels is empty. > > Please post the output of these warnings with the ''T'' option.I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? 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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On Jun 1, 2013, at 9:05 AM, Tom Eastep <teastep@shorewall.net> wrote: > > >> On Jun 1, 2013, at 9:00 AM, Dash Four <mr.dash.four@googlemail.com> wrote: >> >> >>> Tom Eastep wrote: >>> >>>> On 06/01/2013 08:37 AM, Tom Eastep wrote: >>>> >>>> >>>> I *can* reproduce it if I modify action.IFLOG as follows: >>>> >>>> >>>> ?IF $5 >>>> $5 >>>> ?ENDIF >>>> ?IF $1 >>>> NFLOG($1,0,1) >>>> ?ENDIF >>>> ?IF $2 >>>> ?SET @chain $3 ? $3 : " " >>>> ?SET @disposition $4 ? $4 : " " >>>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>>> ?ENDIF >>>> >>>> >>> You are (partially) right. I do have an extra check for the 5th >>> parameter at the very beginning and issue a "Drop" (not DROP!): >>> >>> ?IF $5 eq ''Drop'' >>> $5 >>> ?ENDIF >>> >>> The above statement is conditional upon $5 being equal to "Drop" and >>> when I call this action with "IFLOG(-,log1,-,drop,DROP) all all" that >>> surely won''t satisfy the "if" above as "DROP" ain''t "Drop", unless >>> shorewall makes case insensitive comparisons (if so, that certainly >>> wasn''t the case before). >>> >> The warning is new in 4.5.17 -- the logic surrounding ?IF has not changed. >> >> So please send the real action.IFLOG contents and the actual rule in the RELATED section. >> > > Also, if you have defined your own action.Drop, then I would need to see it too. Because if it terminates with an unconditional DROP and has no CONTINUE rules, then the jump to ''Drop'' will terminate the current chain and any additional rules in that chain are unreachable. >action.IFLOG ~~~~~~~~~~~~ # # Shorewall version 4 - Action Template # # /etc/shorewall/action.template # # This file is a template for files with names of the form # /etc/shorewall/action.<action-name> where <action> is an # ACTION defined in /etc/shorewall/actions. # # To define a new action: # # 1. Add the <action name> to /etc/shorewall/actions # 2. Copy this file to /etc/shorewall/action.<action name> # 3. Add the desired rules to that file. # # Please see http://shorewall.net/Actions.html for additional # information. # # Columns are the same as in /etc/shorewall/rules. # ####################################################################################################### # DO NOT REMOVE THE FOLLOWING LINE ?FORMAT 2 ################################################################################################################################################################################################# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT PORT(S) DEST LIMIT GROUP ?IF $5 eq ''Drop'' $5 ?ENDIF ?IF $1 NFLOG(1,0,1) ?ENDIF ?IF $2 ?SET @disposition $3 ?SET @chain $4 LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?ENDIF ?IF $5 && (! ($5 eq ''Drop'')) $5 ?ENDIF action.Drop ~~~~~~~~~~~ # # Shorewall version 4 - Drop Action # # /usr/share/shorewall/action.Drop # # The default DROP common rules # # This action is invoked before a DROP policy is enforced. The purpose # of the action is: # # a) Avoid logging lots of useless cruft. # b) Ensure that ''auth'' requests are rejected, even if the policy is # DROP. Otherwise, you may experience problems establishing # connections with servers that use auth. # c) Ensure that certain ICMP packets that are necessary for successful # internet operation are always ACCEPTed. # # IF YOU ARE HAVING CONNECTION PROBLEMS, CHANGING THIS FILE WON''T HELP!!!!!!!!! # ############################################################################### #TARGET SOURCE DEST PROTO DPORT SPORT # # # Reject ''auth'' # Auth(A_DROP) # # Don''t log broadcasts # dropBcast # # Drop packets that are in the INVALID state -- these are usually ICMP packets # and just confuse people when they appear in the log. # dropInvalid # # Drop Microsoft noise so that it doesn''t clutter up the log. # SMB(A_DROP) A_DropUPnP # # Drop ''newnotsyn'' traffic so that it doesn''t get logged. # dropNotSyn - - tcp # # Drop late-arriving DNS replies. These are just a nuisance and clutter up # the log. # DropDNSrep rules ~~~~~ [line 106] IFLOG(-,log1,-,drop,DROP) all all -bash-4.1# shorewall compile -T test [...] WARNING: The rule(s) generated by this entry are unreachable and have been discarded /etc/shorewall/action.IFLOG (line 36) from /etc/shorewall/rules (line 106) at /usr/share/perl5/Shorewall/Chains.pm line 7066 Shorewall::Chains::expand_rule(''HASH(0x8c5a500)'', 0, '''', '''', ''-'', ''-'', '''', ''LOG'', ''info(tcp_options,ip_options,macdecode,tcp_sequence,uid)'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2702 Shorewall::Rules::process_rule(''HASH(0x8c5a500)'', '''', ''LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2012 Shorewall::Rules::process_inline(''IFLOG'', ''HASH(0x8c5a500)'', '''', '''', ''IFLOG(-,log1,-,drop,DROP)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2512 Shorewall::Rules::process_rule(undef, '''', ''IFLOG(-,log1,-,drop,DROP)'', '''', ''fw'', ''local'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 3094 Shorewall::Rules::process_raw_rule() called at /usr/share/perl5/Shorewall/Rules.pm line 3267 Shorewall::Rules::process_rules(0) called at /usr/share/perl5/Shorewall/Compiler.pm line 822 Shorewall::Compiler::compiler(''script'', ''test'', ''directory'', '''', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 145 WARNING: The rule(s) generated by this entry are unreachable and have been discarded /etc/shorewall/action.IFLOG (line 39) from /etc/shorewall/rules (line 106) at /usr/share/perl5/Shorewall/Chains.pm line 7066 Shorewall::Chains::expand_rule(''HASH(0x8c5a500)'', 0, '''', '''', ''-'', ''-'', '''', ''DROP'', ''none'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2702 Shorewall::Rules::process_rule(''HASH(0x8c5a500)'', '''', ''DROP:none'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2012 Shorewall::Rules::process_inline(''IFLOG'', ''HASH(0x8c5a500)'', '''', '''', ''IFLOG(-,log1,-,drop,DROP)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2512 Shorewall::Rules::process_rule(undef, '''', ''IFLOG(-,log1,-,drop,DROP)'', '''', ''fw'', ''local'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 3094 Shorewall::Rules::process_raw_rule() called at /usr/share/perl5/Shorewall/Rules.pm line 3267 Shorewall::Rules::process_rules(0) called at /usr/share/perl5/Shorewall/Compiler.pm line 822 Shorewall::Compiler::compiler(''script'', ''test'', ''directory'', '''', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 145 WARNING: The rule(s) generated by this entry are unreachable and have been discarded /etc/shorewall/action.IFLOG (line 36) from /etc/shorewall/rules (line 106) at /usr/share/perl5/Shorewall/Chains.pm line 7066 Shorewall::Chains::expand_rule(''HASH(0x8c5a650)'', 0, '''', '''', ''-'', ''-'', '''', ''LOG'', ''info(tcp_options,ip_options,macdecode,tcp_sequence,uid)'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2702 Shorewall::Rules::process_rule(''HASH(0x8c5a650)'', '''', ''LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2012 Shorewall::Rules::process_inline(''IFLOG'', ''HASH(0x8c5a650)'', '''', '''', ''IFLOG(-,log1,-,drop,DROP)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2512 Shorewall::Rules::process_rule(undef, '''', ''IFLOG(-,log1,-,drop,DROP)'', '''', ''local'', ''fw'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 3094 Shorewall::Rules::process_raw_rule() called at /usr/share/perl5/Shorewall/Rules.pm line 3267 Shorewall::Rules::process_rules(0) called at /usr/share/perl5/Shorewall/Compiler.pm line 822 Shorewall::Compiler::compiler(''script'', ''test'', ''directory'', '''', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 145 WARNING: The rule(s) generated by this entry are unreachable and have been discarded /etc/shorewall/action.IFLOG (line 39) from /etc/shorewall/rules (line 106) at /usr/share/perl5/Shorewall/Chains.pm line 7066 Shorewall::Chains::expand_rule(''HASH(0x8c5a650)'', 0, '''', '''', ''-'', ''-'', '''', ''DROP'', ''none'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2702 Shorewall::Rules::process_rule(''HASH(0x8c5a650)'', '''', ''DROP:none'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2012 Shorewall::Rules::process_inline(''IFLOG'', ''HASH(0x8c5a650)'', '''', '''', ''IFLOG(-,log1,-,drop,DROP)'', ''-,log1,-,drop,DROP'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 2512 Shorewall::Rules::process_rule(undef, '''', ''IFLOG(-,log1,-,drop,DROP)'', '''', ''local'', ''fw'', ''-'', ''-'', ''-'', ...) called at /usr/share/perl5/Shorewall/Rules.pm line 3094 Shorewall::Rules::process_raw_rule() called at /usr/share/perl5/Shorewall/Rules.pm line 3267 Shorewall::Rules::process_rules(0) called at /usr/share/perl5/Shorewall/Compiler.pm line 822 Shorewall::Compiler::compiler(''script'', ''test'', ''directory'', '''', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 145 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? >What does a "default action" mean exactly? ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 09:48 AM, Dash Four wrote:> > Tom Eastep wrote: >> I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? >> > What does a "default action" mean exactly?http://www.shorewall.net/Actions.html#Default This is addressing the issue where the tunnels file is mentioned in the warning message. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 09:46 AM, Dash Four wrote:> > Tom Eastep wrote: >> On Jun 1, 2013, at 9:05 AM, Tom Eastep <teastep@shorewall.net> wrote: >> >> >>> On Jun 1, 2013, at 9:00 AM, Dash Four <mr.dash.four@googlemail.com> wrote: >>> >>> >>>> Tom Eastep wrote: >>>> >>>>> On 06/01/2013 08:37 AM, Tom Eastep wrote: >>>>> >>>>> >>>>> I *can* reproduce it if I modify action.IFLOG as follows: >>>>> >>>>> >>>>> ?IF $5 >>>>> $5 >>>>> ?ENDIF >>>>> ?IF $1 >>>>> NFLOG($1,0,1) >>>>> ?ENDIF >>>>> ?IF $2 >>>>> ?SET @chain $3 ? $3 : " " >>>>> ?SET @disposition $4 ? $4 : " " >>>>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>>>> ?ENDIF >>>>> >>>>> >>>> You are (partially) right. I do have an extra check for the 5th >>>> parameter at the very beginning and issue a "Drop" (not DROP!): >>>> >>>> ?IF $5 eq ''Drop'' >>>> $5 >>>> ?ENDIF >>>> >>>> The above statement is conditional upon $5 being equal to "Drop" and >>>> when I call this action with "IFLOG(-,log1,-,drop,DROP) all all" that >>>> surely won''t satisfy the "if" above as "DROP" ain''t "Drop", unless >>>> shorewall makes case insensitive comparisons (if so, that certainly >>>> wasn''t the case before). >>>> >>> The warning is new in 4.5.17 -- the logic surrounding ?IF has not changed. >>> >>> So please send the real action.IFLOG contents and the actual rule in the RELATED section. >>> >> >> Also, if you have defined your own action.Drop, then I would need to see it too. Because if it terminates with an unconditional DROP and has no CONTINUE rules, then the jump to ''Drop'' will terminate the current chain and any additional rules in that chain are unreachable. >> > action.IFLOG > ~~~~~~~~~~~~... Still no warnings. Please try compiling the attached config on your system and see if warnings are produced. 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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 06/01/2013 09:48 AM, Dash Four wrote: > >> Tom Eastep wrote: >> >>> I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? >>> >>> >> What does a "default action" mean exactly? >> > > http://www.shorewall.net/Actions.html#Default > > This is addressing the issue where the tunnels file is mentioned in the > warning message. >I don''t get this at all - my "tunnels" file is *empty*! I do have the IFLOG action used in the policy file (if that''s what you asked), but 1) I don''t see why is this a problem for shorewall; and 2) what is the relevance between IFLOG and /etc/shorewall/tunnels? ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 10:08 AM, Dash Four wrote:> > Tom Eastep wrote: >> On 06/01/2013 09:48 AM, Dash Four wrote: >> >>> Tom Eastep wrote: >>> >>>> I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? >>>> >>>> >>> What does a "default action" mean exactly? >>> >> >> http://www.shorewall.net/Actions.html#Default >> >> This is addressing the issue where the tunnels file is mentioned in the >> warning message. >> > I don''t get this at all - my "tunnels" file is *empty*! I do have the > IFLOG action used in the policy file (if that''s what you asked), but 1) > I don''t see why is this a problem for shorewall; and 2) what is the > relevance between IFLOG and /etc/shorewall/tunnels?The fact that tunnels is mentioned in the warning message is a harmless bug. The compiler is applying default actions when these warnings are issued; that is the significant point. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 06/01/2013 10:11 AM, Tom Eastep wrote:> On 06/01/2013 10:08 AM, Dash Four wrote: >> >> Tom Eastep wrote: >>> On 06/01/2013 09:48 AM, Dash Four wrote: >>> >>>> Tom Eastep wrote: >>>> >>>>> I''m assuming that IFLOG is also a default action? What parameters are being passed in that case? >>>>> >>>>> >>>> What does a "default action" mean exactly? >>>> >>> >>> http://www.shorewall.net/Actions.html#Default >>> >>> This is addressing the issue where the tunnels file is mentioned in the >>> warning message. >>> >> I don''t get this at all - my "tunnels" file is *empty*! I do have the >> IFLOG action used in the policy file (if that''s what you asked), but 1) >> I don''t see why is this a problem for shorewall; and 2) what is the >> relevance between IFLOG and /etc/shorewall/tunnels? > > The fact that tunnels is mentioned in the warning message is a harmless > bug. The compiler is applying default actions when these warnings are > issued; that is the significant point. >Possibly for both of these warning message cases, the best way to proceed is for you to: shorewall trace compile > trace 2>&1 And send me the ''trace'' file privately. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Dash Four wrote:> > Tom Eastep wrote: >> On Jun 1, 2013, at 9:05 AM, Tom Eastep <teastep@shorewall.net> wrote: >> >> >>> On Jun 1, 2013, at 9:00 AM, Dash Four <mr.dash.four@googlemail.com> >>> wrote: >>> >>> >>>> Tom Eastep wrote: >>>> >>>>> On 06/01/2013 08:37 AM, Tom Eastep wrote: >>>>> >>>>> >>>>> I *can* reproduce it if I modify action.IFLOG as follows: >>>>> >>>>> >>>>> ?IF $5 >>>>> $5 >>>>> ?ENDIF >>>>> ?IF $1 >>>>> NFLOG($1,0,1) >>>>> ?ENDIF >>>>> ?IF $2 >>>>> ?SET @chain $3 ? $3 : " " >>>>> ?SET @disposition $4 ? $4 : " " >>>>> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >>>>> ?ENDIF >>>>> >>>>> >>>> You are (partially) right. I do have an extra check for the 5th >>>> parameter at the very beginning and issue a "Drop" (not DROP!): >>>> >>>> ?IF $5 eq ''Drop'' >>>> $5 >>>> ?ENDIF >>>> >>>> The above statement is conditional upon $5 being equal to "Drop" >>>> and when I call this action with "IFLOG(-,log1,-,drop,DROP) all >>>> all" that surely won''t satisfy the "if" above as "DROP" ain''t >>>> "Drop", unless shorewall makes case insensitive comparisons (if so, >>>> that certainly wasn''t the case before). >>>> >>> The warning is new in 4.5.17 -- the logic surrounding ?IF has not >>> changed. >>> >>> So please send the real action.IFLOG contents and the actual rule in >>> the RELATED section. >>> >> >> Also, if you have defined your own action.Drop, then I would need to >> see it too. Because if it terminates with an unconditional DROP and >> has no CONTINUE rules, then the jump to ''Drop'' will terminate the >> current chain and any additional rules in that chain are unreachable. >> > action.IFLOG > ~~~~~~~~~~~~ > [...] > > rules > ~~~~~ > [line 106] > IFLOG(-,log1,-,drop,DROP) all allI think I finally got the bastard! Now, if I have the above statement in rules and have *no* other statements present, I am *not* getting these warnings. However, if I add the following: rules ~~~~~ SECTION RELATED IFLOG(-,log1,-,accept,ACCEPT) $FW local IFLOG(-,log1,-,accept,ACCEPT) local $FW IFLOG(-,log1,-,drop,DROP) all all Then I get the warnings - all 4 of them, directing me at the last statement line ("all all"). Now, if I comment out either of the "$FW local" or "local $FW" statements, then I get only 2 warnings instead. If I comment out the last statement, then I don''t get any warnings at all. So, what I think is happening is this: 1. The 3 statements above do something in combination that shorewall doesn''t like very much and issues these warnings. 2. shorewall is telling me porkies about the erroneous line in my "rules" statement file (that the problem is with my last statement), confusing the hell out of me. Over to you Tom... ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 10:39 AM, Dash Four <mr.dash.four@googlemail.com> wrote:> >> > I think I finally got the bastard! > > Now, if I have the above statement in rules and have *no* other > statements present, I am *not* getting these warnings. However, if I add > the following: > > rules > ~~~~~ > SECTION RELATED > IFLOG(-,log1,-,accept,ACCEPT) $FW local > IFLOG(-,log1,-,accept,ACCEPT) local $FW > > IFLOG(-,log1,-,drop,DROP) all all > > Then I get the warnings - all 4 of them, directing me at the last > statement line ("all all"). Now, if I comment out either of the "$FW > local" or "local $FW" statements, then I get only 2 warnings instead. If > I comment out the last statement, then I don''t get any warnings at all. > > So, what I think is happening is this: > > 1. The 3 statements above do something in combination that shorewall > doesn''t like very much and issues these warnings. > 2. shorewall is telling me porkies about the erroneous line in my > "rules" statement file (that the problem is with my last statement), > confusing the hell out of me. > > Over to you Tom…Okay -- apply this patch for now. 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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On Jun 1, 2013, at 10:39 AM, Dash Four <mr.dash.four@googlemail.com> wrote: > > >> I think I finally got the bastard! >> >> Now, if I have the above statement in rules and have *no* other >> statements present, I am *not* getting these warnings. However, if I add >> the following: >> >> rules >> ~~~~~ >> SECTION RELATED >> IFLOG(-,log1,-,accept,ACCEPT) $FW local >> IFLOG(-,log1,-,accept,ACCEPT) local $FW >> >> IFLOG(-,log1,-,drop,DROP) all all >> >> Then I get the warnings - all 4 of them, directing me at the last >> statement line ("all all"). Now, if I comment out either of the "$FW >> local" or "local $FW" statements, then I get only 2 warnings instead. If >> I comment out the last statement, then I don''t get any warnings at all. >> >> So, what I think is happening is this: >> >> 1. The 3 statements above do something in combination that shorewall >> doesn''t like very much and issues these warnings. >> 2. shorewall is telling me porkies about the erroneous line in my >> "rules" statement file (that the problem is with my last statement), >> confusing the hell out of me. >> >> Over to you Tom… >> > > Okay -- apply this patch for now. >Before I do that, I discovered another - nastier bug: actions ~~~~~~~ IFLOG inline SFLOG action.SFLOG ~~~~~~~~~~~~ ?SET p6 $6 ? $6 : @{chain} ?IF $5 eq ''Drop'' $5 ?ENDIF IFLOG($1,$2,$3,$4,$5) ; switch:${p6}_${7} ?IF $5 && (! ($5 eq ''Drop'')) $5 ?ENDIF rules ~~~~~ SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test produces: -A +fw2local -m set --match-set test dst -j ACCEPT Please note that this is a straight ACCEPT jump with no conditional switch. The rule produced should have been: -A +fw2local --condition fw2local_log_test_related -m set --match-set test dst -j ACCEPT ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 11:13 AM, Dash Four <mr.dash.four@googlemail.com> wrote:> > Tom Eastep wrote: >> On Jun 1, 2013, at 10:39 AM, Dash Four <mr.dash.four@googlemail.com> wrote: >> >> >>> I think I finally got the bastard! >>> >>> Now, if I have the above statement in rules and have *no* other >>> statements present, I am *not* getting these warnings. However, if I add >>> the following: >>> >>> rules >>> ~~~~~ >>> SECTION RELATED >>> IFLOG(-,log1,-,accept,ACCEPT) $FW local >>> IFLOG(-,log1,-,accept,ACCEPT) local $FW >>> >>> IFLOG(-,log1,-,drop,DROP) all all >>> >>> Then I get the warnings - all 4 of them, directing me at the last >>> statement line ("all all"). Now, if I comment out either of the "$FW >>> local" or "local $FW" statements, then I get only 2 warnings instead. If >>> I comment out the last statement, then I don''t get any warnings at all. >>> >>> So, what I think is happening is this: >>> >>> 1. The 3 statements above do something in combination that shorewall >>> doesn''t like very much and issues these warnings. >>> 2. shorewall is telling me porkies about the erroneous line in my >>> "rules" statement file (that the problem is with my last statement), >>> confusing the hell out of me. >>> >>> Over to you Tom… >>> >> >> Okay -- apply this patch for now. >> > Before I do that, I discovered another - nastier bug: > > actions > ~~~~~~~ > IFLOG inline > SFLOG > > action.SFLOG > ~~~~~~~~~~~~ > ?SET p6 $6 ? $6 : @{chain} > ?IF $5 eq ''Drop'' > $5 > ?ENDIF > IFLOG($1,$2,$3,$4,$5) ; switch:${p6}_${7} > ?IF $5 && (! ($5 eq ''Drop'')) > $5 > ?ENDIF > > rules > ~~~~~ > SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test > > produces: > > -A +fw2local -m set --match-set test dst -j ACCEPT > > Please note that this is a straight ACCEPT jump with no conditional > switch. The rule produced should have been: > > -A +fw2local --condition fw2local_log_test_related -m set --match-set > test dst -j ACCEPTI''m not even sure what the semantics of applying raw input to an inline invocation should be. Apply it to every entry in the action body? What if an entry in the body has raw input supplied? -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 11:35 AM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jun 1, 2013, at 11:13 AM, Dash Four <mr.dash.four@googlemail.com> wrote: > >> >> Tom Eastep wrote: >>> On Jun 1, 2013, at 10:39 AM, Dash Four <mr.dash.four@googlemail.com> wrote: >>> >>> >>>> I think I finally got the bastard! >>>> >>>> Now, if I have the above statement in rules and have *no* other >>>> statements present, I am *not* getting these warnings. However, if I add >>>> the following: >>>> >>>> rules >>>> ~~~~~ >>>> SECTION RELATED >>>> IFLOG(-,log1,-,accept,ACCEPT) $FW local >>>> IFLOG(-,log1,-,accept,ACCEPT) local $FW >>>> >>>> IFLOG(-,log1,-,drop,DROP) all all >>>> >>>> Then I get the warnings - all 4 of them, directing me at the last >>>> statement line ("all all"). Now, if I comment out either of the "$FW >>>> local" or "local $FW" statements, then I get only 2 warnings instead. If >>>> I comment out the last statement, then I don''t get any warnings at all. >>>> >>>> So, what I think is happening is this: >>>> >>>> 1. The 3 statements above do something in combination that shorewall >>>> doesn''t like very much and issues these warnings. >>>> 2. shorewall is telling me porkies about the erroneous line in my >>>> "rules" statement file (that the problem is with my last statement), >>>> confusing the hell out of me. >>>> >>>> Over to you Tom… >>>> >>> >>> Okay -- apply this patch for now. >>> >> Before I do that, I discovered another - nastier bug: >> >> actions >> ~~~~~~~ >> IFLOG inline >> SFLOG >> >> action.SFLOG >> ~~~~~~~~~~~~ >> ?SET p6 $6 ? $6 : @{chain} >> ?IF $5 eq ''Drop'' >> $5 >> ?ENDIF >> IFLOG($1,$2,$3,$4,$5) ; switch:${p6}_${7} >> ?IF $5 && (! ($5 eq ''Drop'')) >> $5 >> ?ENDIF >> >> rules >> ~~~~~ >> SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test >> >> produces: >> >> -A +fw2local -m set --match-set test dst -j ACCEPT >> >> Please note that this is a straight ACCEPT jump with no conditional >> switch. The rule produced should have been: >> >> -A +fw2local --condition fw2local_log_test_related -m set --match-set >> test dst -j ACCEPT > > I''m not even sure what the semantics of applying raw input to an inline invocation should be. Apply it to every entry in the action body? What if an entry in the body has raw input supplied?Never mind -- I misread the example. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:>> rules >> ~~~~~ >> SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test >> >> produces: >> >> -A +fw2local -m set --match-set test dst -j ACCEPT >> >> Please note that this is a straight ACCEPT jump with no conditional >> switch. The rule produced should have been: >> >> -A +fw2local --condition fw2local_log_test_related -m set --match-set >> test dst -j ACCEPT >> > > I''m not even sure what the semantics of applying raw input to an inline invocation should be. Apply it to every entry in the action body? What if an entry in the body has raw input supplied? >Yes, if the action is inline, then apply the switch to every statement in that action - I used to get this in previous versions and now I have a "wrapper" (called WSFLOG, funnily enough), which takes the "core" chain name, has a switch condition to a separate (action) chain where the rest of the statements are executed. That way, the switch is applied only once followed to a separate (action name) jump where everything else is executed. All this is broken now though, because, I suspect, the optimizer is optimizing away too much. If the action entry has an INLINE entry, then take it as it is (don''t try and add a switch if it is too much trouble): the premise on which the INLINE statement is executed was that whoever wrote it should take full responsibility over what needs to be present in that iptables statement. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 11:13 AM, Dash Four <mr.dash.four@googlemail.com> wrote:>> > Before I do that, I discovered another - nastier bug: > > actions > ~~~~~~~ > IFLOG inline > SFLOG > > action.SFLOG > ~~~~~~~~~~~~ > ?SET p6 $6 ? $6 : @{chain} > ?IF $5 eq ''Drop'' > $5 > ?ENDIF > IFLOG($1,$2,$3,$4,$5) ; switch:${p6}_${7} > ?IF $5 && (! ($5 eq ''Drop'')) > $5 > ?ENDIF > > rules > ~~~~~ > SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test > > produces: > > -A +fw2local -m set --match-set test dst -j ACCEPT > > Please note that this is a straight ACCEPT jump with no conditional > switch. The rule produced should have been: > > -A +fw2local --condition fw2local_log_test_related -m set --match-set > test dst -j ACCEPTThe rules generated by SFLOG are: NF-(A)-> filter:SFLOG:1 -A SFLOG -m condition --condition SFLOG_log_test_related -j ACCEPT NF-(A)-> filter:SFLOG:2 -A SFLOG -j ACCEPT Given that the chain ends in an unconditional ''-J ACCEPT'', the preceding rule is optimized away since the packet will be ACCEPTed regardless of whether the condition matches. Further optimization compiles the -m set match with -j ACCEPT and the SFLOG rule is deleted. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On Jun 1, 2013, at 12:45 PM, Tom Eastep <teastep@shorewall.net> wrote:>> > > The rules generated by SFLOG are: > > NF-(A)-> filter:SFLOG:1 -A SFLOG -m condition --condition SFLOG_log_test_related -j ACCEPT > NF-(A)-> filter:SFLOG:2 -A SFLOG -j ACCEPT > > Given that the chain ends in an unconditional ''-J ACCEPT'', the preceding rule is optimized away since the packet will be ACCEPTed regardless of whether the condition matches. Further optimization compiles the -m set match with -j ACCEPT and the SFLOG rule is deleted.The attached patch prevents this type of optimization of rules containing an nfacct match. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2