Victor OYETOLA wrote:
> I ve just install shorewall-common and shorewall-shell
> I can''t defined a network using the CIDR format for my DMZ in
> /etc/shorewall/hosts
>
> fast eth2:172.17.0.0/16
> epac eth2:172.18.0.0/16
> fsa eth2:172.19.0.0/16
> bu eth2:172.20.0.0/16
> recto eth2:172.21.0.0/16
> dmz eth1:81.91.225.224/27
> I receive this error:
> ERROR: Invalid zone definition for zone dmz
> when I comment this line (dmz ) and restart shorewall, my dmz is defined
> as shown in the following line.
> fast Zone: eth2:172.17.0.0/16
> epac Zone: eth2:172.18.0.0/16
> fsa Zone: eth2:172.19.0.0/16
> bu Zone: eth2:172.20.0.0/16
> recto Zone: eth2:172.21.0.0/16
> dmz Zone: eth1:0.0.0.0/0
> net Zone: eth0:0.0.0.0/0
The fact that the ''dmz'' zone shows up the way it does in the
above listing
indicates that you have an entry in your /etc/shorewall/interfaces file such
as this:
dmz eth1 ...
That means that all IPv4 addresses accessed through eth1 are already a part
of zone ''dmz'' so adding eth1:81.91.225.224/27 to the zone is
superfluous.
>
> Every second i receive this message in my syslog
>
> Jul 26 11:51:04 calavi kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth2
> SRC=172.21.0.1 DST=224.0.0.251 LEN=70 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF
> PROTO=UDP SPT=5353 DPT=5353 LEN=50
This is a different problem since it occurs on eth2 (did you look at
Shorewall FAQ 17?). From the above output, it is clear that no zone
associated with eth2 includes the multicast address range (224.0.0.0/4). So
multicasts going to eth2 fall through and are being rejected in the OUTPUT
chain. What is unclear here is why they are being logged -- the standard
''Reject'' default action includes ''dropBcast''
which will silently drop
traffic to that range. So either:
a) You have specified REJECT:None as the applicable policy for fw->all.
b) You have specified REJECT:<someaction> as the policy where
<someaction>
doesn''t silently drop multicasts.
c) You have set REJECT_DEFAULT in shorewall.conf to something other than
''Reject''.
d) You have redefined the ''Reject'' action.
e) Something else is wrong; it will require the output of "shorewall
dump"
to analyze.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/