Tom Eastep wrote: > On 04/10/2013 07:12 PM, Mr Dash Four wrote: > >>> Yep, that did the trick. I am going to do a (very) light testing and >>> will continue tomorrow as I ran out of time... >>> > > My comments assume that the last simply patch that I posted last night > has been installed. > Which one? You've posted two patches: INLINE.patch (which I applied, re-tested and reported back with the above comment) and SET1.patch (which I haven't done anything with yet as I am not at home).
As far as SET1.patch goes, I see another "use Shorewall::Config" is be added to action.INLINE, which was what your earlier INLINE.patch did - should I then reverse INLINE.patch and then apply SET1.patch, or should I just delete the first hunk in SET1.patch and then apply it? >> 1. >> >> rules >> ~~~~~ >> INLINE $FW net ; -m mickey-mouse --name test >> >> produces: >> >> [...] >> :INLINE - [0:0] >> [...] >> -A INLINE -m mickey -mouse --name test >> > > > -A fw2net -m mickey -mouse --name test > > >> 2. >> >> rules >> ~~~~~ >> INLINE $FW:10.1.1.1 net:+mickey-mouse ; -m mickey-mouse --name test >> >> produces: >> >> [...] >> :INLINE - [0:0] >> [...] >> -A fw2net -j INLINE >> > > I presume that rule was produced by your entry in 1 above. > No, you've messed up the email quotation somehow... In case 1 above, I have "INLINE $FW net ; -m mickey-mouse --name test", which should produce "-A fw2net -m mickey-mouse --name test" (note the absence of space between "mickey" and "-mouse"), but it produces jump to a new chain (called INLINE) with a single rule in it: "-m mickey -mouse --name test" (note the extra space). So, what I expected to happen was: 1) not to see this extra "INLINE" chain created; 2) not to see an extra space added between "mickey" and "-mouse", which transforms the whole match into something completely different (or, if "-" is not allowed in match names, then I expected to see an error raised by shorewall). So, that's about case 1 above. With case 2, my understanding was that <src> and <dst> from your announcement were for specifying zones only and that nothing else is allowed there, hence why I reported this. Also, and that is a common "theme" throughout all reported cases, when I specify INLINE in my "rules", I expected a single statement to be added to the current chain (fw2net in all the cases I tested so far) with whatever I specified as parameters/arguments. That does not happen. I don't see the reason why an extra chain (defined %INLINE or whatever you wish to call it) needs to be created with an extra jump to whatever I specified as a rule to be added - it is much simpler to just construct the rule and add it to the current chain (fw2net in this case) instead and be done with it. In other words, I expected to see: "-A fw2net -m mickey-mouse --name test" in case 1 (instead of the new INLINE chain, a single rule, which was wrong anyway, added to it, as well as the additional jump to the INLINE chain). In case 2, I expected to see an error, given my assumptions above. >> -A fw2net -s 10.1.1.1 -m set --match-set mickey-mouse dst -j INLINE >> >> Ignoring the above lines, shouldn't I get an error instead? >> > > What error would you expect? > See above. > With the patch, this rule now produces: > > :$INLINE [0:0] > ... > -A %INLINE -m mickey-mouse --name test > ... > -A fw2net -s 10.1.1.1 -m set --match-set mickey-mouse dst -j %INLINE > > The current optimizer isn't combining those rules which I will try to > correct in the coming days. > Precisely! The "INLINE" chain should have never been created in the first place. The base premise on which INLINE as a feature was added was that whatever is after ";" needs to be appended to the "-A <chain>" (I didn't even want anything else after <src> and <dst>, but if shorewall could combine both that was fine with me too). Simply put - I did not expect to see all this "-j %INLINE" malarkey. >> 3. >> >> rules >> ~~~~~ >> INLINE $FW net tcp ; --dport 1234 -m mickey-mouse --name test >> >> produces:But if I can get the optimizer to work in this case, it should >> generate a workable rule. >> >> [...] >> :INLINE - [0:0] >> [...] >> -A INLINE --dport 1234 -m mickey -mouse --name test >> >> > > With the patch, you get: > > :%INLINE1 - [0:0] > ... > -A %INLINE1 --dport 1234 -m mickey -mouse --name test > ... > -A fw2net -p 6 -j %INLINE1 > > Which clearly doesn't work. On the other hand, the -p match and it's > option (--dport) are split between the columnar and raw parts of the > rule, which isn't something I would want to spend any time worrying about. > Well, exactly and it is why I was for anything else specified after <src> and <dst> and before ";" to raise an error - simply because shorewall won't be able to always get it right (the above being a case in point). The rule should have been "INLINE $FW net ; -p tcp --dport 1234 -m mickey-mouse --name test" which should produce "-A fw2net -p tcp --dport 1234 -m mickey-mouse --name test". Anything in between is asking for trouble. >> 4. >> >> rules >> ~~~~~ >> INLINE $FW net tcp - ; -p 17 --dport 2345 -j SECCTX --name test >> >> produces: >> >> [...] >> :INLINE - [0:0] >> [...] >> -A INLINE -p 17 --dport 2345 -j SECCTX --name test >> > > It now produces: > > %INLINE2 - [0:0] > ... > -A %INLINE2 -p 17 --dport 2345 -j SECCTX --name test > ... > -A fw2net -p 6 -j %INLINE1 > > Here, the fact that INLINE is implemented as an action is apparent. The > optimizer knows that it can't combine rules with different protocols, so > it leaves the rule unoptimized. > Shouldn't that produce an error because I am trying to fit two protocol matches in a single rule (tcp and udp)? The above still won't work though. > I realize that isn't what I indicated in an earlier email, but that's > the way it works. > Again, I don't see the need for this extra %INLINE chain, but you already know that. >> 5. >> >> rules >> ~~~~~ >> INLINE $FW net - - ; -j SECCTX --name test >> >> produces: >> >> -A fw2net -j SECCTX --name test >> >> which is correct, but shouldn't that produce an error as there are 2 >> trailing dashes (-) before ";"? >> > > No -- you can have as many trailing dashes as there are remaining > columns in a rules file entry. > Didn't know that, thanks. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
