I haven''t debugged this enough to understand what is happening, but I observe the following: someipset = bitmap:ip,mac 1) br0:+someipset 2) br0:+someipset[2] The first 1) doesn''t match anything in rules or tcrules, the second 2) matches fine. (Also using +someipset[1] doesn''t match anything) Is it possible/sensible/feasible to have shorewall figure out the ''arity of the ipset? Is it an artifact of the ipset type used here? Not tested this yet, but is it a more descriptive setup to do something like defining someipset:loc in zones and "somealias br0:+someipset[2]" in hosts? That way I *think* I can use "somealias" everywhere and avoid needing to remember the "arity" in various rules? Other suggestions appreciated? Note, probably a stupid question (like previous...), still trying to get my head around the generated iptables rules and what is valid ipset syntax (Recent iptables/ipset/shorewall) Thanks Ed W ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
On Tue, 2011-07-26 at 00:00 +0100, Ed W wrote:> I haven''t debugged this enough to understand what is happening, but I > observe the following: > > someipset = bitmap:ip,mac > > 1) br0:+someipset > 2) br0:+someipset[2] > > The first 1) doesn''t match anything in rules or tcrules, the second 2) > matches fine. (Also using +someipset[1] doesn''t match anything)That is because it is equivalent to 1).> > Is it possible/sensible/feasible to have shorewall figure out the ''arity > of the ipset?With ipsets still under such rapid development, I''m reluctant to add any code that attempts to understand set types.> Is it an artifact of the ipset type used here?Yes.> > Not tested this yet, but is it a more descriptive setup to do something > like defining someipset:loc in zones and "somealias br0:+someipset[2]" > in hosts? That way I *think* I can use "somealias" everywhere and avoid > needing to remember the "arity" in various rules?I don''t believe that a bitmap:ip,mac ipset works in the hosts file. Such an ipset can only be used to match the SOURCE address while an ipset listed in the hosts file must be able to match both SOURCE and DEST addresses. -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 \________________________________________________ ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
Hi Thanks for the explanation on ipset status>> Is it possible/sensible/feasible to have shorewall figure out the ''arity >> of the ipset? > > With ipsets still under such rapid development, I''m reluctant to add any > code that attempts to understand set types.:-) What, an update every 2 weeks or so! Come on, shorewall is matching that right now! (and thanks for such rapid development!)>> Not tested this yet, but is it a more descriptive setup to do something >> like defining someipset:loc in zones and "somealias br0:+someipset[2]" >> in hosts? That way I *think* I can use "somealias" everywhere and avoid >> needing to remember the "arity" in various rules? > > I don''t believe that a bitmap:ip,mac ipset works in the hosts file. Such > an ipset can only be used to match the SOURCE address while an ipset > listed in the hosts file must be able to match both SOURCE and DEST > addresses.Hmm, I see your point. Mac is not necessarily known for the dest, so it''s not possible to match. An incomplete implementation would be possible to match source on [IP,Mac] and dest on [IP], but that''s not supported by ipset... OK, will use explicit ipsets everywhere, plus perhaps some use of params to tidy things up Thanks! Ed W ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
I think this is yet another dumb question, but...
I (mis)read the ipset documentation to be implying that +[ipset1,ipset2]
is an OR relationship and will match if the user is in either of the two
ipsets?
Shorewall in fact generates the first rule below, which as near as I can
see is an AND relationship:
Chain tcpre (1 references)
pkts bytes target prot opt in out source
destination
...
0 0 MARK all -- * * 0.0.0.0/0
0.0.0.0/0 mark match ! 0x0/0xffff match-set cp1 src,src
match-set cp2 src,src MARK or 0x800
2 149 MARK all -- * * 0.0.0.0/0
0.0.0.0/0 mark match ! 0x0/0xffff match-set cp1 src,src MARK
or 0x100
Empirically we can see from above that cp1 matches, but cp1 AND cp2
(empty) don''t match any packets
It''s entirely possible that this is intended - if so, do you think the
docs could clarify this here:
http://shorewall.net/manpages/shorewall-ipsets.html
http://shorewall.net/manpages/shorewall-exclusion.html
On reflection the exclusion page highlights that it''s an AND
relationship, but only if you understand contraposition logic..
OK, perhaps just the ipset page could be made explicit (please?)
Thanks!
Ed W
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
On Tue, 2011-07-26 at 20:28 +0100, Ed W wrote:> I think this is yet another dumb question, but... > > I (mis)read the ipset documentation to be implying that +[ipset1,ipset2] > is an OR relationship and will match if the user is in either of the two > ipsets?No -- it is an AND relationship.> > OK, perhaps just the ipset page could be made explicit (please?) >Done. -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 \________________________________________________ ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/