-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found out problems with dynamic add of hosts to zones. If somebody has idea how to fix it, please do tell. My head is not working on this on properly. Hope you get idea from this message. I''m trying to simplify this as much as possible to get problem clear. Problem is: Zones: vpn wlan net Interfaces: net eth0 wlan eth1 Policies: vpn all REJECT net all DROP wlan all REJECT all wlan REJECT all all REJECT shorewall add eth0:10.10.0.0/24 vpn produces: - -A eth1_dynf -d 10.10.0.0/255.255.255.0 -o eth0 -j wlan2all and then I add another host to vpn zone shorewall add eth1:192.0.2.1 vpn Which will generate this ruleset after previous one. - -A eth1_dynf -s 192.0.2.1 -d 10.10.0.0/255.255.255.0 -o eth0 -j vpn2vpn - -A eth1_dynf -s 192.0.2.1 -o eth1 -j vpn2dmz - -A eth1_dynf -s 192.0.2.1 -o eth0 -j vpn2net - -A eth1_dynf -s 192.0.2.1 -o eth1 -j vpn2wlan - -A eth1_dynf -d 192.0.2.1 -o eth1 -j wlan2all Ok. Problem lies here: when a packet comes from 192.0.2.1 and want to go to 10.10.0.1 both in vpn zone, wlan2all zone REJECT policy hits in _before_ vpn2vpn policy. - -A eth1_dynf -d 10.10.0.0/255.255.255.0 -o eth0 -j wlan2all - -A eth1_dynf -s 192.0.2.1 -d 10.10.0.0/255.255.255.0 -o eth0 -j vpn2vpn - -A eth1_dynf -s 192.0.2.1 -o eth1 -j vpn2dmz - -A eth1_dynf -s 192.0.2.1 -o eth0 -j vpn2net - -A eth1_dynf -s 192.0.2.1 -o eth1 -j vpn2wlan - -A eth1_dynf -d 192.0.2.1 -o eth1 -j wlan2all How to fix dynamic zones so that dynamic zones are always at top of the list and policies without destination are at bottom of the list. Currently dynamic zones just don''t work here. Yep. I know this code is quite complex, Should code check for existence of -d and -s parameters and use -I instead of -A when adding those rules to dynf chain or what''s least wrong fix for that. I''ve just stared at that code too many hours today and could use a good advice. :-) - -- Tuomo Soini <tis@foobar.fi> Linux and network services +358 40 5240030 Foobar Oy <http://foobar.fi/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFClz7xTlrZKzwul1ERAix+AKChWxsudvZlK0ph+DnZwboRxC2rHgCfaQ3/ rWOGRYTnpxu8d3oSPaTceA4=MH7T -----END PGP SIGNATURE-----
Tuomo Soini wrote:> > I''ve just stared at that code too many hours today and could use a good > advice. :-) >The general problem of trying to place the more specific rules before the less specific rules in the dynamic chains is very hard to solve, given arbitrary changes in zone membership. You might try the attached (untested) patch to see if it addresses your particular problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -------------- next part -------------- A non-text attachment was scrubbed... Name: dynamiczone.diff Type: text/x-patch Size: 2635 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050527/f7ea3163/dynamiczone.bin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> The general problem of trying to place the more specific rules before > the less specific rules in the dynamic chains is very hard to solve, > given arbitrary changes in zone membership. You might try the attached > (untested) patch to see if it addresses your particular problem. > > -Tom >Yes. It does address that particular problem. As long as I''m using only one zone for all vpn traffic. Yep, it''s really hard as long as shorewall doesn''t now which zones are dynamic and which are not. And it''s really nearly impossible to do that completely right. - -- Tuomo Soini <tis@foobar.fi> Linux and network services +358 40 5240030 Foobar Oy <http://foobar.fi/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCl1HNTlrZKzwul1ERAhahAJ9CeRpSz9+UqmIG1IjNDxXfB6LTmACfRZwQ 8p27dvJ/evx7gpcaIxWKuQE=ZkDc -----END PGP SIGNATURE-----
Tom Eastep wrote:> ... > The general problem of trying to place the more specific rules before > the less specific rules in the dynamic chains is very hard to solve, > given arbitrary changes in zone membership. You might try the attached > (untested) patch to see if it addresses your particular problem.I''ve not looked at the surrounding code - only the patch - but it seems to me that this would result in zone2zone rules appearing in the reverse of the order they appear in the rules file. -- Paul <http://paulgear.webhop.net> -- Did you know? OpenOffice.org has built-in PDF creation. Better yet, it''s compatible with Microsoft Office, and free! Find out more at <http://www.openoffice.org>. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050528/26fd036e/signature.bin
Paul Gear wrote:> Tom Eastep wrote: >>... >>The general problem of trying to place the more specific rules before >>the less specific rules in the dynamic chains is very hard to solve, >>given arbitrary changes in zone membership. You might try the attached >>(untested) patch to see if it addresses your particular problem. > > I''ve not looked at the surrounding code - only the patch - but it seems > to me that this would result in zone2zone rules appearing in the reverse > of the order they appear in the rules file. >As I mention above, no matter what algorithm one comes up with here I believe that you can come up with a senario where the algorithm "does the wrong thing". I think that the senarios that break with this patch are crazier than the ones that break without it -- that''s the only thing I can say about this. Look at what Tuomo''s test case did. a) The zone precedence order is "vpn wlan net". b) A subzone of "net" is added to vpn. c) A subzone of "wlan" is added to vpn. d) Traffic between these two subzones isn''t handled correctly. It would be handled properly if these zones were staticly defined because "vpn2vpn" would have the highest precedence of all rules. The algoritm in add_to_zone() only ensures that it has the highest precedence *of the rules added in that call to the function". So while my little patch restores zone2zone traffic to it''s proper place, it doesn''t go nearly far enough to fix the entire problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > It would be handled properly if these zones were staticly defined because > "vpn2vpn" would have the highest precedence of all rules. The algoritm in > add_to_zone() only ensures that it has the highest precedence *of the rules > added in that call to the function". So while my little patch restores > zone2zone traffic to it''s proper place, it doesn''t go nearly far enough to > fix the entire problem. >I should add that I wouldn''t advise the Shorewall development community to spend a lot of time trying to fix this. With the advent of ''ipset'' support, there is a much cleaner way to implement dynamic zones: Zones: vpn wlan net Interfaces: net eth0 wlan eth1 Policies: vpn all REJECT net all DROP wlan all REJECT all wlan REJECT all all REJECT Hosts: vpn eth0:+vpn0 vpn eth1:+vpn1 Now when you want to add a host to the ''vpn'' zone, you just add it to the appropriate ipset (vpn0 or vpn1). This hasn''t been tested but it should work (the intent of the current code is that it should work) -- that would be a good project for someone to take on; test this and write an article about how to implement dynamic zones in this way (and fix any bugs found along the way). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key