> There's more to it. 'blacklist' is not a zone attribute. It is a > host-group attribute( See shorewall-hosts(5) ). I regret that it was > initially implemented that way but it was and I need to maintain > compatibility. > OK, I applied the patch, checked and had eth0_out with 'blackout' as the first ref. entry and in it I had the blacklisted ipsets as expected. Did a dry run and tried to connect to a blacklisted address and it worked. Now for the confusing bits:
eth0 in 'interfaces' has 'blacklist' option set (NO numbers). So, according to shorewall-interfaces I wouldn't be allowed to use blacklisted features on packets originating from that interface, but as you can read above - it works. The whole thing is VERY confusing - I should have at least some sort of 'fool-proof' system in place, which should prevent me from using daft combinations like selecting blacklist=1 and then using the "to" option in the blacklist file and vice versa. Also, the man shorewall-interface does not specify what happens if I select blacklist=2 with regards to incoming packets - by reading it I am assuming that blacklist=2 stops ONLY outgoing packets, but not incoming. If that is not the case it should make it clear. Or am I supposed to use "blacklist=1,blacklist=2" if I want packets to be stopped in both directions? As I pointed out - it is very confusing and these things should be made clear. ------------------------------------------------------------------------------ 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 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
