>>> 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 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
