Hello, What does your shorewall interfaces looks like? One question I had is which interface is the <elsewhere> zone connected to?
Maybe <elsewhere> is better suited for an entry on shorewall host file? Cheers ----------------- Leandro Avila ----- Original Message ----- From:Vieri Di Paola <[email protected]> To:[email protected] Cc: Sent:Thursday, March 24, 2011 4:09 AM Subject:Re: [Shorewall-users] shorewall bridge Hi, According to http://www.shorewall.net/bridge-Shorewall-perl.html: <fw> -> <BP zone> rules are not allowed <non-BP zone> -> <BP zone> rules are not allowed "Policies from a non-BP zone to a BP are disallowed. Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are disallowed." /etc/shorewall/zones defines a <BP zone> as a "subzone" of a <non-BP zone>: #ZONE TYPE OPTIONS fw firewall elsewhere ipv4 world ipv4 net:world bport loc:world bport So I'm supposing that one CANNOT define rules and policies such as: <elsewhere> -> <loc> but can define rules such as: <elsewhere> -> <world> Suppose that my loc zone is physically connected to eth0 and net is connected to eth1 and that I want to allow specific IP addr/port traffic from <elsewhere> to <net> but block it from <elsewhere> to <loc>. If I set this in /etc/shorewall/policy: elsewhere world REJECT and this in /etc/shorewall/rules: ACCEPT elsewhere world:<SMTP_SERVER_IP_ADDR> tcp 25 then I should be blocking all SMTP traffic except to my SMTP server. However, I won't be able to explicitly allow tcp 25 traffic to the "loc" subzone of "world" and disallow tcp 25 traffic to the "net" subzone. Also, if the net subzone is considered "insecure" then a host in that subzone could assign itself the same IP address as my SMTP server thus receiving SMTP traffic illegitimately. Is this a physdev match limitation? Is there a solution to this other than making sure that my net subzone isn't "insecure"? On the other hand, if my /etc/shorewall/policy file contains: net elsewhere REJECT info net world REJECT info and a host from <elsewhere> tries to connect to <SMTP_SERVER_IP_ADDR> and the latter is within the net bport subzone (ie. connected to eth1 in my example) then it should fail, right? The connection should succeed if <SMTP_SERVER_IP_ADDR> were connected to eth0 (loc bport subzone). Thanks, Vieri ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
