Are there any scenarios that require traffic from a zone to itself to be blocked? If not, Shorewall should possibly allow it as a matter of course. It seems strange having to explicitly create such a policy & it''s not immediately obvious when it is required. -- Taso Hatzi caesar 17 <<-salad cjbx jc vdwwjar jc xi jc jd salad
On Saturday 06 November 2004 17:46, Taso Hatzi wrote:> Are there any scenarios that require traffic from a zone to itself to be > blocked? If not, Shorewall should possibly allow it as a matter of course. > It seems strange having to explicitly create such a policy & it''s not > immediately obvious when it is required.That''s the way it works already. But if you add a rule (or rules) that control(s) traffic from the zone to itself, then any traffic that doesn''t match the rule(s) is subject to policies. -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:> >>Are there any scenarios that require traffic from a zone to itself to be >>blocked? If not, Shorewall should possibly allow it as a matter of course. >>It seems strange having to explicitly create such a policy & it''s not >>immediately obvious when it is required. > > > That''s the way it works already. But if you add a rule (or rules) that > control(s) traffic from the zone to itself, then any traffic that doesn''t > match the rule(s) is subject to policies. >I guess what I''m suggesting is that Z -> Z traffic should be exempt from the "all all REJECT info" policy that most(?) people have in their policy file. Are you saying that it is exempt? If the zone file has n zones, Z1 - Zn, I am suggesting that the following policies are implict at the end of the policy file. Z1 Z1 ACCEPT ::: Zn Zn ACCEPT all all REJECT INFO Also, it wouldn''t do any harm to be dictatorial about some aspects of zones and their names. For example, Shorewall could predefine the set of zones fw, net, loc, and dmz, their purpose and their display name. It makes it easier to write how-to''s, and provide support, and removes a few more variables which are not really necessary for a user.
On Saturday 06 November 2004 20:01, Taso Hatzi wrote:> Tom Eastep wrote: > >>Are there any scenarios that require traffic from a zone to itself to be > >>blocked? If not, Shorewall should possibly allow it as a matter of > >> course. It seems strange having to explicitly create such a policy & > >> it''s not immediately obvious when it is required. > > > > That''s the way it works already. But if you add a rule (or rules) that > > control(s) traffic from the zone to itself, then any traffic that doesn''t > > match the rule(s) is subject to policies. > > I guess what I''m suggesting is that Z -> Z traffic should be exempt from > the "all all REJECT info" policy that most(?) people have in their policy > file. Are you saying that it is exempt?It is exempt IF YOU DON''T HAVE ANY Z->Z RULES.> > If the zone file has n zones, Z1 - Zn, I am suggesting that the following > policies are implict at the end of the policy file. > > Z1 Z1 ACCEPT > > Zn Zn ACCEPT > all all REJECT INFOThe Zn Zn ACCEPT policies are implicitly at the beginning of the policy file but again each policy is contigent on the absence of Zn->Zn rules.> > > Also, it wouldn''t do any harm to be dictatorial about some aspects > of zones and their names. For example, Shorewall could predefine > the set of zones fw, net, loc, and dmz, their purpose and their > display name.No! One of the things that distinguishes Shorewall from other Netfilter frontends is its flexibility. I am not going to start dictating anything.> It makes it easier to write how-to''s, and provide > support, and removes a few more variables which are not really > necessary for a user. >They are not necessary for you -- that doesn''t mean that they aren''t necessary for other users with totally different fireall needs. -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