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