Beta 3 is now available for testing.
Problems corrected since Beta 2:
1) If a chain consisted of a single RETURN rule, optimize level 4
would handle it incorrectly by moving the RETURN rule to the
chain(s) that jumped to the single-rule chain.
Known Problems Remaining (in addition to the perennial Upstart issue):
1) The optimizer doesn''t delete ending RETURN rules from chains.
New Features since Beta 2:
1) There are now two new sections in the rules file:
INVALID
Allows definition of rules to be applied to packets in the
INVALID connection state.
UNTRACKED
Allows definition of rules to be applied to packets in the
UNTRACKED connection state (due to entries in the conntrack
file).
The implementation of these sections is modeled after that of the
RELATED section. There are options in shorewall.conf
(shorewall6.conf) that control the disposition and logging of
packets that fail to match any of the rules in the section.
INVALID_DISPOSITION
Valid values are CONTINUE, DROP, REJECT, and A_DROP.
The default is CONTINUE, which provides compatibility with
earlier releases (the packets are subject to the rules in
the NEW section).
INVALID_LOG_LEVEL.
Determines logging of packets handled by
INVALID_DISPOSITION. Empty by default (no logginig).
NOTRACK_DISPOSITION
Valid values are CONTINUE, ACCEPT, DROP, REJECT, A_ACCEPT
and A_DROP.
The default is CONTINUE, which provides compatibility with
earlier releases (the packets are subject to the rules in
the NEW section).
NOTRACK_LOG_LEVEL.
Determines logging of packets handled by
NOTRACK_DISPOSITION. Empty by default (no logging).
The new order of sections in the rules files is:
ALL
ESTABLISHED
RELATED
INVALID
NOTRACK
NEW
Thank you for testing,
-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 \________________________________________________
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
Tom There seems to be an infinite loop in the ''Optimizing ruleset'' phase. My ''Swiss Army Knife'' config. started successfully under Beta 2 in approximately 10 minutes on 2 GHZ Pentium 4. Under Beta 3, it is still running after 1 hour. Other than the first couple of minutes, all the time is spent in the ''Optimizing ruleset'' phase. I am not going to have the time to look at it until tomorrow. Do you want me to send you the config. or wait until I have had a chance to look at it? Steven. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 1/26/13 12:30 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>There seems to be an infinite loop in the ''Optimizing ruleset'' phase. > >My ''Swiss Army Knife'' config. started successfully under Beta 2 in >approximately 10 minutes on 2 GHZ Pentium 4. > >Under Beta 3, it is still running after 1 hour. Other than the first >couple of >minutes, all the time is spent in the ''Optimizing ruleset'' phase. > >I am not going to have the time to look at it until tomorrow. > >Do you want me to send you the config. or wait until I have had a chance >to >look at it?Steven, Please send it to me and I''ll take a look. Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 1/26/13 12:30 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>There seems to be an infinite loop in the ''Optimizing ruleset'' phase. > >My ''Swiss Army Knife'' config. started successfully under Beta 2 in >approximately 10 minutes on 2 GHZ Pentium 4. > >Under Beta 3, it is still running after 1 hour. Other than the first >couple of >minutes, all the time is spent in the ''Optimizing ruleset'' phase. > >I am not going to have the time to look at it until tomorrow. > >Do you want me to send you the config. or wait until I have had a chance >to >look at it?Steven send me the config and I was able to understand the problem. It was not a loop but optimize level 8 was certainly taking a lot longer than it needed to. Patch attached. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On Sunday 27 Jan 2013 01:38:06 Tom Eastep wrote:> On 1/26/13 12:30 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote: > >There seems to be an infinite loop in the ''Optimizing ruleset'' phase. > > > >My ''Swiss Army Knife'' config. started successfully under Beta 2 in > >approximately 10 minutes on 2 GHZ Pentium 4. > > > >Under Beta 3, it is still running after 1 hour. Other than the first > >couple of > >minutes, all the time is spent in the ''Optimizing ruleset'' phase. > > > >I am not going to have the time to look at it until tomorrow. > > > >Do you want me to send you the config. or wait until I have had a chance > >to > >look at it? > > Steven send me the config and I was able to understand the problem. It was > not a loop but optimize level 8 was certainly taking a lot longer than it > needed to. > > Patch attached. > > -Tom > You do not need a parachute to skydive. You only need a parachute to > skydive twice.Tom Confirmed, after applying the patch the config. takes just over 10 minutes to start up. Thanks. Steven. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
> Known Problems Remaining (in addition to the perennial Upstart issue): > > 1) The optimizer doesn''t delete ending RETURN rules from chains. >Have I understood this correctly that the above leaves a RETURN jump even if it is the only statement in a given chain (the opposite of what the optimizer was doing before I found the blrules bug and reported it)?> New Features since Beta 2: > > 1) There are now two new sections in the rules file: > > INVALID > > Allows definition of rules to be applied to packets in the > INVALID connection state. > > UNTRACKED > > Allows definition of rules to be applied to packets in the > UNTRACKED connection state (due to entries in the conntrack > file). > > The implementation of these sections is modeled after that of the > RELATED section. There are options in shorewall.conf > (shorewall6.conf) that control the disposition and logging of > packets that fail to match any of the rules in the section. > > INVALID_DISPOSITION > > Valid values are CONTINUE, DROP, REJECT, and A_DROP. > > The default is CONTINUE, which provides compatibility with > earlier releases (the packets are subject to the rules in > the NEW section). > > INVALID_LOG_LEVEL. > > Determines logging of packets handled by > INVALID_DISPOSITION. Empty by default (no logginig). > > NOTRACK_DISPOSITION > > Valid values are CONTINUE, ACCEPT, DROP, REJECT, A_ACCEPT > and A_DROP. > > The default is CONTINUE, which provides compatibility with > earlier releases (the packets are subject to the rules in > the NEW section). > > NOTRACK_LOG_LEVEL. > > Determines logging of packets handled by > NOTRACK_DISPOSITION. Empty by default (no logging). > > The new order of sections in the rules files is: > > ALL > ESTABLISHED > RELATED > INVALID > NOTRACK > NEW >That''s even better than what I suggested previously - much cleaner and various conntrack states are treated equally. Just out of interest, a couple of queries: 1. How do you deal with the blrules statements and do you place any state match restrictions upon them (like --cstate NEW,INVALID as was the case up until now)? If so, I just realised that the UNTRACKED state is not matched here so I think you need to make a provision for that. 2. Do the statements in blrules still go before anything in "rules" (including the new sections you''ve introduced in this Beta)? 3. In what preference do you place the RELATED, INVALID and UNTRACKED state matches in the chain groups - which one goes 1st, 2nd and 3rd (I presume you have separate sub-chains for those in each a2b chain pair)? 4. Do you optimise each of these 3 sub-chains (for example, if I have the same set of rules for, say, RELATED and UNTRACKED, do you combine these into one new chain)? I would be able to test this (and anything else you may introduce in the meantime) next weekend when I am hopeful I could dedicate some more time. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 05:54 AM, Steven Jan Springl wrote:>> >> Steven sent me the config and I was able to understand the problem. It was >> not a loop but optimize level 8 was certainly taking a lot longer than it >> needed to. >> >> Patch attached. > > Confirmed, after applying the patch the config. takes just over 10 minutes to > start up.Thanks Steven, -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 06:33 AM, Mr Dash Four wrote:> >> Known Problems Remaining (in addition to the perennial Upstart issue): >> >> 1) The optimizer doesn''t delete ending RETURN rules from chains. >> > Have I understood this correctly that the above leaves a RETURN jump > even if it is the only statement in a given chain (the opposite of what > the optimizer was doing before I found the blrules bug and reported it)?You apparently missed the ''Problem Corrected''. The optimizer now eliminates single-RETURN-rule chains. The remaining issue is that when RETURN is the target of the last rule in a multi-rule chain, the optimizer isn''t deleting the superfluous rule.> >> New Features since Beta 2: >> >> 1) There are now two new sections in the rules file: >> >> INVALID >> >> Allows definition of rules to be applied to packets in the >> INVALID connection state. >> >> UNTRACKED...>> >> The new order of sections in the rules files is: >> >> ALL >> ESTABLISHED >> RELATED >> INVALID >> NOTRACK >> NEW >> > That''s even better than what I suggested previously - much cleaner and > various conntrack states are treated equally. Just out of interest, a > couple of queries: > > 1. How do you deal with the blrules statements and do you place any > state match restrictions upon them (like --cstate NEW,INVALID as was the > case up until now)? If so, I just realised that the UNTRACKED state is > not matched here so I think you need to make a provision for that.Yesterday (after uploading Beta 3), I committed a change that adds UNTRACKED to the states being passed to blrules. It has always been one of the states passed to the dynamic blacklisting chain but not for blrules.> 2. Do the statements in blrules still go before anything in "rules" > (including the new sections you''ve introduced in this Beta)?Yes.> 3. In what preference do you place the RELATED, INVALID and UNTRACKED > state matches in the chain groups - which one goes 1st, 2nd and 3rd (I > presume you have separate sub-chains for those in each a2b chain pair)?There are separate sub-chains and they are handled in the same order as the sections.> 4. Do you optimise each of these 3 sub-chains (for example, if I have > the same set of rules for, say, RELATED and UNTRACKED, do you combine > these into one new chain)?As always, when multiple chains have identical rules, the optimizer (level 8) will combine them into a single chain.> > I would be able to test this (and anything else you may introduce in the > meantime) next weekend when I am hopeful I could dedicate some more time. >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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
Tom When UNTRACKED_DISPOSITION=CONTINUE the following error message is produced: ERROR: Invalid value (CONTINUE) for UNTRACKED_DISPOSITION Steven. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 07:55 AM, Steven Jan Springl wrote:> When UNTRACKED_DISPOSITION=CONTINUE the following error message is produced: > > ERROR: Invalid value (CONTINUE) for UNTRACKED_DISPOSITION >Oops -- patch attached. Thanks Steven, -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On Sunday 27 Jan 2013 16:11:34 Tom Eastep wrote:> On 01/27/2013 07:55 AM, Steven Jan Springl wrote: > > When UNTRACKED_DISPOSITION=CONTINUE the following error message is > > produced: > > > > ERROR: Invalid value (CONTINUE) for UNTRACKED_DISPOSITION > > Oops -- patch attached. > > Thanks Steven, > -TomTom Confirmed, the patch corrects the issue. Thanks. Steven. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 08:18 AM, Steven Jan Springl wrote:> > Confirmed, the patch corrects the issue. >Thanks Steven, -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
Tom
The attached minimal config. produces the following error messages:
ERROR: Internal error in Shorewall::Chains::new_chain at
/usr/share/shorewall/Shorewall/Chains.pm line 1972 /etc/shorewall2A18/rules
(line 23) at /usr/share/shorewall/Shorewall/Config.pm line 1205
Shorewall::Config::fatal_error(''Internal error in
Shorewall::Chains::new_chain at /usr/share/...'') called at
/usr/share/shorewall/Shorewall/Config.pm line 1243
Shorewall::Config::assert('''') called at
/usr/share/shorewall/Shorewall/Chains.pm line 1972
Shorewall::Chains::new_chain(''filter'',
''_fw2lan'') called at
/usr/share/shorewall/Shorewall/Rules.pm line 883
Shorewall::Rules::finish_chain_section(''HASH(0xac62830)'',
''HASH(0xac62830)'',
''ESTABLISHED,RELATED,INVALID,UNTRACKED'') called at
/usr/share/shorewall/Shorewall/Rules.pm line 1000
Shorewall::Rules::finish_section(''ESTABLISHED,RELATED,INVALID,UNTRACKED'')
called at /usr/share/shorewall/Shorewall/Rules.pm line 2612
Shorewall::Rules::process_section(''NEW'') called at
/usr/share/shorewall/Shorewall/Rules.pm line 2692
Shorewall::Rules::process_rule() called at
/usr/share/shorewall/Shorewall/Rules.pm line 2886
Shorewall::Rules::process_rules(0) called at
/usr/share/shorewall/Shorewall/Compiler.pm line 823
Shorewall::Compiler::compiler(''script'',
''/var/lib/shorewall/.start'',
''directory'', ''/etc/shorewall2A18'',
''verbosity'', 1, ''timestamp'', 0,
''debug'',
...) called at /usr/share/shorewall/compiler.pl line 142
Steven.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 08:52 AM, Steven Jan Springl wrote:> The attached minimal config. produces the following error messages: > > ERROR: Internal error in Shorewall::Chains::new_chain at > /usr/share/shorewall/Shorewall/Chains.pm line 1972 /etc/shorewall2A18/rules > (line 23) at /usr/share/shorewall/Shorewall/Config.pm line 1205 > > Shorewall::Config::fatal_error(''Internal error in > Shorewall::Chains::new_chain at /usr/share/...'') called at > /usr/share/shorewall/Shorewall/Config.pm line 1243 > > Shorewall::Config::assert('''') called at > /usr/share/shorewall/Shorewall/Chains.pm line 1972 > > Shorewall::Chains::new_chain(''filter'', ''_fw2lan'') called at > /usr/share/shorewall/Shorewall/Rules.pm line 883 > > Shorewall::Rules::finish_chain_section(''HASH(0xac62830)'', > ''HASH(0xac62830)'', ''ESTABLISHED,RELATED,INVALID,UNTRACKED'') called at > /usr/share/shorewall/Shorewall/Rules.pm line 1000 > > Shorewall::Rules::finish_section(''ESTABLISHED,RELATED,INVALID,UNTRACKED'') > called at /usr/share/shorewall/Shorewall/Rules.pm line 2612 > > Shorewall::Rules::process_section(''NEW'') called at > /usr/share/shorewall/Shorewall/Rules.pm line 2692 > > Shorewall::Rules::process_rule() called at > /usr/share/shorewall/Shorewall/Rules.pm line 2886 > > Shorewall::Rules::process_rules(0) called at > /usr/share/shorewall/Shorewall/Compiler.pm line 823 > > Shorewall::Compiler::compiler(''script'', ''/var/lib/shorewall/.start'', > ''directory'', ''/etc/shorewall2A18'', ''verbosity'', 1, ''timestamp'', 0, ''debug'', > ...) called at /usr/share/shorewall/compiler.pl line 142 >The attached patch corrects that problem. Thanks Steven, -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On Sunday 27 Jan 2013 18:09:43 Tom Eastep wrote:> On 01/27/2013 08:52 AM, Steven Jan Springl wrote: > > The attached minimal config. produces the following error messages: > > > > ERROR: Internal error in Shorewall::Chains::new_chain at > > /usr/share/shorewall/Shorewall/Chains.pm line 1972 > > /etc/shorewall2A18/rules (line 23) at > > /usr/share/shorewall/Shorewall/Config.pm line 1205 > > > > Shorewall::Config::fatal_error(''Internal error in > > > > Shorewall::Chains::new_chain at /usr/share/...'') called at > > /usr/share/shorewall/Shorewall/Config.pm line 1243 > > > > Shorewall::Config::assert('''') called at > > > > /usr/share/shorewall/Shorewall/Chains.pm line 1972 > > > > Shorewall::Chains::new_chain(''filter'', ''_fw2lan'') called at > > > > /usr/share/shorewall/Shorewall/Rules.pm line 883 > > > > Shorewall::Rules::finish_chain_section(''HASH(0xac62830)'', > > > > ''HASH(0xac62830)'', ''ESTABLISHED,RELATED,INVALID,UNTRACKED'') called at > > /usr/share/shorewall/Shorewall/Rules.pm line 1000 > > > > Shorewall::Rules::finish_section(''ESTABLISHED,RELATED,INVALID,UNTRACKED'' > > ) > > > > called at /usr/share/shorewall/Shorewall/Rules.pm line 2612 > > > > Shorewall::Rules::process_section(''NEW'') called at > > > > /usr/share/shorewall/Shorewall/Rules.pm line 2692 > > > > Shorewall::Rules::process_rule() called at > > > > /usr/share/shorewall/Shorewall/Rules.pm line 2886 > > > > Shorewall::Rules::process_rules(0) called at > > > > /usr/share/shorewall/Shorewall/Compiler.pm line 823 > > > > Shorewall::Compiler::compiler(''script'', ''/var/lib/shorewall/.start'', > > > > ''directory'', ''/etc/shorewall2A18'', ''verbosity'', 1, ''timestamp'', 0, > > ''debug'', ...) called at /usr/share/shorewall/compiler.pl line 142 > > The attached patch corrects that problem. > > Thanks Steven, > -TomTom Confirmed, the patch fixes the problem. Thanks. Steven. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 10:29 AM, Steven Jan Springl wrote:> > Confirmed, the patch fixes the problem. >Thanks Steven, -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 07:45 AM, Tom Eastep wrote:> >> 3. In what preference do you place the RELATED, INVALID and UNTRACKED >> state matches in the chain groups - which one goes 1st, 2nd and 3rd (I >> presume you have separate sub-chains for those in each a2b chain pair)? > > There are separate sub-chains and they are handled in the same order as > the sections. >Note, however, that Beta 3 will often handle one of the other states prior to ESTABLISHED. That has been corrected in my current tree. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
>>> Known Problems Remaining (in addition to the perennial Upstart issue): >>> >>> 1) The optimizer doesn''t delete ending RETURN rules from chains. >>> >>> >> Have I understood this correctly that the above leaves a RETURN jump >> even if it is the only statement in a given chain (the opposite of what >> the optimizer was doing before I found the blrules bug and reported it)? >> > > You apparently missed the ''Problem Corrected''.I did read it, but didn''t include it intentionally as for some reason I thought that this was the same issue. Never mind...>> 1. How do you deal with the blrules statements and do you place any >> state match restrictions upon them (like --cstate NEW,INVALID as was the >> case up until now)? If so, I just realised that the UNTRACKED state is >> not matched here so I think you need to make a provision for that. >> > > Yesterday (after uploading Beta 3), I committed a change that adds > UNTRACKED to the states being passed to blrules. It has always been one > of the states passed to the dynamic blacklisting chain but not for blrules. >Should I assume that BLACKLISTNEWONLY covers that state (UNTRACKED)? In other words when BLACKLISTNEWONLY=Yes, I''ll have a jump to the blacklist chain when states are NEW,INVALID,UNTRACKED or is this different? The reason I asked this is very simple: currently you have 5 different sections in "rules", dealing with the 5 possible states of the connection. In its present state, "blrules" can only have a single on/off switch - either have NEW,INVALID,UNTRACKED (BLACKLISTNEWONLY=Yes) or don''t (BLACKLISTNEWONLY=No), in which case the blacklist chain is traversed for every packet regardless of its state - a bit like having only a "SECTION ALL". This, provided I have understood you correctly as to the meaning of that shorewall.conf variable. Why not introduce the same sections you currently have in "rules", in "blrules"? That way, I could control very precisely what should be included when, in my blacklist chain. I might, for example, want to blacklist everything in INVALID state, but have different processing rules for ESTABLISHED, as well as NEW. In the present form of "blrules" I can''t really do that. Another suggestion in this respect: How easy would it be to implement the SECTION statement to include multiple states, like "SECTION NEW,INVALID" for example? That would ease up having to write the same thing twice (only to have the optimizer combine it later on in some nondescript chain name). In that way, optimisation should also be easier.>> 3. In what preference do you place the RELATED, INVALID and UNTRACKED >> state matches in the chain groups - which one goes 1st, 2nd and 3rd (I >> presume you have separate sub-chains for those in each a2b chain pair)? >> > > There are separate sub-chains and they are handled in the same order as > the sections. >So, if I have this: SECTION ESTABLISHED [...] SECTION NEW [...] SECTION INVALID [...] SECTION RELATED [...] SECTION NOTRACK [...] Does that mean the way the chains are built, the "ESTABLISHED" state goes first, followed by NEW, then INVALID, RELATED and finally UNTRACKED since that is how I ordered these states in my "rules" file? ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 01:57 PM, Mr Dash Four wrote:>> Yesterday (after uploading Beta 3), I committed a change that adds >> UNTRACKED to the states being passed to blrules. It has always been one >> of the states passed to the dynamic blacklisting chain but not for blrules. >> > Should I assume that BLACKLISTNEWONLY covers that state (UNTRACKED)? In > other words when BLACKLISTNEWONLY=Yes, I''ll have a jump to the blacklist > chain when states are NEW,INVALID,UNTRACKED or is this different?You assume correctly.> > The reason I asked this is very simple: currently you have 5 different > sections in "rules", dealing with the 5 possible states of the connection. > > In its present state, "blrules" can only have a single on/off switch - > either have NEW,INVALID,UNTRACKED (BLACKLISTNEWONLY=Yes) or don''t > (BLACKLISTNEWONLY=No), in which case the blacklist chain is traversed > for every packet regardless of its state - a bit like having only a > "SECTION ALL". This, provided I have understood you correctly as to the > meaning of that shorewall.conf variable.You understand correctly.> > Why not introduce the same sections you currently have in "rules", in > "blrules"? That way, I could control very precisely what should be > included when, in my blacklist chain.Because the blrules file is still handled internally as a section in the rules file.> I might, for example, want to > blacklist everything in INVALID state, but have different processing > rules for ESTABLISHED, as well as NEW. In the present form of "blrules" > I can''t really do that.The Invalid, Related and Untracked actions can be used in the blrules file. I can also add an Established action. I''m also working on the ability to pass arbitrary actions to those macros; again, won''t make it into 4.5.13 though.> > Another suggestion in this respect: How easy would it be to implement > the SECTION statement to include multiple states, like "SECTION > NEW,INVALID" for example? That would ease up having to write the same > thing twice (only to have the optimizer combine it later on in some > nondescript chain name). In that way, optimisation should also be easier.I have structured the SECTION implementation to allow that in the future; it won''t make it into 4.5.13 though.> >>> 3. In what preference do you place the RELATED, INVALID and UNTRACKED >>> state matches in the chain groups - which one goes 1st, 2nd and 3rd (I >>> presume you have separate sub-chains for those in each a2b chain pair)? >>> >> >> There are separate sub-chains and they are handled in the same order as >> the sections. >> > So, if I have this: > > SECTION ESTABLISHED > [...] > SECTION NEW > [...] > SECTION INVALID > [...] > SECTION RELATED > [...] > SECTION NOTRACK > [...] > Does that mean the way the chains are built, the "ESTABLISHED" state > goes first, followed by NEW, then INVALID, RELATED and finally UNTRACKED > since that is how I ordered these states in my "rules" file?No. The order of the sections is fixed today and will remain 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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
>> Why not introduce the same sections you currently have in "rules", in >> "blrules"? That way, I could control very precisely what should be >> included when, in my blacklist chain. >> > > Because the blrules file is still handled internally as a section in the > rules file. >And that makes it impossible to be implemented now/in the future?>> I might, for example, want to >> blacklist everything in INVALID state, but have different processing >> rules for ESTABLISHED, as well as NEW. In the present form of "blrules" >> I can''t really do that. >> > > The Invalid, Related and Untracked actions can be used in the blrules > file. I can also add an Established action.That''s not the same thing as having a specific section dedicated for each state where a set of rules for that state could be defined, is it?> I''m also working on the > ability to pass arbitrary actions to those macros; again, won''t make it > into 4.5.13 though. >I also take it passing arbitrary actions to the various *_DISPOSITION shorewall.conf variables is also a no-go?> I have structured the SECTION implementation to allow that in the > future; it won''t make it into 4.5.13 though. >That''s fine, thanks.>> So, if I have this: >> >> SECTION ESTABLISHED >> [...] >> SECTION NEW >> [...] >> SECTION INVALID >> [...] >> SECTION RELATED >> [...] >> SECTION NOTRACK >> [...] >> Does that mean the way the chains are built, the "ESTABLISHED" state >> goes first, followed by NEW, then INVALID, RELATED and finally UNTRACKED >> since that is how I ordered these states in my "rules" file? >> > > No. The order of the sections is fixed today and will remain so. >Which is what exactly? Don''t you think that is a bit restrictive? For example, if I want my ESTABLISHED state to take precedence (by "precedence" I mean traverse the absolute minimum set of rules), I can''t really control that. Similarly, if I want the INVALID state set of rules to be dealt with first (thus placing the INVALID section at the top of "rules"), I have no control of that either? ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 03:38 PM, Mr Dash Four wrote:> >>> Why not introduce the same sections you currently have in "rules", in >>> "blrules"? That way, I could control very precisely what should be >>> included when, in my blacklist chain. >>> >> >> Because the blrules file is still handled internally as a section in the >> rules file. >> > And that makes it impossible to be implemented now/in the future?It makes it difficult enough that I wont do it.> >>> I might, for example, want to >>> blacklist everything in INVALID state, but have different processing >>> rules for ESTABLISHED, as well as NEW. In the present form of "blrules" >>> I can''t really do that. >>> >> >> The Invalid, Related and Untracked actions can be used in the blrules >> file. I can also add an Established action. > That''s not the same thing as having a specific section dedicated for > each state where a set of rules for that state could be defined, is it?No.> >> I''m also working on the >> ability to pass arbitrary actions to those macros; again, won''t make it >> into 4.5.13 though. >> > I also take it passing arbitrary actions to the various *_DISPOSITION > shorewall.conf variables is also a no-go?Given that you can accomplish the same thing already, it hardly seems worth it. e.g., finish the section with an unconditional action invocation and specify CONTINUE as the _DISPOSITION.> >> I have structured the SECTION implementation to allow that in the >> future; it won''t make it into 4.5.13 though. >> > That''s fine, thanks. > >>> So, if I have this: >>> >>> SECTION ESTABLISHED >>> [...] >>> SECTION NEW >>> [...] >>> SECTION INVALID >>> [...] >>> SECTION RELATED >>> [...] >>> SECTION NOTRACK >>> [...] >>> Does that mean the way the chains are built, the "ESTABLISHED" state >>> goes first, followed by NEW, then INVALID, RELATED and finally UNTRACKED >>> since that is how I ordered these states in my "rules" file? >>> >> >> No. The order of the sections is fixed today and will remain so. >> > Which is what exactly?As listed in the release notes and in shorewall-rules(5). Don''t you think that is a bit restrictive. I don''t think it is restrictive enough to change.> > For example, if I want my ESTABLISHED state to take precedence (by > "precedence" I mean traverse the absolute minimum set of rules), I can''t > really control that.I think that the right thing to do there is to redefine FASTACCEPT to only include ESTABLISHED state. Then FASTACCEPT=Yes puts the ESTABLISHED accept rule very early. In fact, I should do that for this release (given the recently discovered issues with RELATED).> Similarly, if I want the INVALID state set of rules > to be dealt with first (thus placing the INVALID section at the top of > "rules"), I have no control of that either? >No. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/27/2013 03:54 PM, Tom Eastep wrote:>> For example, if I want my ESTABLISHED state to take precedence (by >> "precedence" I mean traverse the absolute minimum set of rules), I can''t >> really control that. > > I think that the right thing to do there is to redefine FASTACCEPT to > only include ESTABLISHED state. Then FASTACCEPT=Yes puts the ESTABLISHED > accept rule very early. In fact, I should do that for this release > (given the recently discovered issues with RELATED).I reviewed how FASTACCEPT works and I''m not sure I''ll change it. If RELATED_DISPOSITION is anything but ''ACCEPT'' or if RELATED_LOG_LEVEL is set, then only ESTABLISHED packets are accepted early. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
>> I also take it passing arbitrary actions to the various *_DISPOSITION >> shorewall.conf variables is also a no-go? > > Given that you can accomplish the same thing already, it hardly seems > worth it. e.g., finish the section with an unconditional action > invocation and specify CONTINUE as the _DISPOSITION.Please elaborate. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
> 1) There are now two new sections in the rules file: > > INVALID >[...] > NOTRACK_DISPOSITION > > Valid values are CONTINUE, ACCEPT, DROP, REJECT, A_ACCEPT > and A_DROP. > > The default is CONTINUE, which provides compatibility with > earlier releases (the packets are subject to the rules in > the NEW section). > > NOTRACK_LOG_LEVEL. > > Determines logging of packets handled by > NOTRACK_DISPOSITION. Empty by default (no logging). >1. Optimise same-jump and same-match rules which have different states: -A net2fw -m conntrack --ctstate ESTABLISHED -j ACCEPT -A net2fw -m conntrack --ctstate RELATED -j ACCEPT could be optimised to -A net2fw -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2. INVALID_DISPOSITION: A_REJECT, A_ACCEPT and ACCEPT were accepted by shorewall (no errors were given), though these were ultimately ignored as no iptables rules were produced. At an earlier stage of the testing of this, INVALID_DISPOSITION option seemed to be completely ignored whatever value I specified - if I have "INVALID_DISPOSITION=DROP" in shorewall.conf for example, there was nothing generated with INVALID state match and DROP jump. Unfortunately, I was not able to reproduce this at the later stages. 3. UNTRACKED_DISPOSITION (this is listed as NOTRACK_DISPOSITION in the announcement above, though "shorewall update" converts it and treats it as UNTRACKED_DISPOSITION): CONTINUE works, ACCEPT and A_ACCEPT are ignored completely for whatever reason (I expected -j ACCEPT/A_ACCEPT), A_DROP is accepted and works (this wasn''t in the announcement) and A_REJECT is accepted (no syntax error is given), but ultimately no iptables rule is produced. The strangest thing for UNTRACKED_DISPOSITION as well was, that at one stage (at the beginning of the testing) I was able to produce an adequate rule only for some of the chains: I had the appropriate "--cstate UNTRACKED -j <ACTION>" generated for my fw2local and local2fw for example, but not for fw2net and net2fw chains. Again, I was unable to reproduce this later on, unfortunately! 4. "SECTION UNTRACKED" is accepted (while "SECTION NOTRACK" isn''t) as a section statement in (at least) "rules" (not that I am complaining as to me it is more intuitive) - "ERROR: Invalid SECTION (NOTRACK)" is shown. 5. Similar to 1. above: if I have exactly the same statements in any two sections in "rules" (say INVALID and UNTRACKED), the chain itself is properly optimised, but the "state" isn''t. I get this instead: -A fw2net -m conntrack --ctstate INVALID -j ~comb0 -A fw2net -m conntrack --ctstate UNTRACKED -j ~comb0 That should have been "-A fw2net -m conntrack --ctstate INVALID,UNTRACKED -j ~comb0" ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/01/2013 08:01 PM, Mr Dash Four wrote:>>> I also take it passing arbitrary actions to the various *_DISPOSITION >>> shorewall.conf variables is also a no-go? >> >> Given that you can accomplish the same thing already, it hardly seems >> worth it. e.g., finish the section with an unconditional action >> invocation and specify CONTINUE as the _DISPOSITION. > Please elaborate.shorewall.conf: RELATED_DISPOSITION=CONTINUE rules: SECTION RELATED ... ... foo all all The above is equivalent to RELATED_DISPOSITION=foo -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 \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/01/2013 08:01 PM, Mr Dash Four wrote:> >> 1) There are now two new sections in the rules file: >> >> INVALID [...] NOTRACK_DISPOSITION >> >> Valid values are CONTINUE, ACCEPT, DROP, REJECT, A_ACCEPT and >> A_DROP. >> >> The default is CONTINUE, which provides compatibility with earlier >> releases (the packets are subject to the rules in the NEW >> section). >> >> NOTRACK_LOG_LEVEL. >> >> Determines logging of packets handled by NOTRACK_DISPOSITION. Empty >> by default (no logging). >> > 1. Optimise same-jump and same-match rules which have different > states: > > -A net2fw -m conntrack --ctstate ESTABLISHED -j ACCEPT -A net2fw -m > conntrack --ctstate RELATED -j ACCEPT > > could be optimised to > > -A net2fw -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTYes -- as I stated in my earlier post, there is still areas for improvement in optimizing state handling.> > 2. INVALID_DISPOSITION: A_REJECT, A_ACCEPT and ACCEPT were accepted > by shorewall (no errors were given), though these were ultimately > ignored as no iptables rules were produced. > > At an earlier stage of the testing of this, INVALID_DISPOSITION > option seemed to be completely ignored whatever value I specified - > if I have "INVALID_DISPOSITION=DROP" in shorewall.conf for example, > there was nothing generated with INVALID state match and DROP jump. > Unfortunately, I was not able to reproduce this at the later stages.Patch attached. Note that it removes A_ACCEPT and ACCEPT from the possible choices for INVALID_DISPOSITION (which is as documented).> > 3. UNTRACKED_DISPOSITION (this is listed as NOTRACK_DISPOSITION in > the announcement above, though "shorewall update" converts it and > treats it as UNTRACKED_DISPOSITION): CONTINUE works, ACCEPT and > A_ACCEPT are ignored completely for whatever reason (I expected -j > ACCEPT/A_ACCEPT), A_DROP is accepted and works (this wasn''t in the > announcement) and A_REJECT is accepted (no syntax error is given), > but ultimately no iptables rule is produced.The attached patch should correct that problem as well.> > The strangest thing for UNTRACKED_DISPOSITION as well was, that at > one stage (at the beginning of the testing) I was able to produce an > adequate rule only for some of the chains: I had the appropriate > "--cstate UNTRACKED -j <ACTION>" generated for my fw2local and > local2fw for example, but not for fw2net and net2fw chains. Again, I > was unable to reproduce this later on, unfortunately!There are two cases for handling <state>_DISPOSITION; one where the secondary chain is created and one where it is not. One of them was probably broken earlier (this was also the case in the problem corrected by the attachment).> > 4. "SECTION UNTRACKED" is accepted (while "SECTION NOTRACK" isn''t) as > a section statement in (at least) "rules" (not that I am complaining > as to me it is more intuitive) - "ERROR: Invalid SECTION (NOTRACK)" > is shown.Yes -- obviously a typo in the release notes.> > 5. Similar to 1. above: if I have exactly the same statements in any > two sections in "rules" (say INVALID and UNTRACKED), the chain itself > is properly optimised, but the "state" isn''t. I get this instead: > > -A fw2net -m conntrack --ctstate INVALID -j ~comb0 -A fw2net -m > conntrack --ctstate UNTRACKED -j ~comb0 > > That should have been "-A fw2net -m conntrack --ctstate > INVALID,UNTRACKED -j ~comb0" >That''s an even harder case for the compiler to detect. -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 \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
>> Please elaborate. > > shorewall.conf: > > RELATED_DISPOSITION=CONTINUE > > rules: > > SECTION RELATED > ... > ... > foo all all > > The above is equivalent to RELATED_DISPOSITION=fooThanks, I could live with that, though would still prefer it if I was able to use custom actions and not pollute my "rules" unnecessarily - it is filled to the brim as it is. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
> Patch attached. Note that it removes A_ACCEPT and ACCEPT from the > possible choices for INVALID_DISPOSITION (which is as documented).A_REJECT is allowed (rightly so!) - all you need is to amend the original announcement as A_REJECT wasn''t included there. Another query: out of interest, why do you use "-g A_X" (X=DROP,REJECT) and not a regular jump - what is there to be gained by that?>> 3. UNTRACKED_DISPOSITION (this is listed as NOTRACK_DISPOSITION in >> the announcement above, though "shorewall update" converts it and >> treats it as UNTRACKED_DISPOSITION): CONTINUE works, ACCEPT and >> A_ACCEPT are ignored completely for whatever reason (I expected -j >> ACCEPT/A_ACCEPT), A_DROP is accepted and works (this wasn''t in the >> announcement) and A_REJECT is accepted (no syntax error is given), >> but ultimately no iptables rule is produced. > > The attached patch should correct that problem as well.ACCEPT is still ignored, A_ACCEPT is, this time, correctly handled and so are the rest of the built-in actions (you need to amend you original announcement to include A_REJECT).>> -A fw2net -m conntrack --ctstate INVALID -j ~comb0 >> -A fw2net -m conntrack --ctstate UNTRACKED -j ~comb0 >> >> That should have been "-A fw2net -m conntrack --ctstate >> INVALID,UNTRACKED -j ~comb0" >> > > That''s an even harder case for the compiler to detect.The way I see it, if the jump target is the same all you have to do is check for different states and combine them if that is the case and if there are no additional matches (this would obviously require another pass to check for "comb0" as this, I assume, was produced by the optimizer). ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/02/2013 05:59 PM, Mr Dash Four wrote:> > >> Patch attached. Note that it removes A_ACCEPT and ACCEPT from the >> possible choices for INVALID_DISPOSITION (which is as documented). > A_REJECT is allowed (rightly so!) - all you need is to amend the > original announcement as A_REJECT wasn''t included there. Another > query: out of interest, why do you use "-g A_X" (X=DROP,REJECT) and > not a regular jump - what is there to be gained by that? > >>> 3. UNTRACKED_DISPOSITION (this is listed as NOTRACK_DISPOSITION >>> in the announcement above, though "shorewall update" converts it >>> and treats it as UNTRACKED_DISPOSITION): CONTINUE works, ACCEPT >>> and A_ACCEPT are ignored completely for whatever reason (I >>> expected -j ACCEPT/A_ACCEPT), A_DROP is accepted and works (this >>> wasn''t in the announcement) and A_REJECT is accepted (no syntax >>> error is given), but ultimately no iptables rule is produced. >> >> The attached patch should correct that problem as well. > > ACCEPT is still ignored, A_ACCEPT is, this time, correctly handled > and so are the rest of the built-in actions (you need to amend you > original announcement to include A_REJECT). > > >>> -A fw2net -m conntrack --ctstate INVALID -j ~comb0 -A fw2net -m >>> conntrack --ctstate UNTRACKED -j ~comb0 >>> >>> That should have been "-A fw2net -m conntrack --ctstate >>> INVALID,UNTRACKED -j ~comb0" >>> >> >> That''s an even harder case for the compiler to detect. > The way I see it, if the jump target is the same all you have to do > is check for different states and combine them if that is the case > and if there are no additional matches (this would obviously require > another pass to check for "comb0" as this, I assume, was produced by > the optimizer).Yep -- Optimize level 16 currently does something similar by combining adjacent rules that are identical except for port number(s). I would have to do something similar for conntrack state. -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 \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/03/2013 07:24 AM, Tom Eastep wrote:> On 02/02/2013 05:59 PM, Mr Dash Four wrote:>>>> 3. UNTRACKED_DISPOSITION (this is listed as NOTRACK_DISPOSITION >>>> in the announcement above, though "shorewall update" converts it >>>> and treats it as UNTRACKED_DISPOSITION): CONTINUE works, ACCEPT >>>> and A_ACCEPT are ignored completely for whatever reason (I >>>> expected -j ACCEPT/A_ACCEPT), A_DROP is accepted and works (this >>>> wasn''t in the announcement) and A_REJECT is accepted (no syntax >>>> error is given), but ultimately no iptables rule is produced. >>> >>> The attached patch should correct that problem as well. >> >> ACCEPT is still ignored, A_ACCEPT is, this time, correctly handled >> and so are the rest of the built-in actions (you need to amend you >> original announcement to include A_REJECT).Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
> Yep -- Optimize level 16 currently does something similar by combining > adjacent rules that are identical except for port number(s). I would > have to do something similar for conntrack state.Well done on this one - it works to perfection now! ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
>>> ACCEPT is still ignored, A_ACCEPT is, this time, correctly handled >>> and so are the rest of the built-in actions (you need to amend you >>> original announcement to include A_REJECT). > > Patch attached.That also works now. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb