Hi Tom Hi all > Those zones aren't nested -- they are disjoint! Right. Sorry for the disorientation.
> Maximum length of a zone name is 5 characters! I'm sorry. I forgot about the 5 char limit when I wrote this mail. The real zone names are 5 or less, I used longer names to make it clear what I mean. But thank you for notifying! > servers eth1:10.0.0.0/24 dhcp > clients eth1:10.0.1.0/24,10.0.2.0/23 dhcp Yes, of course! Thank you! > A real "belt and suspenders" setup :-) Sorry, I don't understand this saying. What does it mean? (must be funny ;)) > No -- Not if: > > a) The addresses correspond to different zones; or > b) The addresses are in the same zone but you have either > intra-zone rules > or an intra-zone policy for that zone. aehm, hmm....,ok A question to make it clear for me: _If_ I use multiple IP adresses for one interface AND don't list each corresponding IP/network in the hosts file AND want to route between them, THEN I need the multi option. In the following setup, hosts on 10.0.0.0/24, 10.0.1.0/24 and on 192.168.0.0/24 can access each other without specifying the multi option?: /etc/shorewall/zones: srv Servers Server Zone cli Clients Client Zone exa Example Example Zone for the "detect" question /etc/shorewall/interfaces: - eth1 detect #no options /etc/shorewall/hosts: srv eth1:10.0.0.0/24 dhcp cli eth1:10.0.1.0/23 dhcp exa eth1:192.168.0.0/24 #no options eth1 has the following IPs (done in the Bering interface config) 10.0.0.1/22 192.168.0.1/24 > Yes -- "detect" only detects the first broadcast address. So, in the example above, the "detect" in the interfaces file would be wrong! I'd need: /etc/shorewall/interfaces: - eth1 10.0.3.255,192.168.0.255 #no options Right? > One more comment -- if you plan to define rules between the client and > server zones, what you are implementing is little more than "security > through obscurity" and in this case, it's not even very obscure. Any user > with administrative privileges on their client machine can change the > netmask and access any server they choose. Yes, you're right, that would be "security through obscurity"! But I don't want to control traffic from the servers to the clients (or vice-versa). I want to control traffic coming from the branch offices to the servers and clients. Especially, I don't want that hosts on remote networks can access the clients on the LAN. -- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch | http://leaf.sourceforge.net/devel/sminola ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
