--On Thursday, January 23, 2003 8:36 PM +0100 Sandro Minola <[EMAIL PROTECTED]> wrote:
It refers to a cautious man who wears a belt around his waist as well as suspenders (straps over his shoulders) to hold up his pants.A real "belt and suspenders" setup :-)Sorry, I don't understand this saying. What does it mean? (must be funny ;))
Yes -- unless you have a policy for that zone to itself. So this works: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.
/etc/shorewall/zones
foo bar baz
/etc/shorewall/interfaces
foo eth1 ...
/etc/shorewall/policy
foo foo ACCEPT
In this case, even if eth1 has multiple addresses, there is no need for 'multi'.
In this case, there is no need for 'multi' since each subnet is a separate zone.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?
Correct.
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.
Good! -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: teastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ------------------------------------------------------- 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
