On 2/22/19 7:10 PM, ObNox wrote:
> That's what I don't understand here. If "all!${FW},net" translates to
> "z1,z2,..,zN", then why my current settings work perfectly and produce
> no error at compile time...
>
> z1,z2,..,zN { dest=z1,z2,..,zN+ policy=REJECT loglevel=info }
> all { dest=all policy=DROP loglevel=info }
>
> While...
>
> all!${FW},net { dest=all+!${FW},net policy=REJECT loglevel=info }
> all { dest=all policy=DROP loglevel=info }
>
> does not and ends up with an error? As you said, the first line ought to
> be an exact equivalent right? I'm missing something here.It is not an exact equivalent, obviously. For one thing, when either the SOURCE or DESTINATION is 'all', any previous policy specified for a particular Zi,Zj pair is not overwritten and no error is produced. There is also an historical element. Prior to the introduction of the EXPAND_POLICIES option, all->z, z->all and all->all policies were enforced in chains all-z, z-all and all-all respectively. This is still the case when EXPAND_POLICIES=No. The code takes the same path when EXPAND_POLICIES=Yes, then "expands" the policy into the effected Zi-Zj chains, while leaving the original policy chain in the configuration (to be optimized out later). That is done exactly to catch multiple policies with the same SOURCE and DESTINATION columns. I didn't change that when I introduced zone exclusion and it isn't clear that I want to. > > >> When you include '+', the rule >> covers both inter-zone AND intra-zone traffic. > > So in the current state, I can't mimic my old settings with the > exclusions feature. > > I want to REJECT inter/intra-zone traffic because I'm dealing with known > hosts and I don't want them to wait for packet timeouts > > I want to DROP everything else, both "expected" traffic from a known > zone like "net->*" and "unexpected" traffic from unknown sources like a > rogue IP not belonging to any zone and thus falling into the default > policy of INPUT/FORWARD. > > Yikes! I guess I'll continue to use the old way of listing every single > zone I manage, which gets visually not appealing when there are several > of them :-) > This issue could be revisited, but certainly not in a patch release as the change would need wider testing than I myself can provide. I will go ahead and release the patch that I sent you, as that is an obvious bug. My own feeling is that an intra-zone policy other than ACCEPT is a rare requirement (and such cases can be handled with explicit policies). The most common case would be net->net, especially where there are multiple uplinks . Otherwise, if hosts in the same zone aren't supposed to communicate, then why are they in the same zone in the first place. I believe that inter-zone traffic can be handled in the way that you want, without any further change. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
