figti@netcourrier.com
2003-Jul-09 06:00 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
I''ve the xMule p2p program running on my firewall, which is also a
gateway for my private network.
I''ve set Shorewall according to the "Two-interface QuickStart
Guide" (policy, rules, masq, interfaces, shorewall.conf files attached)
I noticed that Shorewall causes xMule to weird behaviors : after 15-20 minutes,
xMule drains 100% CPU and thus "hangs".
I found out that shutting down Shorewall get things back to normal ( xMule gets
back to 5-10% CPU...)
Restarting Shorewall causes xMule to get back to 100% CPU within 10-15 minutes
:(
To my point of view, it is quite the same as a "funnel phenomenon"...
Besides, I noticed that allowing
"fw net ACCEPT" in /etc/shorewall/policy
causes xMule to run smoothly (but this does not actually protect my gateway)
I''ve asked on the xMule board, but nobody seems to be able to help.
I''m now totally stuck. Actually xMule can indeed run, but my gateway
and my whole network is spread open to the whole Internet :(
Thanx very much
PS : I tried with Shorewall 1.2 as well as 1.4.4b, both give the same result.
I''m on Debian testing/unstable
Additionnal informations :
Figuera:/etc/shorewall# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:01:01:d4:7c:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
70: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
3
link/ppp
inet 212.195.95.243 peer 212.195.88.1/32 scope global ppp0
Figuera:/etc/shorewall#
Figuera:/etc/shorewall# ip route show
212.195.88.1 dev ppp0 proto kernel scope link src 212.195.95.243
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
default via 212.195.88.1 dev ppp0
Figuera:/etc/shorewall#
I did not include "shorewall status" output cause it''s a
300Ko file. Anyway I may compress it and send it back.
-------------------------------------------------------------
NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min)
Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
-------------- next part --------------
#
# Shorewall version 1.4 - Sample Rules File For Two Interfaces
#
# /etc/shorewall/rules
#
# Rules in this file govern connection establishment. Requests and
# responses are automatically allowed using connection tracking.
#
# In most places where an IP address or subnet is allowed, you
# can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to
# indicate that the rule matches all addresses except the address/subnet
# given. Notice that no white space is permitted between "!" and the
# address/subnet.
#
# Columns are:
#
#
# ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT,
# CONTINUE or LOG.
#
# ACCEPT
# Allow the connection request
# DROP
# Ignore the request
# REJECT
# Disallow the request and return an
# icmp-unreachable or an RST packet.
# DNAT
# Forward the request to another
# system (and optionally another
# port).
# DNAT-
# Advanced users only.
# Like DNAT but only generates the
# DNAT iptables rule and not
# the companion ACCEPT rule.
# REDIRECT
# Redirect the request to a local
# port on the firewall.
# REDIRECT-
# Advanced users only.
# Like REDIRECT but only generates the
# REDIRECT iptables rule and not the
# companion ACCEPT rule.
# CONTINUE
# (For experts only). Do Not Process
# any of the following rules for this
# (source zone,destination zone). If
# the source and/or destination IP
# address falls into a zone defined
# later in /etc/shorewall/zones, this
# connection request will be passed
# to the rules defined for that
# (those) zones(s).
# LOG
# Simply log the packet and continue.
#
# May optionally be followed by ":" and a syslog log
# level (e.g, REJECT:info). This causes the packet to be
# logged at the specified level.
#
# You may also specify ULOG (must be in upper case) as a
# log level. This will log to the ULOG target for routing
# to a separate log through use of ulogd.
# (http://www.gnumonks.org/projects/ulogd).
#
# SOURCE Source hosts to which the rule applies. May be a zone
# defined in /etc/shorewall/zones, $FW to indicate the
# firewall itself, or "all" If the ACTION is DNAT or
# REDIRECT, sub-zones of the specified zone may be
# excluded from the rule by following the zone name with
# "!'' and a comma-separated list of sub-zone names.
#
# Except when "all" is specified, clients may be further
# restricted to a list of subnets and/or hosts by
# appending ":" and a comma-separated list of subnets
# and/or hosts. Hosts may be specified by IP or MAC
# address; mac addresses must begin with "~" and must use
# "-" as a separator.
#
# Some Examples:
#
# net:155.186.235.1
# Host 155.186.235.1 on the Internet
#
# loc:192.168.1.0/24
# Subnet 192.168.1.0/24 on the
# Local Network
#
# net:155.186.235.1,155.186.235.2
# Hosts 155.186.235.1 and
# 155.186.235.2 on the Internet.
#
# loc:~00-A0-C9-15-39-78
# Host on the Local Network with
# MAC address 00:A0:C9:15:39:78.
#
# Alternatively, clients may be specified by interface
# by appending ":" to the zone name followed by the
# interface name. For example, net:eth0 specifies a
# client that communicates with the firewall system
# through eth0. This may be optionally followed by
# another colon (":") and an IP/MAC/subnet address
# as described above (e.g., net:eth0:192.168.1.5).
#
# DEST Location of Server. May be a zone defined in
# /etc/shorewall/zones, $FW to indicate the firewall
# itself or "all"
#
# Except when "all" is specified, the server may be
# further restricted to a particular subnet, host or
# interface by appending ":" and the subnet, host or
# interface. See above.
#
# Restrictions:
#
# 1. MAC addresses are not allowed.
# 2. In DNAT rules, only IP addresses are
# allowed; no FQDNs or subnet addresses
# are permitted.
# 3 You may not specify both an interface and
# an address.
#
# The port that the server is listening on may be
# included and separated from the server''s IP address by
# ":". If omitted, the firewall will not modifiy the
# destination port. A destination port may only be
# included if the ACTION is DNAT or REDIRECT.
#
# Example: net:155.186.235.1:25 specifies a Internet
# server at IP address 155.186.235.1 and listening on port
# 25. The port number MUST be specified as an integer
# and not as a name from /etc/services.
#
# If the ACTION is REDIRECT, this column needs only to
# contain the port number on the firewall that the
# request should be redirected to.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp",
a number,
# "all".
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port
# ranges; if the protocol is "icmp", this column is
# interpreted as the destination icmp-type(s).
#
# A port range is expressed as <low port>:<high port>.
#
# This column is ignored if PROTOCOL = all but must be
# entered if any of the following ields are supplied.
# In that case, it is suggested that this field contain
# "-"
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the CLIENT PORT(S) list below:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# CLIENT PORT(S) (Optional) Port(s) used by the client. If omitted,
# any source port is acceptable. Specified as a comma-
# separated list of port names, port numbers or port
# ranges.
#
# If you don''t want to restrict client ports but need to
# specify an ADDRESS in the next column, then place "-"
# in this column.
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the DEST PORT(S) list above:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT[-] or
# REDIRECT[-]) If included and different from the IP
# address given in the SERVER column, this is an address
# on some interface on the firewall and connections to
# that address will be forwarded to the IP and port
# specified in the DEST column.
#
# The address may optionally be followed by
# a colon (":") and a second IP address. This causes
# Shorewall to use the second IP address as the source
# address in forwarded packets. See the Shorewall
# documentation for restrictions concerning this feature.
# If no source IP address is given, the original source
# address is not altered.
#
# Also by default all outbound loc -> net communications are allowed.
# You can change this behavior in the sample policy file.
#
# Example: Accept www requests to the firewall.
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# ACCEPT net fw tcp http
#
# Example: Accept SMTP requests from the Local Network to the Internet
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# ACCEPT loc net tcp smtp
#
# Example: Forward all ssh and http connection requests from the Internet
# to local system 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp ssh,http
#
# Example: Redirect all locally-originating www connection requests to
# port 3128 on the firewall (Squid running on the firewall
# system) except when the destination address is 192.168.2.2
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# REDIRECT loc 3128 tcp www - !192.168.2.2
#
# Example: All http requests from the Internet to address
# 130.252.100.69 are to be forwarded to 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69
##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT net fw icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw net icmp 8
#
# Accept DNS connections from the firewall to the Internet
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
########### SSH: ##################################################
#
# Accept SSH connections from the local network and from the Internet
#
ACCEPT loc fw tcp 22
ACCEPT net fw tcp 22
# Accepter les connexions SSH du firewall vers le r?seau local
#(inutile pour l''instant)
#ACCEPT fw loc tcp 22
#
# Accepter les connexions Web du fw vers le net: ports 80 (http) et 443 (https)
en tcp
# (pour pouvoir faire du Web ? partir du poste fw)
ACCEPT fw net tcp 80
ACCEPT fw net tcp 443
#
########### PRIVOXY #######################
#
# Accepter la connexion du proxy (privoxy) vers le net (privoxy : port 8118;
install? sur le poste fw)
ACCEPT fw net tcp 8118
ACCEPT fw net udp 8118
#
# Accepter la connexion du r?seau local sur le proxy (privoxy)
ACCEPT loc fw tcp 8118
ACCEPT loc fw udp 8118
#
#
########## APACHE ########################
# Accepter les connexions du reseau local vers le firewall : ports 80 (http) et
443 (https) en tcp
# (car serveur apache install? sur le fw)
ACCEPT loc fw tcp 80
ACCEPT loc fw tcp 443
# Accepter les connexions net vers le firewall : ports 80 (http) et 443 (https)
en tcp
# (car serveur apache install? sur le fw)
ACCEPT net fw tcp 80
ACCEPT net fw tcp 443
#
#
########### FTP ##################################################
# Accepter les connexions FTP clientes du firewall vers internet (tcp : port
21):
ACCEPT fw net tcp 21
# Accepter les connexions FTP du reseau local vers le firewall (tcp : port 21):
ACCEPT loc fw tcp 21
# Accepter les connexions FTP du net vers le firewall (tcp : port 21)
ACCEPT net fw tcp 21
########### NTP ##################################################
# Accepter les connexions du fw ? un serveur ntpd (pour synchro Heure interne)
ACCEPT fw net udp 123
########## xMule ###############################
# xMule : cf http://www.xmule.org/forums/index.php?showtopic=128&hl=firewall
ACCEPT net fw tcp 4662
ACCEPT fw net tcp 4662
#ci-dessous, 8 lignes pour "aider" le script de restart de xmule
ACCEPT net fw tcp 4762
ACCEPT fw net tcp 4762
ACCEPT net fw udp 4762
ACCEPT fw net udp 4762
ACCEPT net fw tcp 4672
ACCEPT fw net tcp 4672
ACCEPT net fw udp 4662
ACCEPT fw net udp 4662
#Esp?rons que ?a marche....
ACCEPT net fw udp 4672
ACCEPT fw net udp 4672
ACCEPT fw net tcp 4661
ACCEPT net fw tcp 4665
ACCEPT net fw udp 4665
#ACCEPT fw net udp 4665
ACCEPT net fw tcp 4711
#Methode bourrin pour voir si xMule va enfin supporter Shorewall:
ACCEPT net fw tcp 4000:5000
ACCEPT net fw udp 4000:5000
ACCEPT fw net tcp 4000:5000
ACCEPT fw net udp 4000:5000
########### VNC ###################################################
#Accepter les connexions du reseau local au fw (4 serveurs VNC possibles, des
ports "1" ? "4"):
ACCEPT loc fw tcp 5900:5904
#Accepter les connexions du net au fw (4 serveurs VNC possibles, des ports
"1" ? "4"):
ACCEPT net fw tcp 5900:5904
########### SERVEUR X: #############################################
# Pour lancer des applications sous X ? distance.
# Accepter les connexions X du r?seau local vers le firewall (tcp et udp : ports
6000:6015)
# Pour l''instant (20030626), on acc?de au bureaux(x) par VNC, donc ces
lignes sont comment?es:
# ACCEPT loc fw tcp 6000:6015
# ACCEPT loc fw udp 6000:6015
# Accepter les connexions X du fw vers le r?seau local :
# ACCEPT fw loc tcp 6000:6015
# ACCEPT fw loc udp 6000:6015
########### ICQ: ##################################################
# Accepter les connexions du fw au serveur icq (udp : port 5190) :
# ACCEPT fw net tcp 5190
# Accepter les connexions via les ports tcp : 4200:4202 (d?faut: 4000:4100) :
# ACCEPT net fw related 4200:4202
########### COURRIER et NEWS #######################################
# Accepter les connexions du fw aux serveurs pop3 (tcp : port 110):
# ACCEPT fw net tcp 110
# Accepter les connexions du fw aux serveurs smtp (tcp : port 25):
# ACCEPT fw net tcp 25
# Accepter les connexions aux serveurs nntp (news, tcp : port 119):
# ACCEPT fw net tcp 119
########### IRC ##################################################
# Accepter les connexions du firewall sur IRC (tcp et udp : port 194):
# ACCEPT fw net tcp 6667
# ACCEPT fw net udp 6667
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-------------- next part --------------
##############################################################################
# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# L O G G I N G
##############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
#
# Valid levels are:
#
# 7 debug
# 6 info
# 5 notice
# 4 warning
# 3 err
# 2 crit
# 1 alert
# 0 emerg
#
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall
# log messages are generated by NetFilter and are logged using facility
# ''kern'' and the level that you specifify. If you are unsure
of the level
# to choose, 6 (info) is a safe bet. You may specify levels by name or by
# number.
#
# If you have build your kernel with ULOG target support, you may also
# specify a log level of ULOG (must be all caps). Rather than log its
# messages to syslogd, Shorewall will direct netfilter to log the messages
# via the ULOG target which will send them to a process called
''ulogd''.
# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be
# configured to log all Shorewall message to their own log file
################################################################################
#
# LOG FILE LOCATION
#
# This variable tells the /sbin/shorewall program where to look for Shorewall
# log messages. If not set or set to an empty string (e.g.,
LOGFILE="") then
# /var/log/messages is assumed.
#
# WARNING: The LOGFILE variable simply tells the ''shorewall''
program where to
# look for Shorewall messages.It does NOT control the destination for
# these messages. For information about how to do that, see
#
# http://www.shorewall.net/shorewall_logging.html
LOGFILE=/var/log/messages
#
# LOG FORMAT
#
# Shell ''printf'' Formatting template for the --log-prefix
value in log messages
# generated by Shorewall to identify Shorewall log messages. The supplied
# template is expected to accept either two or three arguments; the first is
# the chain name, the second (optional) is the logging rule number within that
# chain and the third is the ACTION specifying the disposition of the packet
# being logged. You must use the %d formatting type for the rule number; if your
# template does not contain %d then the rule number will not be included.
#
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
#
# LOGFORMAT="fp=%s:%d a=%s "
#
# If not specified or specified as empty (LOGFORMAT="") then the value
# "Shorewall:%s:%s:" is assumed.
#
# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up
# to but not including the first ''%'') to find log messages in
the ''show log'',
# ''status'' and ''hits'' commands. This part
should not be omitted (the
# LOGFORMAT should not begin with "%") and the leading part should be
# sufficiently unique for /sbin/shorewall to identify Shorewall messages.
LOGFORMAT="Shorewall:%s:%s:"
#
# LOG RATE LIMITING
#
# The next two variables can be used to control the amount of log output
# generated. LOGRATE is expressed as a number followed by an optional
# `/second'', `/minute'', `/hour'', or `/day''
suffix and specifies the maximum
# rate at which a particular message will occur. LOGBURST determines the
# maximum initial burst size that will be logged. If set empty, the default
# value of 5 will be used.
#
# Example:
#
# LOGRATE=10/minute
# LOGBURST=5
#
# If BOTH variables are set empty then logging will not be rate-limited.
#
LOGRATELOGBURST
#
# LEVEL AT WHICH TO LOG ''UNCLEAN'' PACKETS
#
# This variable determines the level at which Mangled/Invalid packets are logged
# under the ''dropunclean'' interface option. If you set this
variable to an
# empty value (e.g., LOGUNCLEAN= ), Mangled/Invalid packets will be dropped
# silently.
#
# The value of this variable also determines the level at which Mangled/Invalid
# packets are logged under the ''logunclean'' interface option.
If the variable
# is empty, these packets will still be logged at the ''info''
level.
#
# See the comment at the top of this section for a description of log levels
#
LOGUNCLEAN=info
#
# BLACKLIST LOG LEVEL
#
# Set this variable to the syslogd level that you want blacklist packets logged
# (beware of DOS attacks resulting from such logging). If not set, no logging
# of blacklist packets occurs.
#
# See the comment at the top of this section for a description of log levels
#
BLACKLIST_LOGLEVEL
#
# LOGGING ''New not SYN'' rejects
#
# This variable only has an effect when NEWNOTSYN=No (see below).
#
# When a TCP packet that does not have the SYN flag set and the ACK and RST
# flags clear then unless the packet is part of an established connection,
# it will be rejected by the firewall. If you want these rejects logged,
# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.
#
# See the comment at the top of this section for a description of log levels
#
# Example: LOGNEWNOTSYN=debug
LOGNEWNOTSYN
#
# MAC List Log Level
#
# Specifies the logging level for connection requests that fail MAC
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
# such connection requests will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
MACLIST_LOG_LEVEL=info
#
# TCP FLAGS Log Level
#
# Specifies the logging level for packets that fail TCP Flags
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="")
then
# such packets will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
TCP_FLAGS_LOG_LEVEL=info
#
# RFC1918 Log Level
#
# Specifies the logging level for packets that fail RFC 1918
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
# RFC1918_LOG_LEVEL=info is assumed.
#
# See the comment at the top of this section for a description of log levels
#
RFC1918_LOG_LEVEL=info
################################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
################################################################################
#
# PATH - Change this if you want to change the order in which Shorewall
# searches directories for executable files.
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
# SUBSYSTEM LOCK FILE
#
# Set this to the name of the lock file expected by your init scripts. For
# RedHat, this should be /var/lock/subsys/shorewall. On Debian, it
# should be "". If your init scripts don''t use lock files,
set this to "".
#
SUBSYSLOCK=""
#
# SHOREWALL TEMPORARY STATE DIRECTORY
#
# This is the directory where the firewall maintains state information while
# it is running
#
STATEDIR=/var/lib/shorewall
#
# KERNEL MODULE DIRECTORY
#
# If your netfilter kernel modules are in a directory other than
# /lib/modules/`uname -r`/kernel/net/ipv4/netfilter then specify that
# directory in this variable. Example: MODULESDIR=/etc/modules.
MODULESDIR
################################################################################
# F I R E W A L L O P T I O N S
################################################################################
# NAME OF THE FIREWALL ZONE
#
# Name of the firewall zone -- if not set or if set to an empty string,
"fw"
# is assumed.
#
FW=fw
#
# ENABLE NAT SUPPORT
#
# You probally want yes here. Only gateways not doing NAT in any form, like
# SNAT,DNAT masquerading, port forwading etc. should say "no" here.
#
NAT_ENABLED=Yes
#
# ENABLE MANGLE SUPPORT
#
# If you say "no" here, Shorewall will ignore the /etc/shorewall/tos
file
# and will not initialize the mangle table when starting or stopping
# your firewall. You must enable mangling if you want Traffic Shaping
# (see TC_ENABLED below).
#
MANGLE_ENABLED=Yes
#
# ENABLE IP FORWARDING
#
# If you say "On" or "on" here, IPV4 Packet Forwarding is
enabled. If you
# say "Off" or "off", packet forwarding will be disabled.
You would only want
# to disable packet forwarding if you are installing Shorewall on a
# standalone system or if you want all traffic through the Shorewall system
# to be handled by proxies.
#
# If you set this variable to "Keep" or "keep", Shorewall
will neither
# enable nor disable packet forwarding.
#
IP_FORWARDING=On
#
# AUTOMATICALLY ADD NAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will
automatically add IP addresses
# for each NAT external address that you give in /etc/shorewall/nat. If you say
# "No" or "no", you must add these aliases youself.
#
ADD_IP_ALIASES=Yes
#
# AUTOMATICALLY ADD SNAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will
automatically add IP addresses
# for each SNAT external address that you give in /etc/shorewall/masq. If you
say
# "No" or "no", you must add these aliases youself. LEAVE
THIS SET TO "No" unless
# you are sure that you need it -- most people don''t!!!
#
ADD_SNAT_ALIASES=No
#
# ENABLE TRAFFIC SHAPING
#
# If you say "Yes" or "yes" here, Traffic Shaping is enabled
in the firewall. If
# you say "No" or "no" then traffic shaping is not enabled.
If you enable traffic
# shaping you must have iproute[2] installed (the "ip" and
"tc" utilities) and
# you must enable packet mangling above.
#
TC_ENABLED=No
#
# Clear Traffic Shapping/Control
#
# If this option is set to ''No'' then Shorewall won''t
clear the current
# traffic control rules during [re]start. This setting is intended
# for use by people that prefer to configure traffic shaping when
# the network interfaces come up rather than when the firewall
# is started. If that is what you want to do, set TC_ENABLED=Yes and
# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
# way, your traffic shaping rules can still use the ''fwmark''
# classifier based on packet marking defined in /etc/shorewall/tcrules.
#
# If omitted, CLEAR_TC=Yes is assumed.
CLEAR_TC=Yes
#
# Mark Packets in the forward chain
#
# When processing the tcrules file, Shorewall normally marks packets in the
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
# this to "Yes". If not specified or if set to the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
# Marking packets in the FORWARD chain has the advantage that inbound
# packets destined for Masqueraded/SNATed local hosts have had their destination
# address rewritten so they can be marked based on their destination. When
# packets are marked in the PREROUTING chain, packets destined for
# Masqueraded/SNATed local hosts still have a destination address corresponding
# to the firewall''s external interface.
#
# Note: Older kernels do not support marking packets in the FORWARD chain and
# setting this variable to Yes may cause startup problems.
MARK_IN_FORWARD_CHAIN=No
#
# MSS CLAMPING
#
# Set this variable to "Yes" or "yes" if you want the TCP
"Clamp MSS to PMTU"
# option. This option is most commonly required when your internet
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
# have CONFIG_IP_NF_TARGET_TCPMSS set.
#
# [From the kernel help:
#
# This option adds a `TCPMSS'' target, which allows you to alter the
# MSS value of TCP SYN packets, to control the maximum size for that
# connection (usually limiting it to your outgoing interface''s MTU
# minus 40).
#
# This is used to overcome criminally braindead ISPs or servers which
# block ICMP Fragmentation Needed packets. The symptoms of this
# problem are that everything works fine from your Linux
# firewall/router, but machines behind it can never exchange large
# packets:
# 1) Web browsers connect, then hang with no data received.
# 2) Small mail works fine, but large emails hang.
# 3) ssh works fine, but scp hangs after initial handshaking.
# ]
#
# If left blank, or set to "No" or "no", the option is not
enabled.
#
CLAMPMSS=Yes
#
# ROUTE FILTERING
#
# Set this variable to "Yes" or "yes" if you want kernel
route filtering on all
# interfaces (anti-spoofing measure).
#
# If this variable is not set or is set to the empty value, "No" is
assumed.
# In that case, you can still enable route filtering on individual interfaces
# in the /etc/shorewall/interfaces file.
ROUTE_FILTER=Yes
#
# NAT BEFORE RULES
#
# Shorewall has traditionally processed static NAT rules before port forwarding
# rules. If you would like to reverse the order, set this variable to
"No".
#
# If this variable is not set or is set to the empty value, "Yes" is
assumed.
NAT_BEFORE_RULES=Yes
# MULTIPORT support
#
# If your kernel includes the multiport match option
# (CONFIG_IP_NF_MATCH_MULTIPORT), you may enable it''s use here. When
this
# option is enabled by setting it''s value to "Yes" or
"yes":
#
# 1) If you list more that 15 ports in a comma-seperated list in
# /etc/shorewall/rules, Shorewall will not use the multiport option
# but will generate a separate rule for each element of each port
# list.
# 2) If you include a port range (<low port>:<high port>) in the
# rule, Shorewall will not use the multiport option but will generate
# a separate rule for each element of each port list.
#
# See the /etc/shorewall/rules file for additional information on this option.
#
# if this variable is not set or is set to the empty value, "No" is
assumed.
MULTIPORT=No
# DNAT IP ADDRESS DETECTION
#
# Normally when Shorewall encounters the following rule:
#
# DNAT net loc:192.168.1.3 tcp 80
#
# it will forward TCP port 80 connections from the net to 192.168.1.3
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
# convenient for two reasons:
#
# a) If the the network interface has a dynamic IP address, the
# firewall configuration will work even when the address
# changes.
#
# b) It saves having to configure the IP address in the rule
# while still allowing the firewall to be started before the
# internet interface is brought up.
#
# This default behavior can also have a negative effect. If the
# internet interface has more than one IP address then the above
# rule will forward connection requests on all of these addresses;
# that may not be what is desired.
#
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
# only if the original destination address is the primary IP address of
# one of the interfaces associated with the source zone. Note that this
# requires all interfaces to the source zone to be up when the firewall
# is [re]started.
DETECT_DNAT_IPADDRS=No
#
# MUTEX TIMEOUT
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall lock file. After the number
# of seconds corresponding to the value of this variable, programs will assume
# that the last program to hold the lock died without releasing the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a "shorewall restart"
command.
MUTEX_TIMEOUT=60
#
# NEWNOTSYN
#
# If this variable is set to "No" or "no", then When a TCP
packet that does
# not have the SYN flag set and the ACK and RST flags clear then unless the
# packet is part of an established connection, it will be dropped by the
# firewall
#
# If this variable is set to "Yes" or "yes" then such
packets will not be
# dropped but will pass through the normal rule processing.
#
# Users with a High-availability setup with two firewall''s and one
acting
# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may
# also need to select NEWNOTSYN=Yes.
NEWNOTSYN=No
################################################################################
# P A C K E T D I S P O S I T I O N
################################################################################
#
# BLACKLIST DISPOSITION
#
# Set this variable to the action that you want to perform on packets from
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
# DROP is assumed.
#
BLACKLIST_DISPOSITION=DROP
#
# MAC List Disposition
#
# This variable determines the disposition of connection requests arriving
# on interfaces that have the ''maclist'' option and that are
from a device
# that is not listed for that interface in /etc/shorewall/maclist. Valid
# values are ACCEPT, DROP and REJECT. If not specified or specified as
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
MACLIST_DISPOSITION=REJECT
#
# TCP FLAGS Disposition
#
# This variable determins the disposition of packets having an invalid
# combination of TCP flags that are received on interfaces having the
# ''tcpflags'' option specified in /etc/shorewall/interfaces. If
not specified
# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is
assumed.
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.4 - Sample Masquerade file For Two Interfaces
#
# etc/shorewall/masq
#
# Use this file to define dynamic NAT (Masquerading) and to define Source NAT
# (SNAT).
#
# Columns are:
#
# INTERFACE
# Outgoing interface. This is usually your internet
# interface. If ADD_SNAT_ALIASES=Yes in
# /etc/shorewall/shorewall.conf, you may add ":" and
# a digit to indicate that you want the alias added with
# that name (e.g., eth0:0). This will allow the alias to
# be displayed with ifconfig. THAT IS THE ONLY USE FOR
# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER
# PLACE IN YOUR SHOREWALL CONFIGURATION.
#
# This may be qualified by adding the character
# ":" followed by a destination host or subnet.
#
#
# SUBNET
# Subnet that you wish to masquerade. You can specify this as
# a subnet or as an interface. If you give the name of an
# interface, you must have iproute installed and the interface
# must be up before you start the firewall.
#
# In order to exclude a subset of the specified SUBNET, you
# may append "!" and a comma-separated list of IP addresses
# and/or subnets that you wish to exclude.
#
# Example: eth1!192.168.1.4,192.168.32.0/27
#
# In that example traffic from eth1 would be masqueraded unless
# it came from 192.168.1.4 or 196.168.32.0/27
#
# ADDRESS (Optional)
# If you specify an address here, SNAT will be
# used and this will be the source address. If
# ADD_SNAT_ALIASES is set to Yes or yes in
# /etc/shorewall/shorewall.conf then Shorewall
# will automatically add this address to the
# INTERFACE named in the first column.
#
# WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if
# the address given in this column is the primary
# IP address for the interface in the INTERFACE
# column.
#
# This column may not contain a DNS Name.
#
# Example 1:
#
# You have a simple masquerading setup where eth0 connects to
# a DSL or cable modem and eth1 connects to your local network
# with subnet 192.168.0.0/24.
#
# Your entry in the file can be either:
#
# #INTERFACE SUBNET ADDRESS
# eth0 eth1
#
# or
#
# #INTERFACE SUBNET ADDRESS
# eth0 192.168.0.0/24
#
# Example 2:
#
# You add a router to your local network to connect subnet
# 192.168.1.0/24 which you also want to masquerade. You then
# add a second entry for eth0 to this file:
#
# #INTERFACE SUBNET ADDRESS
# eth0 192.168.1.0/24
#
# Example 3:
#
# You have an IPSEC tunnel through ipsec0 and you want to
# masquerade packets coming from 192.168.1.0/24 but only if
# these packets are destined for hosts in 10.1.1.0/24:
#
# #INTERFACE SUBNET ADDRESS
# ipsec0:10.1.1.0/24 196.168.1.0/24
#
# Example 4:
#
# You want all outgoing traffic from 192.168.1.0/24 through
# eth0 to use source address 206.124.146.176 which is NOT the
# primary address of eth0. You want 206.124.146.176 added to
# be added to eth0 with name eth0:0.
#
# #INTERFACE SUBNET ADDRESS
# eth0:0 192.168.1.0/24 206.124.146.176
#
##############################################################################
#INTERFACE SUBNET ADDRESS
ppp0 eth0
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.4 -- Sample Interface File For Two Interfaces
#
# /etc/shorewall/interfaces
#
# You must add an entry in this file for each network interface on your
# firewall system.
#
# Columns are:
#
# ZONE
# Zone for this interface. Must match the short name
# of a zone defined in /etc/shorewall/zones.
#
# If the interface serves multiple zones that will be
# defined in the /etc/shorewall/hosts file, you should
# place "-" in this column.
#
# INTERFACE
# Name of interface. Each interface may be listed only
# once in this file. You may NOT specify the name of
# an alias (e.g., eth0:0) here; see
# http://www.shorewall.net/FAQ.htm#faq18
#
# DO NOT DEFINE THE LOOPBACK INTERFACE (lo) IN THIS FILE.
#
# BROADCAST
# The broadcast address for the subnetwork to which the
# interface belongs. For P-T-P interfaces, this
# column is left blank.If the interface has multiple
# addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you use the special value "detect", the firewall
# will detect the broadcast address for you. If you
# select this option, the interface must be up before
# the firewall is started, you must have iproute
# installed and the interface must only be associated
# with a single subnet.
#
# If you don''t want to give a value for this column but
# you want to enter a value in the OPTIONS column, enter
# "-" in this column.
#
# OPTIONS
# A comma-separated list of options including the
# following:
#
# dhcp
# Interface is managed by DHCP or used by
# a DHCP server running on the firewall or
# you have a static IP but are on a LAN
# segment with lots of Laptop DHCP clients.
# norfc1918
# This interface should not receive
# any packets whose source is in one
# of the ranges reserved by RFC 1918
# (i.e., private or "non-routable"
# addresses. If packet mangling is
# enabled in shorewall.conf, packets
# whose destination addresses are
# reserved by RFC 1918 are also rejected.
# routefilter
# Turn on kernel route filtering for this
# interface (anti-spoofing measure). This
# option can also be enabled globally in
# the /etc/shorewall/shorewall.conf file.
# dropunclean
# Logs and drops mangled/invalid packets
# logunclean
# Logs mangled/invalid packets but does
# not drop them.
# blacklist
# Check packets arriving on this interface
# against the /etc/shorewall/blacklist
# file.
# maclist
# Connection requests from this interface
# are compared against the contents of
# /etc/shorewall/maclist. If this option
# is specified, the interface must be
# an ethernet NIC and must be up before
# Shorewall is started.
# tcpflags
# Packets arriving on this interface are
# checked for certain illegal combinations
# of TCP flags. Packets found to have
# such a combination of flags are handled
# according to the setting of
# TCP_FLAGS_DISPOSITION after having been
# logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
# proxyarp
# Sets /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
# Do NOT use this option if you are
# employing Proxy ARP through entries in
# /etc/shorewall/proxyarp. This option is
# intended soley for use with Proxy ARP
# sub-networking as described at:
# http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet
#
# The order in which you list the options is not
# significant but the list should have no embedded white
# space.
#
# Example 1:
# Suppose you have eth0 connected to a DSL modem and
# eth1 connected to your local network and that your
# local subnet is 192.168.1.0/24. The eth0 interface gets
# it''s IP address via DHCP from subnet 206.191.149.192/27.
#
# Your entries for this setup would look like:
#
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# local eth1 192.168.1.255
#
# Example 2:
# The same configuration without specifying broadcast
# addresses is:
#
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 detect dhcp
# loc eth1 detect
#
##############################################################################
#ZONE INTERFACE BROADCAST OPTIONS
net ppp0 - routefilter,norfc1918
loc eth0 detect
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.4 -- Sample Policy File For Two Interfaces
#
# /etc/shorewall/policy
#
# This file determines what to do with a new connection request if we
# don''t get a match from the /etc/shorewall/rules file or from the
# /etc/shorewall/common[.def] file. For each source/destination pair, the
# file is processed in order until a match is found ("all" will match
# any client or server).
#
# Columns are:
#
# SOURCE Source zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all".
#
# DEST Destination zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all"
#
# WARNING: Firewall->Firewall policies are not allowed; if
# you have a policy where both SOURCE and DEST are $FW,
# Shorewall will not start!
#
# POLICY Policy if no match from the rules file is found. Must
# be "ACCEPT", "DROP", "REJECT",
"CONTINUE" Or "NONE"
#
# ACCEPT
# Accept the connection
# DROP
# Ignore the connection request.
# REJECT
# For TCP, send RST. For all other, send
# "port unreachable" ICMP.
# CONTINUE
# Pass the connection request past
# any other rules that it might also
# match (where the source or destination
# zone in those rules is a superset of
# the SOURCE or DEST in this policy)
# NONE
# Assume that there will never be any
# packets from this SOURCE to this
# DEST. Shorewall will not set up any
# infrastructure to handle such packets
# and you may not have any rules with
# this SOURCE and DEST in the /etc/shorewall/rules
# file. If such a packet is received the result
# is undefined.
#
# LOG LEVEL If supplied, each connection handled under the default
# POLICY is logged at that level. If not supplied, no
# log message is generated. See syslog.conf(5) for a
# description of log levels.
#
# Beginning with Shorewall version 1.3.12, you may
# also specify ULOG (must be in upper case). This will
# log to the ULOG target and sent to a separate log
# through use of ulogd (http://www.gnumonks.org/projects/ulogd).
#
# If you don''t want to log but need to specify the
# following column, place "_" here.
#
# LIMIT:BURST If passed, specifies the maximum TCP connection rate
# and the size of an acceptable burst. If not specified,
# TCP connections are not limited.
#
# As shipped, the default policies are:
#
# a) All connections from the local network to the Internet are allowed
# b) All connections from the Internet are ignored but logged at syslog
# level KERNEL.INFO.
# d) All other connection requests are rejected and logged at level
# KERNEL.INFO.
###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
#fw net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
figti@netcourrier.com
2003-Jul-09 06:24 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
I''ve the xMule p2p program running on my firewall, which is also a
gateway for my private network.
I''ve set Shorewall according to the "Two-interface QuickStart
Guide" (policy, rules, masq, interfaces, shorewall.conf files attached)
I noticed that Shorewall causes xMule to weird behaviors : after 15-20 minutes,
xMule drains 100% CPU and thus "hangs".
I found out that shutting down Shorewall get things back to normal ( xMule gets
back to 5-10% CPU...)
Restarting Shorewall causes xMule to get back to 100% CPU within 10-15 minutes
:(
To my point of view, it is quite the same as a "funnel phenomenon",
with xMule having large amounts of incoming/outgoing connections, and Shorewalls
struggling under that heavy load.
Besides, I noticed that adding
"fw net ACCEPT" in /etc/shorewall/policy
causes xMule to run smoothly for hours (but this way my gateway is not protected
any more...)
I''ve asked on the xMule board, but nobody seems to be able to help.
I''m now totally stuck. Actually xMule can indeed run, but my gateway
and my whole network is spread open to the whole Internet :(
Thanx very much
PS : I tried with Shorewall 1.2 as well as 1.4.4b, both give the same result.
I''m on Debian testing/unstable
Additionnal informations :
Figuera:/etc/shorewall# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:01:01:d4:7c:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
70: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
3
link/ppp
inet 212.195.95.243 peer 212.195.88.1/32 scope global ppp0
Figuera:/etc/shorewall#
Figuera:/etc/shorewall# ip route show
212.195.88.1 dev ppp0 proto kernel scope link src 212.195.95.243
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
default via 212.195.88.1 dev ppp0
Figuera:/etc/shorewall#
I did not include "shorewall status" output cause it''s a
300Ko file. Anyway I may compress it and send it back if needed
-------------------------------------------------------------
NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min)
Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
-------------- next part --------------
#
# Shorewall 1.4 -- Sample Policy File For Two Interfaces
#
# /etc/shorewall/policy
#
# This file determines what to do with a new connection request if we
# don''t get a match from the /etc/shorewall/rules file or from the
# /etc/shorewall/common[.def] file. For each source/destination pair, the
# file is processed in order until a match is found ("all" will match
# any client or server).
#
# Columns are:
#
# SOURCE Source zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all".
#
# DEST Destination zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all"
#
# WARNING: Firewall->Firewall policies are not allowed; if
# you have a policy where both SOURCE and DEST are $FW,
# Shorewall will not start!
#
# POLICY Policy if no match from the rules file is found. Must
# be "ACCEPT", "DROP", "REJECT",
"CONTINUE" Or "NONE"
#
# ACCEPT
# Accept the connection
# DROP
# Ignore the connection request.
# REJECT
# For TCP, send RST. For all other, send
# "port unreachable" ICMP.
# CONTINUE
# Pass the connection request past
# any other rules that it might also
# match (where the source or destination
# zone in those rules is a superset of
# the SOURCE or DEST in this policy)
# NONE
# Assume that there will never be any
# packets from this SOURCE to this
# DEST. Shorewall will not set up any
# infrastructure to handle such packets
# and you may not have any rules with
# this SOURCE and DEST in the /etc/shorewall/rules
# file. If such a packet is received the result
# is undefined.
#
# LOG LEVEL If supplied, each connection handled under the default
# POLICY is logged at that level. If not supplied, no
# log message is generated. See syslog.conf(5) for a
# description of log levels.
#
# Beginning with Shorewall version 1.3.12, you may
# also specify ULOG (must be in upper case). This will
# log to the ULOG target and sent to a separate log
# through use of ulogd (http://www.gnumonks.org/projects/ulogd).
#
# If you don''t want to log but need to specify the
# following column, place "_" here.
#
# LIMIT:BURST If passed, specifies the maximum TCP connection rate
# and the size of an acceptable burst. If not specified,
# TCP connections are not limited.
#
# As shipped, the default policies are:
#
# a) All connections from the local network to the Internet are allowed
# b) All connections from the Internet are ignored but logged at syslog
# level KERNEL.INFO.
# d) All other connection requests are rejected and logged at level
# KERNEL.INFO.
###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
#fw net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.4 -- Sample Interface File For Two Interfaces
#
# /etc/shorewall/interfaces
#
# You must add an entry in this file for each network interface on your
# firewall system.
#
# Columns are:
#
# ZONE
# Zone for this interface. Must match the short name
# of a zone defined in /etc/shorewall/zones.
#
# If the interface serves multiple zones that will be
# defined in the /etc/shorewall/hosts file, you should
# place "-" in this column.
#
# INTERFACE
# Name of interface. Each interface may be listed only
# once in this file. You may NOT specify the name of
# an alias (e.g., eth0:0) here; see
# http://www.shorewall.net/FAQ.htm#faq18
#
# DO NOT DEFINE THE LOOPBACK INTERFACE (lo) IN THIS FILE.
#
# BROADCAST
# The broadcast address for the subnetwork to which the
# interface belongs. For P-T-P interfaces, this
# column is left blank.If the interface has multiple
# addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you use the special value "detect", the firewall
# will detect the broadcast address for you. If you
# select this option, the interface must be up before
# the firewall is started, you must have iproute
# installed and the interface must only be associated
# with a single subnet.
#
# If you don''t want to give a value for this column but
# you want to enter a value in the OPTIONS column, enter
# "-" in this column.
#
# OPTIONS
# A comma-separated list of options including the
# following:
#
# dhcp
# Interface is managed by DHCP or used by
# a DHCP server running on the firewall or
# you have a static IP but are on a LAN
# segment with lots of Laptop DHCP clients.
# norfc1918
# This interface should not receive
# any packets whose source is in one
# of the ranges reserved by RFC 1918
# (i.e., private or "non-routable"
# addresses. If packet mangling is
# enabled in shorewall.conf, packets
# whose destination addresses are
# reserved by RFC 1918 are also rejected.
# routefilter
# Turn on kernel route filtering for this
# interface (anti-spoofing measure). This
# option can also be enabled globally in
# the /etc/shorewall/shorewall.conf file.
# dropunclean
# Logs and drops mangled/invalid packets
# logunclean
# Logs mangled/invalid packets but does
# not drop them.
# blacklist
# Check packets arriving on this interface
# against the /etc/shorewall/blacklist
# file.
# maclist
# Connection requests from this interface
# are compared against the contents of
# /etc/shorewall/maclist. If this option
# is specified, the interface must be
# an ethernet NIC and must be up before
# Shorewall is started.
# tcpflags
# Packets arriving on this interface are
# checked for certain illegal combinations
# of TCP flags. Packets found to have
# such a combination of flags are handled
# according to the setting of
# TCP_FLAGS_DISPOSITION after having been
# logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
# proxyarp
# Sets /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
# Do NOT use this option if you are
# employing Proxy ARP through entries in
# /etc/shorewall/proxyarp. This option is
# intended soley for use with Proxy ARP
# sub-networking as described at:
# http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet
#
# The order in which you list the options is not
# significant but the list should have no embedded white
# space.
#
# Example 1:
# Suppose you have eth0 connected to a DSL modem and
# eth1 connected to your local network and that your
# local subnet is 192.168.1.0/24. The eth0 interface gets
# it''s IP address via DHCP from subnet 206.191.149.192/27.
#
# Your entries for this setup would look like:
#
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# local eth1 192.168.1.255
#
# Example 2:
# The same configuration without specifying broadcast
# addresses is:
#
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 detect dhcp
# loc eth1 detect
#
##############################################################################
#ZONE INTERFACE BROADCAST OPTIONS
net ppp0 - routefilter,norfc1918
loc eth0 detect
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-------------- next part --------------
##############################################################################
# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# L O G G I N G
##############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
#
# Valid levels are:
#
# 7 debug
# 6 info
# 5 notice
# 4 warning
# 3 err
# 2 crit
# 1 alert
# 0 emerg
#
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall
# log messages are generated by NetFilter and are logged using facility
# ''kern'' and the level that you specifify. If you are unsure
of the level
# to choose, 6 (info) is a safe bet. You may specify levels by name or by
# number.
#
# If you have build your kernel with ULOG target support, you may also
# specify a log level of ULOG (must be all caps). Rather than log its
# messages to syslogd, Shorewall will direct netfilter to log the messages
# via the ULOG target which will send them to a process called
''ulogd''.
# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be
# configured to log all Shorewall message to their own log file
################################################################################
#
# LOG FILE LOCATION
#
# This variable tells the /sbin/shorewall program where to look for Shorewall
# log messages. If not set or set to an empty string (e.g.,
LOGFILE="") then
# /var/log/messages is assumed.
#
# WARNING: The LOGFILE variable simply tells the ''shorewall''
program where to
# look for Shorewall messages.It does NOT control the destination for
# these messages. For information about how to do that, see
#
# http://www.shorewall.net/shorewall_logging.html
LOGFILE=/var/log/messages
#
# LOG FORMAT
#
# Shell ''printf'' Formatting template for the --log-prefix
value in log messages
# generated by Shorewall to identify Shorewall log messages. The supplied
# template is expected to accept either two or three arguments; the first is
# the chain name, the second (optional) is the logging rule number within that
# chain and the third is the ACTION specifying the disposition of the packet
# being logged. You must use the %d formatting type for the rule number; if your
# template does not contain %d then the rule number will not be included.
#
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
#
# LOGFORMAT="fp=%s:%d a=%s "
#
# If not specified or specified as empty (LOGFORMAT="") then the value
# "Shorewall:%s:%s:" is assumed.
#
# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up
# to but not including the first ''%'') to find log messages in
the ''show log'',
# ''status'' and ''hits'' commands. This part
should not be omitted (the
# LOGFORMAT should not begin with "%") and the leading part should be
# sufficiently unique for /sbin/shorewall to identify Shorewall messages.
LOGFORMAT="Shorewall:%s:%s:"
#
# LOG RATE LIMITING
#
# The next two variables can be used to control the amount of log output
# generated. LOGRATE is expressed as a number followed by an optional
# `/second'', `/minute'', `/hour'', or `/day''
suffix and specifies the maximum
# rate at which a particular message will occur. LOGBURST determines the
# maximum initial burst size that will be logged. If set empty, the default
# value of 5 will be used.
#
# Example:
#
# LOGRATE=10/minute
# LOGBURST=5
#
# If BOTH variables are set empty then logging will not be rate-limited.
#
LOGRATELOGBURST
#
# LEVEL AT WHICH TO LOG ''UNCLEAN'' PACKETS
#
# This variable determines the level at which Mangled/Invalid packets are logged
# under the ''dropunclean'' interface option. If you set this
variable to an
# empty value (e.g., LOGUNCLEAN= ), Mangled/Invalid packets will be dropped
# silently.
#
# The value of this variable also determines the level at which Mangled/Invalid
# packets are logged under the ''logunclean'' interface option.
If the variable
# is empty, these packets will still be logged at the ''info''
level.
#
# See the comment at the top of this section for a description of log levels
#
LOGUNCLEAN=info
#
# BLACKLIST LOG LEVEL
#
# Set this variable to the syslogd level that you want blacklist packets logged
# (beware of DOS attacks resulting from such logging). If not set, no logging
# of blacklist packets occurs.
#
# See the comment at the top of this section for a description of log levels
#
BLACKLIST_LOGLEVEL
#
# LOGGING ''New not SYN'' rejects
#
# This variable only has an effect when NEWNOTSYN=No (see below).
#
# When a TCP packet that does not have the SYN flag set and the ACK and RST
# flags clear then unless the packet is part of an established connection,
# it will be rejected by the firewall. If you want these rejects logged,
# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.
#
# See the comment at the top of this section for a description of log levels
#
# Example: LOGNEWNOTSYN=debug
LOGNEWNOTSYN
#
# MAC List Log Level
#
# Specifies the logging level for connection requests that fail MAC
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
# such connection requests will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
MACLIST_LOG_LEVEL=info
#
# TCP FLAGS Log Level
#
# Specifies the logging level for packets that fail TCP Flags
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="")
then
# such packets will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
TCP_FLAGS_LOG_LEVEL=info
#
# RFC1918 Log Level
#
# Specifies the logging level for packets that fail RFC 1918
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
# RFC1918_LOG_LEVEL=info is assumed.
#
# See the comment at the top of this section for a description of log levels
#
RFC1918_LOG_LEVEL=info
################################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
################################################################################
#
# PATH - Change this if you want to change the order in which Shorewall
# searches directories for executable files.
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
# SUBSYSTEM LOCK FILE
#
# Set this to the name of the lock file expected by your init scripts. For
# RedHat, this should be /var/lock/subsys/shorewall. On Debian, it
# should be "". If your init scripts don''t use lock files,
set this to "".
#
SUBSYSLOCK=""
#
# SHOREWALL TEMPORARY STATE DIRECTORY
#
# This is the directory where the firewall maintains state information while
# it is running
#
STATEDIR=/var/lib/shorewall
#
# KERNEL MODULE DIRECTORY
#
# If your netfilter kernel modules are in a directory other than
# /lib/modules/`uname -r`/kernel/net/ipv4/netfilter then specify that
# directory in this variable. Example: MODULESDIR=/etc/modules.
MODULESDIR
################################################################################
# F I R E W A L L O P T I O N S
################################################################################
# NAME OF THE FIREWALL ZONE
#
# Name of the firewall zone -- if not set or if set to an empty string,
"fw"
# is assumed.
#
FW=fw
#
# ENABLE NAT SUPPORT
#
# You probally want yes here. Only gateways not doing NAT in any form, like
# SNAT,DNAT masquerading, port forwading etc. should say "no" here.
#
NAT_ENABLED=Yes
#
# ENABLE MANGLE SUPPORT
#
# If you say "no" here, Shorewall will ignore the /etc/shorewall/tos
file
# and will not initialize the mangle table when starting or stopping
# your firewall. You must enable mangling if you want Traffic Shaping
# (see TC_ENABLED below).
#
MANGLE_ENABLED=Yes
#
# ENABLE IP FORWARDING
#
# If you say "On" or "on" here, IPV4 Packet Forwarding is
enabled. If you
# say "Off" or "off", packet forwarding will be disabled.
You would only want
# to disable packet forwarding if you are installing Shorewall on a
# standalone system or if you want all traffic through the Shorewall system
# to be handled by proxies.
#
# If you set this variable to "Keep" or "keep", Shorewall
will neither
# enable nor disable packet forwarding.
#
IP_FORWARDING=On
#
# AUTOMATICALLY ADD NAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will
automatically add IP addresses
# for each NAT external address that you give in /etc/shorewall/nat. If you say
# "No" or "no", you must add these aliases youself.
#
ADD_IP_ALIASES=Yes
#
# AUTOMATICALLY ADD SNAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will
automatically add IP addresses
# for each SNAT external address that you give in /etc/shorewall/masq. If you
say
# "No" or "no", you must add these aliases youself. LEAVE
THIS SET TO "No" unless
# you are sure that you need it -- most people don''t!!!
#
ADD_SNAT_ALIASES=No
#
# ENABLE TRAFFIC SHAPING
#
# If you say "Yes" or "yes" here, Traffic Shaping is enabled
in the firewall. If
# you say "No" or "no" then traffic shaping is not enabled.
If you enable traffic
# shaping you must have iproute[2] installed (the "ip" and
"tc" utilities) and
# you must enable packet mangling above.
#
TC_ENABLED=No
#
# Clear Traffic Shapping/Control
#
# If this option is set to ''No'' then Shorewall won''t
clear the current
# traffic control rules during [re]start. This setting is intended
# for use by people that prefer to configure traffic shaping when
# the network interfaces come up rather than when the firewall
# is started. If that is what you want to do, set TC_ENABLED=Yes and
# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
# way, your traffic shaping rules can still use the ''fwmark''
# classifier based on packet marking defined in /etc/shorewall/tcrules.
#
# If omitted, CLEAR_TC=Yes is assumed.
CLEAR_TC=Yes
#
# Mark Packets in the forward chain
#
# When processing the tcrules file, Shorewall normally marks packets in the
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
# this to "Yes". If not specified or if set to the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
# Marking packets in the FORWARD chain has the advantage that inbound
# packets destined for Masqueraded/SNATed local hosts have had their destination
# address rewritten so they can be marked based on their destination. When
# packets are marked in the PREROUTING chain, packets destined for
# Masqueraded/SNATed local hosts still have a destination address corresponding
# to the firewall''s external interface.
#
# Note: Older kernels do not support marking packets in the FORWARD chain and
# setting this variable to Yes may cause startup problems.
MARK_IN_FORWARD_CHAIN=No
#
# MSS CLAMPING
#
# Set this variable to "Yes" or "yes" if you want the TCP
"Clamp MSS to PMTU"
# option. This option is most commonly required when your internet
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
# have CONFIG_IP_NF_TARGET_TCPMSS set.
#
# [From the kernel help:
#
# This option adds a `TCPMSS'' target, which allows you to alter the
# MSS value of TCP SYN packets, to control the maximum size for that
# connection (usually limiting it to your outgoing interface''s MTU
# minus 40).
#
# This is used to overcome criminally braindead ISPs or servers which
# block ICMP Fragmentation Needed packets. The symptoms of this
# problem are that everything works fine from your Linux
# firewall/router, but machines behind it can never exchange large
# packets:
# 1) Web browsers connect, then hang with no data received.
# 2) Small mail works fine, but large emails hang.
# 3) ssh works fine, but scp hangs after initial handshaking.
# ]
#
# If left blank, or set to "No" or "no", the option is not
enabled.
#
CLAMPMSS=Yes
#
# ROUTE FILTERING
#
# Set this variable to "Yes" or "yes" if you want kernel
route filtering on all
# interfaces (anti-spoofing measure).
#
# If this variable is not set or is set to the empty value, "No" is
assumed.
# In that case, you can still enable route filtering on individual interfaces
# in the /etc/shorewall/interfaces file.
ROUTE_FILTER=Yes
#
# NAT BEFORE RULES
#
# Shorewall has traditionally processed static NAT rules before port forwarding
# rules. If you would like to reverse the order, set this variable to
"No".
#
# If this variable is not set or is set to the empty value, "Yes" is
assumed.
NAT_BEFORE_RULES=Yes
# MULTIPORT support
#
# If your kernel includes the multiport match option
# (CONFIG_IP_NF_MATCH_MULTIPORT), you may enable it''s use here. When
this
# option is enabled by setting it''s value to "Yes" or
"yes":
#
# 1) If you list more that 15 ports in a comma-seperated list in
# /etc/shorewall/rules, Shorewall will not use the multiport option
# but will generate a separate rule for each element of each port
# list.
# 2) If you include a port range (<low port>:<high port>) in the
# rule, Shorewall will not use the multiport option but will generate
# a separate rule for each element of each port list.
#
# See the /etc/shorewall/rules file for additional information on this option.
#
# if this variable is not set or is set to the empty value, "No" is
assumed.
MULTIPORT=No
# DNAT IP ADDRESS DETECTION
#
# Normally when Shorewall encounters the following rule:
#
# DNAT net loc:192.168.1.3 tcp 80
#
# it will forward TCP port 80 connections from the net to 192.168.1.3
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
# convenient for two reasons:
#
# a) If the the network interface has a dynamic IP address, the
# firewall configuration will work even when the address
# changes.
#
# b) It saves having to configure the IP address in the rule
# while still allowing the firewall to be started before the
# internet interface is brought up.
#
# This default behavior can also have a negative effect. If the
# internet interface has more than one IP address then the above
# rule will forward connection requests on all of these addresses;
# that may not be what is desired.
#
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
# only if the original destination address is the primary IP address of
# one of the interfaces associated with the source zone. Note that this
# requires all interfaces to the source zone to be up when the firewall
# is [re]started.
DETECT_DNAT_IPADDRS=No
#
# MUTEX TIMEOUT
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall lock file. After the number
# of seconds corresponding to the value of this variable, programs will assume
# that the last program to hold the lock died without releasing the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a "shorewall restart"
command.
MUTEX_TIMEOUT=60
#
# NEWNOTSYN
#
# If this variable is set to "No" or "no", then When a TCP
packet that does
# not have the SYN flag set and the ACK and RST flags clear then unless the
# packet is part of an established connection, it will be dropped by the
# firewall
#
# If this variable is set to "Yes" or "yes" then such
packets will not be
# dropped but will pass through the normal rule processing.
#
# Users with a High-availability setup with two firewall''s and one
acting
# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may
# also need to select NEWNOTSYN=Yes.
NEWNOTSYN=No
################################################################################
# P A C K E T D I S P O S I T I O N
################################################################################
#
# BLACKLIST DISPOSITION
#
# Set this variable to the action that you want to perform on packets from
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
# DROP is assumed.
#
BLACKLIST_DISPOSITION=DROP
#
# MAC List Disposition
#
# This variable determines the disposition of connection requests arriving
# on interfaces that have the ''maclist'' option and that are
from a device
# that is not listed for that interface in /etc/shorewall/maclist. Valid
# values are ACCEPT, DROP and REJECT. If not specified or specified as
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
MACLIST_DISPOSITION=REJECT
#
# TCP FLAGS Disposition
#
# This variable determins the disposition of packets having an invalid
# combination of TCP flags that are received on interfaces having the
# ''tcpflags'' option specified in /etc/shorewall/interfaces. If
not specified
# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is
assumed.
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.4 - Sample Masquerade file For Two Interfaces
#
# etc/shorewall/masq
#
# Use this file to define dynamic NAT (Masquerading) and to define Source NAT
# (SNAT).
#
# Columns are:
#
# INTERFACE
# Outgoing interface. This is usually your internet
# interface. If ADD_SNAT_ALIASES=Yes in
# /etc/shorewall/shorewall.conf, you may add ":" and
# a digit to indicate that you want the alias added with
# that name (e.g., eth0:0). This will allow the alias to
# be displayed with ifconfig. THAT IS THE ONLY USE FOR
# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER
# PLACE IN YOUR SHOREWALL CONFIGURATION.
#
# This may be qualified by adding the character
# ":" followed by a destination host or subnet.
#
#
# SUBNET
# Subnet that you wish to masquerade. You can specify this as
# a subnet or as an interface. If you give the name of an
# interface, you must have iproute installed and the interface
# must be up before you start the firewall.
#
# In order to exclude a subset of the specified SUBNET, you
# may append "!" and a comma-separated list of IP addresses
# and/or subnets that you wish to exclude.
#
# Example: eth1!192.168.1.4,192.168.32.0/27
#
# In that example traffic from eth1 would be masqueraded unless
# it came from 192.168.1.4 or 196.168.32.0/27
#
# ADDRESS (Optional)
# If you specify an address here, SNAT will be
# used and this will be the source address. If
# ADD_SNAT_ALIASES is set to Yes or yes in
# /etc/shorewall/shorewall.conf then Shorewall
# will automatically add this address to the
# INTERFACE named in the first column.
#
# WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if
# the address given in this column is the primary
# IP address for the interface in the INTERFACE
# column.
#
# This column may not contain a DNS Name.
#
# Example 1:
#
# You have a simple masquerading setup where eth0 connects to
# a DSL or cable modem and eth1 connects to your local network
# with subnet 192.168.0.0/24.
#
# Your entry in the file can be either:
#
# #INTERFACE SUBNET ADDRESS
# eth0 eth1
#
# or
#
# #INTERFACE SUBNET ADDRESS
# eth0 192.168.0.0/24
#
# Example 2:
#
# You add a router to your local network to connect subnet
# 192.168.1.0/24 which you also want to masquerade. You then
# add a second entry for eth0 to this file:
#
# #INTERFACE SUBNET ADDRESS
# eth0 192.168.1.0/24
#
# Example 3:
#
# You have an IPSEC tunnel through ipsec0 and you want to
# masquerade packets coming from 192.168.1.0/24 but only if
# these packets are destined for hosts in 10.1.1.0/24:
#
# #INTERFACE SUBNET ADDRESS
# ipsec0:10.1.1.0/24 196.168.1.0/24
#
# Example 4:
#
# You want all outgoing traffic from 192.168.1.0/24 through
# eth0 to use source address 206.124.146.176 which is NOT the
# primary address of eth0. You want 206.124.146.176 added to
# be added to eth0 with name eth0:0.
#
# #INTERFACE SUBNET ADDRESS
# eth0:0 192.168.1.0/24 206.124.146.176
#
##############################################################################
#INTERFACE SUBNET ADDRESS
ppp0 eth0
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall version 1.4 - Sample Rules File For Two Interfaces
#
# /etc/shorewall/rules
#
# Rules in this file govern connection establishment. Requests and
# responses are automatically allowed using connection tracking.
#
# In most places where an IP address or subnet is allowed, you
# can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to
# indicate that the rule matches all addresses except the address/subnet
# given. Notice that no white space is permitted between "!" and the
# address/subnet.
#
# Columns are:
#
#
# ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT,
# CONTINUE or LOG.
#
# ACCEPT
# Allow the connection request
# DROP
# Ignore the request
# REJECT
# Disallow the request and return an
# icmp-unreachable or an RST packet.
# DNAT
# Forward the request to another
# system (and optionally another
# port).
# DNAT-
# Advanced users only.
# Like DNAT but only generates the
# DNAT iptables rule and not
# the companion ACCEPT rule.
# REDIRECT
# Redirect the request to a local
# port on the firewall.
# REDIRECT-
# Advanced users only.
# Like REDIRECT but only generates the
# REDIRECT iptables rule and not the
# companion ACCEPT rule.
# CONTINUE
# (For experts only). Do Not Process
# any of the following rules for this
# (source zone,destination zone). If
# the source and/or destination IP
# address falls into a zone defined
# later in /etc/shorewall/zones, this
# connection request will be passed
# to the rules defined for that
# (those) zones(s).
# LOG
# Simply log the packet and continue.
#
# May optionally be followed by ":" and a syslog log
# level (e.g, REJECT:info). This causes the packet to be
# logged at the specified level.
#
# You may also specify ULOG (must be in upper case) as a
# log level. This will log to the ULOG target for routing
# to a separate log through use of ulogd.
# (http://www.gnumonks.org/projects/ulogd).
#
# SOURCE Source hosts to which the rule applies. May be a zone
# defined in /etc/shorewall/zones, $FW to indicate the
# firewall itself, or "all" If the ACTION is DNAT or
# REDIRECT, sub-zones of the specified zone may be
# excluded from the rule by following the zone name with
# "!'' and a comma-separated list of sub-zone names.
#
# Except when "all" is specified, clients may be further
# restricted to a list of subnets and/or hosts by
# appending ":" and a comma-separated list of subnets
# and/or hosts. Hosts may be specified by IP or MAC
# address; mac addresses must begin with "~" and must use
# "-" as a separator.
#
# Some Examples:
#
# net:155.186.235.1
# Host 155.186.235.1 on the Internet
#
# loc:192.168.1.0/24
# Subnet 192.168.1.0/24 on the
# Local Network
#
# net:155.186.235.1,155.186.235.2
# Hosts 155.186.235.1 and
# 155.186.235.2 on the Internet.
#
# loc:~00-A0-C9-15-39-78
# Host on the Local Network with
# MAC address 00:A0:C9:15:39:78.
#
# Alternatively, clients may be specified by interface
# by appending ":" to the zone name followed by the
# interface name. For example, net:eth0 specifies a
# client that communicates with the firewall system
# through eth0. This may be optionally followed by
# another colon (":") and an IP/MAC/subnet address
# as described above (e.g., net:eth0:192.168.1.5).
#
# DEST Location of Server. May be a zone defined in
# /etc/shorewall/zones, $FW to indicate the firewall
# itself or "all"
#
# Except when "all" is specified, the server may be
# further restricted to a particular subnet, host or
# interface by appending ":" and the subnet, host or
# interface. See above.
#
# Restrictions:
#
# 1. MAC addresses are not allowed.
# 2. In DNAT rules, only IP addresses are
# allowed; no FQDNs or subnet addresses
# are permitted.
# 3 You may not specify both an interface and
# an address.
#
# The port that the server is listening on may be
# included and separated from the server''s IP address by
# ":". If omitted, the firewall will not modifiy the
# destination port. A destination port may only be
# included if the ACTION is DNAT or REDIRECT.
#
# Example: net:155.186.235.1:25 specifies a Internet
# server at IP address 155.186.235.1 and listening on port
# 25. The port number MUST be specified as an integer
# and not as a name from /etc/services.
#
# If the ACTION is REDIRECT, this column needs only to
# contain the port number on the firewall that the
# request should be redirected to.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp",
a number,
# "all".
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port
# ranges; if the protocol is "icmp", this column is
# interpreted as the destination icmp-type(s).
#
# A port range is expressed as <low port>:<high port>.
#
# This column is ignored if PROTOCOL = all but must be
# entered if any of the following ields are supplied.
# In that case, it is suggested that this field contain
# "-"
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the CLIENT PORT(S) list below:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# CLIENT PORT(S) (Optional) Port(s) used by the client. If omitted,
# any source port is acceptable. Specified as a comma-
# separated list of port names, port numbers or port
# ranges.
#
# If you don''t want to restrict client ports but need to
# specify an ADDRESS in the next column, then place "-"
# in this column.
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the DEST PORT(S) list above:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT[-] or
# REDIRECT[-]) If included and different from the IP
# address given in the SERVER column, this is an address
# on some interface on the firewall and connections to
# that address will be forwarded to the IP and port
# specified in the DEST column.
#
# The address may optionally be followed by
# a colon (":") and a second IP address. This causes
# Shorewall to use the second IP address as the source
# address in forwarded packets. See the Shorewall
# documentation for restrictions concerning this feature.
# If no source IP address is given, the original source
# address is not altered.
#
# Also by default all outbound loc -> net communications are allowed.
# You can change this behavior in the sample policy file.
#
# Example: Accept www requests to the firewall.
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# ACCEPT net fw tcp http
#
# Example: Accept SMTP requests from the Local Network to the Internet
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# ACCEPT loc net tcp smtp
#
# Example: Forward all ssh and http connection requests from the Internet
# to local system 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp ssh,http
#
# Example: Redirect all locally-originating www connection requests to
# port 3128 on the firewall (Squid running on the firewall
# system) except when the destination address is 192.168.2.2
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# REDIRECT loc 3128 tcp www - !192.168.2.2
#
# Example: All http requests from the Internet to address
# 130.252.100.69 are to be forwarded to 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69
##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT net fw icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw net icmp 8
#
# Accept DNS connections from the firewall to the Internet
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
########### SSH: ##################################################
#
# Accept SSH connections from the local network and from the Internet
#
ACCEPT loc fw tcp 22
ACCEPT net fw tcp 22
# Accepter les connexions SSH du firewall vers le r?seau local
#(inutile pour l''instant)
#ACCEPT fw loc tcp 22
#
# Accepter les connexions Web du fw vers le net: ports 80 (http) et 443 (https)
en tcp
# (pour pouvoir faire du Web ? partir du poste fw)
ACCEPT fw net tcp 80
ACCEPT fw net tcp 443
#
########### PRIVOXY #######################
#
# Accepter la connexion du proxy (privoxy) vers le net (privoxy : port 8118;
install? sur le poste fw)
ACCEPT fw net tcp 8118
ACCEPT fw net udp 8118
#
# Accepter la connexion du r?seau local sur le proxy (privoxy)
ACCEPT loc fw tcp 8118
ACCEPT loc fw udp 8118
#
#
########## APACHE ########################
# Accepter les connexions du reseau local vers le firewall : ports 80 (http) et
443 (https) en tcp
# (car serveur apache install? sur le fw)
ACCEPT loc fw tcp 80
ACCEPT loc fw tcp 443
# Accepter les connexions net vers le firewall : ports 80 (http) et 443 (https)
en tcp
# (car serveur apache install? sur le fw)
ACCEPT net fw tcp 80
ACCEPT net fw tcp 443
#
#
########### FTP ##################################################
# Accepter les connexions FTP clientes du firewall vers internet (tcp : port
21):
ACCEPT fw net tcp 21
# Accepter les connexions FTP du reseau local vers le firewall (tcp : port 21):
ACCEPT loc fw tcp 21
# Accepter les connexions FTP du net vers le firewall (tcp : port 21)
ACCEPT net fw tcp 21
########### NTP ##################################################
# Accepter les connexions du fw ? un serveur ntpd (pour synchro Heure interne)
ACCEPT fw net udp 123
########## xMule ###############################
# xMule : cf http://www.xmule.org/forums/index.php?showtopic=128&hl=firewall
ACCEPT net fw tcp 4662
ACCEPT fw net tcp 4662
#ci-dessous, 8 lignes pour "aider" le script de restart de xmule
ACCEPT net fw tcp 4762
ACCEPT fw net tcp 4762
ACCEPT net fw udp 4762
ACCEPT fw net udp 4762
ACCEPT net fw tcp 4672
ACCEPT fw net tcp 4672
ACCEPT net fw udp 4662
ACCEPT fw net udp 4662
#Esp?rons que ?a marche....
ACCEPT net fw udp 4672
ACCEPT fw net udp 4672
ACCEPT fw net tcp 4661
ACCEPT net fw tcp 4665
ACCEPT net fw udp 4665
#ACCEPT fw net udp 4665
ACCEPT net fw tcp 4711
#Methode bourrin pour voir si xMule va enfin supporter Shorewall:
ACCEPT net fw tcp 4000:5000
ACCEPT net fw udp 4000:5000
ACCEPT fw net tcp 4000:5000
ACCEPT fw net udp 4000:5000
########### VNC ###################################################
#Accepter les connexions du reseau local au fw (4 serveurs VNC possibles, des
ports "1" ? "4"):
ACCEPT loc fw tcp 5900:5904
#Accepter les connexions du net au fw (4 serveurs VNC possibles, des ports
"1" ? "4"):
ACCEPT net fw tcp 5900:5904
########### SERVEUR X: #############################################
# Pour lancer des applications sous X ? distance.
# Accepter les connexions X du r?seau local vers le firewall (tcp et udp : ports
6000:6015)
# Pour l''instant (20030626), on acc?de au bureaux(x) par VNC, donc ces
lignes sont comment?es:
# ACCEPT loc fw tcp 6000:6015
# ACCEPT loc fw udp 6000:6015
# Accepter les connexions X du fw vers le r?seau local :
# ACCEPT fw loc tcp 6000:6015
# ACCEPT fw loc udp 6000:6015
########### ICQ: ##################################################
# Accepter les connexions du fw au serveur icq (udp : port 5190) :
# ACCEPT fw net tcp 5190
# Accepter les connexions via les ports tcp : 4200:4202 (d?faut: 4000:4100) :
# ACCEPT net fw related 4200:4202
########### COURRIER et NEWS #######################################
# Accepter les connexions du fw aux serveurs pop3 (tcp : port 110):
# ACCEPT fw net tcp 110
# Accepter les connexions du fw aux serveurs smtp (tcp : port 25):
# ACCEPT fw net tcp 25
# Accepter les connexions aux serveurs nntp (news, tcp : port 119):
# ACCEPT fw net tcp 119
########### IRC ##################################################
# Accepter les connexions du firewall sur IRC (tcp et udp : port 194):
# ACCEPT fw net tcp 6667
# ACCEPT fw net udp 6667
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
On Wed, 9 Jul 2003 figti@netcourrier.com wrote:> I''ve the xMule p2p program running on my firewall, which is also a > gateway for my private network. I''ve set Shorewall according to the > "Two-interface QuickStart Guide" (policy, rules, masq, interfaces, > shorewall.conf files attached) >"P2P" and security are often mutually exclusive.> > I noticed that Shorewall causes xMule to weird behaviors : after 15-20 > minutes, xMule drains 100% CPU and thus "hangs". I found out that > shutting down Shorewall get things back to normal ( xMule gets back to > 5-10% CPU...) Restarting Shorewall causes xMule to get back to 100% CPU > within 10-15 minutes :( To my point of view, it is quite the same as a > "funnel phenomenon", with xMule having large amounts of > incoming/outgoing connections, and Shorewalls struggling under that > heavy load.Well, since once you start Shorewall there is NOT ONE INSTRUCTION OF SHOREWALL CODE RUNNING, the notion that "Shorewall''s struggling" is ridiculous. If *netfilter* has run out of entries it it''s connection tracking table, you will see messages to that effect in your system log. You are probably also seeing Shorewall messages if you would bother to look.> > Besides, I noticed that adding "fw net ACCEPT" in /etc/shorewall/policy > causes xMule to run smoothly for hours (but this way my gateway is not > protected any more...)Well, that policy is included in the sample policy file but is commented out. Uncommenting it is prefectly acceptable if you want to be able to run arbitrary network clients on your firewall. Your gateway is still quite secure with that policy. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
On 9 Jul 2003 at 15:23, figti@netcourrier.com wrote: > Besides, I noticed that adding> "fw net ACCEPT" in /etc/shorewall/policy > causes xMule to run smoothly for hours (but this way my gateway is > not protected any more...)Why do you say that? All that means is the firewall is free to creat outward connections at will. It has no implications for inward connections from the net to your firewall. -- ______________________________________ John Andersen NORCOM / Juneau, Alaska http://www.screenio.com/ (907) 790-3386 ._______________________________________ John S. Andersen NORCOM mailto:JAndersen@norcomsoftware.com Juneau, Alaska http://www.screenio.com/
figti@netcourrier.com
2003-Jul-10 05:25 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
sorry for my (moderate) knowledge of firewalling. Thanks to your answers, I progressed well. It is now 5 full days I''m stuck on this (nice holidays, huh?). Now I''m just wondering about a few things, because I don''t understand every behaviour... OK ; I tried a weird thing. Please be so kind to read my explanation :-) ______________ with the following settings: /etc/shorewall/rules: ACCEPT net fw tcp 4662 ACCEPT net fw udp 4711,4665 /etc/shorewall/policy: fw net ACCEPT Everything is working. -nice- ______________ with the following settings: /etc/shorewall/rules: ACCEPT net fw tcp 1:65000 ACCEPT net fw udp 1:65000 ACCEPT fw net tcp 1:65000 ACCEPT fw net udp 1:65000 /etc/shorewall/policy fw net ACCEPT xMule gets mad and drains 100% CPu within 10 minutes. OK, I understand this is a nonsense. This was JUST for testing. But anyway, with this settings, xMule has problems. I understand my second settings as "having everything opened". So why does xMule acts differently ? Why such a difference between "~everything opened in /etc/shorewall/rules" and "everything opened in /etc/shorewall/policy" ? Many thanx, now I''m beginning to understand :-P ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
On Thu, 2003-07-10 at 07:24, figti@netcourrier.com wrote:> sorry for my (moderate) knowledge of firewalling. Thanks to your > answers, I progressed well. It is now 5 full days I''m stuck on this (nice holidays, huh?). > > Now I''m just wondering about a few things, because I don''t understand > every behaviour... > > OK ; I tried a weird thing. Please be so kind to read my explanation :-) > ______________ > > with the following settings: > /etc/shorewall/rules: > ACCEPT net fw tcp 4662 > ACCEPT net fw udp 4711,4665 > /etc/shorewall/policy: > fw net ACCEPT > > Everything is working. -nice- > ______________ > > with the following settings: > /etc/shorewall/rules: > ACCEPT net fw tcp 1:65000 > ACCEPT net fw udp 1:65000 > ACCEPT fw net tcp 1:65000 > ACCEPT fw net udp 1:65000 > /etc/shorewall/policy > fw net ACCEPT > > xMule gets mad and drains 100% CPu within 10 minutes. > > OK, I understand this is a nonsense. This was JUST for testing. > But anyway, with this settings, xMule has problems. > > I understand my second settings as "having everything opened". So why > does xMule acts differently ? > > Why such a difference between > "~everything opened in /etc/shorewall/rules" and > "everything opened in /etc/shorewall/policy" ? >I don''t know and I don''t personally care. Unless you can produce some *Shorewall-relevant* information such as log messages, I can''t help you. Reporting that "xMule consumes lots of CPU" gives us absolutely no information that is helpful. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
figti@netcourrier.com wrote:> > sorry for my (moderate) knowledge of firewalling. Thanks to your > answers, I progressed well. It is now 5 full days I''m stuck on this (nice holidays, huh?).Actually, you are providing yourself with a massive headache on your very own, trying to install Shorewall with a P2P program. A firewall is a way of blocking out (and not letting out, too) connections to/from your machine (network). P2P wants to do things the other way around... that''s where the problems start...> Now I''m just wondering about a few things, because I don''t understand > every behaviour...The best way to start is to find out how Shorewall, with Netfilter + iptables, handles your traffic to begin with. You will see what it does and doesn''t do.........before you let the P2P program do it''s own stuff.> OK ; I tried a weird thing. Please be so kind to read my explanation :-) > ______________ > > with the following settings: > /etc/shorewall/rules: > ACCEPT net fw tcp 4662 > ACCEPT net fw udp 4711,4665 > /etc/shorewall/policy: > fw net ACCEPTDo you actually know what those ports with their connections will do on your machine?> Everything is working. -nice- > ______________ > > with the following settings: > /etc/shorewall/rules: > ACCEPT net fw tcp 1:65000 > ACCEPT net fw udp 1:65000 > ACCEPT fw net tcp 1:65000 > ACCEPT fw net udp 1:65000 > /etc/shorewall/policy > fw net ACCEPT > > xMule gets mad and drains 100% CPu within 10 minutes.I don''t really understand what 100% CPU drainage has to do with Shorewall, that''s something which is explained at www.xmule.org.> OK, I understand this is a nonsense. This was JUST for testing. > But anyway, with this settings, xMule has problems.> I understand my second settings as "having everything opened". So why > does xMule acts differently ?And this is where your real problems start to show...you seem to be more worried about xMule''s performance than what your Shorewall installation is doing for you..> Why such a difference between > "~everything opened in /etc/shorewall/rules" and > "everything opened in /etc/shorewall/policy" ?The simple explanation is that rules are exceptions to the policies.> Many thanx, now I''m beginning to understand :-PI''ll tell you the truth, I''m not as close as you are. Personally, the only P2P client I''ve ever bothered to handle is WinMX, just portforward tcp 6699 + udp 6257 to an internal machine somewhere and neither ipchains or iptables has any hassles with them! :) Best regards, -- Patrick Benson Stockholm, Sweden
figti@netcourrier.com
2003-Jul-10 07:25 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
Well, xMule took 100% CPU at 13:53:00, besides I experiment the following messages in /var/log/messages: Jul 10 13:51:09 Figuera eric: Shorewall Stopped Jul 10 13:51:19 Figuera eric: Shorewall Started Jul 10 13:57:18 Figuera eric: Shorewall Stopped Jul 10 13:57:30 Figuera eric: Shorewall Started Thus : no messages ! :-( besides I''ve the following in /var/log/syslog: Jul 10 13:51:09 Figuera eric: Shorewall Stopped Jul 10 13:51:19 Figuera eric: Shorewall Started Jul 10 13:53:01 Figuera /USR/SBIN/CRON[7514]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi) Jul 10 13:57:18 Figuera eric: Shorewall Stopped Jul 10 13:57:30 Figuera eric: Shorewall Started nothing much more as you can see... Then... do you have any suggestion, or do you think I should ask anywhere else ? Thanx, Figti ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
On Thu, 2003-07-10 at 09:24, figti@netcourrier.com wrote:> Well, xMule took 100% CPU at 13:53:00, besides I experiment the following messages in /var/log/messages: > > Jul 10 13:51:09 Figuera eric: Shorewall Stopped > Jul 10 13:51:19 Figuera eric: Shorewall Started > Jul 10 13:57:18 Figuera eric: Shorewall Stopped > Jul 10 13:57:30 Figuera eric: Shorewall Started > > Thus : no messages ! :-( >And do you have Shorewall and syslogd configured to log messages to /var/log/messages? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
figti@netcourrier.com
2003-Jul-10 08:28 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
I guess so: /var/log/syslog : Jul 10 13:51:05 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=81.48.35.244 DST=212.195.190.181 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=6398 DF PROTO =TCP SPT=53299 DPT=6346 WINDOW=8192 RES=0x00 SYN URGP=0 Jul 10 13:51:08 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=81.48.35.244 DST=212.195.190.181 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=6602 DF PROTO =TCP SPT=53299 DPT=6346 WINDOW=8192 RES=0x00 SYN URGP=0 Jul 10 13:51:09 Figuera eric: Shorewall Stopped Jul 10 13:51:19 Figuera eric: Shorewall Started Jul 10 13:53:01 Figuera /USR/SBIN/CRON[7514]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi) Jul 10 13:57:18 Figuera eric: Shorewall Stopped Jul 10 13:57:30 Figuera eric: Shorewall Started Jul 10 14:01:37 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=80.131.120.107 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=122 ID=12132 PROT O=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=80.131.120.107 LEN=46 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=UDP SPT=4762 DPT=4672 LEN=26 ] Jul 10 14:01:38 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=217.80.122.124 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=59 ID=17054 DF PR OTO=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=217.80.122.124 LEN=46 TOS=0x00 PREC=0x00 TTL=57 ID=0 FRAG:64 PROTO=UDP ] Jul 10 14:05:48 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=80.136.126.222 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=247 ID=4243 DF PR OTO=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=80.136.126.222 LEN=66 TOS=0x00 PREC=0x00 TTL=57 ID=0 FRAG:64 PROTO=UDP ] /var/log/messages : Jul 10 13:51:03 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=81.48.35.244 DST=212.195.190.181 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=6203 DF PROTO =TCP SPT=53299 DPT=6346 WINDOW=8192 RES=0x00 SYN URGP=0 Jul 10 13:51:05 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=81.48.35.244 DST=212.195.190.181 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=6398 DF PROTO =TCP SPT=53299 DPT=6346 WINDOW=8192 RES=0x00 SYN URGP=0 Jul 10 13:51:08 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=81.48.35.244 DST=212.195.190.181 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=6602 DF PROTO =TCP SPT=53299 DPT=6346 WINDOW=8192 RES=0x00 SYN URGP=0 Jul 10 13:51:09 Figuera eric: Shorewall Stopped Jul 10 13:51:19 Figuera eric: Shorewall Started Jul 10 13:57:18 Figuera eric: Shorewall Stopped Jul 10 13:57:30 Figuera eric: Shorewall Started Jul 10 14:01:37 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=80.131.120.107 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=122 ID=12132 PROT O=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=80.131.120.107 LEN=46 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=UDP SPT=4762 DPT=4672 LEN=26 ] Jul 10 14:01:38 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=217.80.122.124 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=59 ID=17054 DF PR OTO=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=217.80.122.124 LEN=46 TOS=0x00 PREC=0x00 TTL=57 ID=0 FRAG:64 PROTO=UDP ] Jul 10 14:05:48 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=80.136.126.222 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=247 ID=4243 DF PR OTO=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=80.136.126.222 LEN=66 TOS=0x00 PREC=0x00 TTL=57 ID=0 FRAG:64 PROTO=UDP ] Jul 10 14:08:47 Figuera kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=217.136.124.253 DST=212.195.190.181 LEN=56 TOS=0x00 PREC=0x00 TTL=247 ID=63534 DF PROTO=ICMP TYPE=3 CODE=3 [SRC=212.195.190.181 DST=217.136.124.253 LEN=66 TOS=0x00 PREC=0x00 TTL=55 ID=0 FRAG:64 PROTO=UDP ] You see, outside this "time lapse", I indeed have logs of connections... I have them the way it is default-configured, for a two-interfaces gateway... ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
On Thu, 2003-07-10 at 10:27, figti@netcourrier.com wrote:> I guess so: >Then I have no clue why xMule is behaving this way and this is my last post on this thread. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
figti@netcourrier.com
2003-Jul-10 08:43 UTC
[Shorewall-users] Shorewall don''t like xMule ...?
Ok; great :-( ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,15 ? TTC/min)
On Thu, 2003-07-10 at 10:42, figti@netcourrier.com wrote:> Ok; great :-(1. You have a solution that works. 2. A policy of ACCEPT is certainly different from simply allowing all UDP and all TCP ports -- look at /etc/protocols; there are more than just UDP and TCP listed there. 3. I personally think that running a P2P application on a firewall is a great way of asking to be hacked. Once you have a good firewall in place, your greatest vulnerabilities to attack are the services that you expose to the internet and your M$ email clients. 4. As both Patrick Benson and I have pointed out, P2P apps and security are not necessarily compatible; so exposing such a service to the internet from your firewall sure seems unwise to me. 5. I have visited the xMule web site and find that there is an ongoing survey over the question of whether xMule uses too much CPU resource; this makes me think that you aren''t the only person experiencing excessive CPU utilization. The fact that you seem to be able to vary the utilization with different firewall rules is interesting but I would think that it would be of more interest to the xmule developers than it is to me, especially since you apparently aren''t seeing a flood of rejected packets when the xMule CPU utilization is high. 6. There ARE ways (notably strace) to try to find out what xMule is doing when it is using so much CPU. Feel free to play with it. 7. I have limited much time to spend trying to support Shorewall users; I''m not going so spend that time diagnosing performance anomalies in someone else''s program. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thu, 2003-07-10 at 09:37, Tom Eastep wrote:> 7. I have limited much time to spend trying to support Shorewall users; > I''m not going so spend that time diagnosing performance anomalies in > someone else''s program.Hmmm -- I sure made a hack of typing that sentence. Let me try again: I have limited time to spend trying to support Shorewall users; I''m not going to spend that time diagnosing performance anomalies in someone else''s program (especially when those anomalies only show up when using an off-the-wall Shorewall configuration). -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net