One of the limitations in ipset is that it does not allow me to specify IP,Port pairs in the same construct (map, hashmap etc) where the IP address is not a B-class address (/16). To overcome this issue I have resorted to some creative Shorewall statements in my rules file like: ACCEPT $FW:+dest-port-map[dst] net:+dest-ip-map This produces the right result, in a round-about way (it produces a code containing 2 match-set constructs - both are ''dst''). Is there another - preferably more straight-forward - possibility? I was thinking of, may be, separating the second part (net:...) with comas and using something like: ACCEPT $FW net:+dest-ip-map,+dest-port-map but do not know whether it is possible to implement in Shorewall? The above alternative would also allow me to include ipset pairs containing protocols (udp, tcp, icmp even). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 09/19/2010 09:33 AM, Mr Dash Four wrote:> One of the limitations in ipset is that it does not allow me to specify > IP,Port pairs in the same construct (map, hashmap etc) where the IP > address is not a B-class address (/16). To overcome this issue I have > resorted to some creative Shorewall statements in my rules file like: > > ACCEPT $FW:+dest-port-map[dst] net:+dest-ip-map > > This produces the right result, in a round-about way (it produces a code > containing 2 match-set constructs - both are ''dst'').That''s the best way to do what you are trying to do.> > Is there another - preferably more straight-forward - possibility? I was > thinking of, may be, separating the second part (net:...) with comas and > using something like: > > ACCEPT $FW net:+dest-ip-map,+dest-port-mapThat syntax is already supported but produces two separate rules; been that way forever so changing it is not an option.> > but do not know whether it is possible to implement in Shorewall? The > above alternative would also allow me to include ipset pairs containing > protocols (udp, tcp, icmp even)I''ll think about an alternative syntax for 4.4.14... -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> That''s the best way to do what you are trying to do. >I have some more twisted ones (when I have source ip,port pairs and a destination ip-port set) and Shorewall just about manages to fit this, but it is just.> I''ll think about an alternative syntax for 4.4.14... >This is useful when I have to restrict traffic to various IP,Port hosts which use different protocols. Personal VPN is a good example - you have various hosts with different ip,port pair combinations and you also have them use either tcp or udp depending on that pair. Currently, on one of my machines I issue two identical statements (like the one I listed in my initial post), but one for tcp and one for udp protocols, which isn''t the most efficient way and I''d rather be able to specify IP,port,protocol as a triplet (dst,dst,dst) than make two statements covering all bases (I also have to make two sets - one for udp and one for tcp which is not very convenient). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/19/10 9:40 AM, Tom Eastep wrote:> On 09/19/2010 09:33 AM, Mr Dash Four wrote: >> One of the limitations in ipset is that it does not allow me to specify >> IP,Port pairs in the same construct (map, hashmap etc) where the IP >> address is not a B-class address (/16). To overcome this issue I have >> resorted to some creative Shorewall statements in my rules file like: >> >> ACCEPT $FW:+dest-port-map[dst] net:+dest-ip-map >> >> This produces the right result, in a round-about way (it produces a code >> containing 2 match-set constructs - both are ''dst''). > > That''s the best way to do what you are trying to do. > >> >> Is there another - preferably more straight-forward - possibility? I was >> thinking of, may be, separating the second part (net:...) with comas and >> using something like: >> >> ACCEPT $FW net:+dest-ip-map,+dest-port-map > > That syntax is already supported but produces two separate rules; been that > way forever so changing it is not an option. > >> >> but do not know whether it is possible to implement in Shorewall? The >> above alternative would also allow me to include ipset pairs containing >> protocols (udp, tcp, icmp even) > > I''ll think about an alternative syntax for 4.4.14...4.4.14 will support this syntax: ACCEPT $FW net:[+dest-ip-map,+dest-port-map],... Using [...] to delimit the ipset list allows embedded [src|dst,...] to be handled easily. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> 4.4.14 will support this syntax: > > ACCEPT $FW net:[+dest-ip-map,+dest-port-map],... > > Using [...] to delimit the ipset list allows embedded [src|dst,...] to > be handled easily. >I presume whether it would be src or dst will be determined by its positioning, for example: ACCEPT $FW[+src-ip-map,src-port-map] net:[+dst-ip-map,+dst-port-map] as there won''t be any restrictions as to the number of ipsets included. Also, would it not make more sense to use this syntax: net:+[dst-ip-map,dst-port-map] or is that not doable (saving a plus sign and it looks more ... logical)? Another thing I haven''t thought of, but you need to account if you are to implement this: currently ipsets with triplets, whatever they are, definitely include a protocol name, so potentially there may be a clash (for example when I have udp in my src triplet and then specify another triplet having tcp protocol as my dst). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/19/10 12:41 PM, Mr Dash Four wrote:> >> 4.4.14 will support this syntax: >> >> ACCEPT $FW net:[+dest-ip-map,+dest-port-map],... >> >> Using [...] to delimit the ipset list allows embedded [src|dst,...] to >> be handled easily. >> > I presume whether it would be src or dst will be determined by its > positioning, for example: > > ACCEPT $FW[+src-ip-map,src-port-map] net:[+dst-ip-map,+dst-port-map] > > as there won''t be any restrictions as to the number of ipsets included. > > Also, would it not make more sense to use this syntax: > net:+[dst-ip-map,dst-port-map] or is that not doable (saving a plus sign > and it looks more ... logical)?Good suggestion.> > Another thing I haven''t thought of, but you need to account if you are > to implement this: currently ipsets with triplets, whatever they are, > definitely include a protocol name, so potentially there may be a clash > (for example when I have udp in my src triplet and then specify another > triplet having tcp protocol as my dst).I don''t understand the problem -- sorry. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
>> Another thing I haven''t thought of, but you need to account if you are >> to implement this: currently ipsets with triplets, whatever they are, >> definitely include a protocol name, so potentially there may be a clash >> (for example when I have udp in my src triplet and then specify another >> triplet having tcp protocol as my dst). >> > > I don''t understand the problem -- sorry. >My fault, sorry! This functionality was, apparently, removed in the newer versions of ipset, so adding protocol in the set is no longer possible. The possible triplet combinations left in the current ipset are IP,port,IP and IP,port,IP/cidr-size, though with the above additions to 4.4.14 this can be expanded with more natural matches, like IP,port,IP,port for example, though the protocol, as it stands, has to be specified outside the set - there is no getting around this limitation as far as I can see. In the older versions of ipset I could use triplets in the form of IP,port,protocol, which suited me fine and I could have one set for list of hosts,ports and protocols (though Shorewall was the problem then as I could not fit all three of IP, port and protocol using one set AND use Shorewall at the same time without reverting to manual hacking). The conclusion - not every new version is better than the previous one (I mean ipset, not Shorewall). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/19/10 3:36 PM, Mr Dash Four wrote:> >>> Another thing I haven''t thought of, but you need to account if you are >>> to implement this: currently ipsets with triplets, whatever they are, >>> definitely include a protocol name, so potentially there may be a clash >>> (for example when I have udp in my src triplet and then specify another >>> triplet having tcp protocol as my dst). >>> >> >> I don''t understand the problem -- sorry. >> > My fault, sorry! This functionality was, apparently, removed in the > newer versions of ipset, so adding protocol in the set is no longer > possible. >That explains it -- 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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev