extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-01-24 14:39:04 +01:00
Code Issues Packages Projects Releases Wiki Activity

Shorewall-1.4.4a

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@573 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-05-28 19:20:23 +00:00
parent 59660f2576
commit e70a63f267
56 changed files with 22801 additions and 21670 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
Lrp/etc/shorewall/common.def
View File

@ -16,6 +16,7 @@ run_iptables -A common -p icmp -j icmpdef
############################################################################
# NETBIOS chatter
#
run_iptables -A common -p udp --dport 135 -j reject
run_iptables -A common -p udp --dport 137:139 -j reject
run_iptables -A common -p udp --dport 445 -j reject
run_iptables -A common -p tcp --dport 139 -j reject

5
Lrp/etc/shorewall/rules
View File

@ -31,6 +31,11 @@
# the companion ACCEPT rule.
# REDIRECT -- Redirect the request to a local
# port on the firewall.
# REDIRECT-
# -- Advanced users only.
# Like REDIRET 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

27
Lrp/etc/shorewall/shorewall.conf
View File

@ -55,13 +55,30 @@
LOGFILE=/var/log/messages
#
# LOG MARKER
# LOG FORMAT
#
# Used to identify Shorewall log messages. If you are using fireparse, you must
# set this to "fp=Shorewall:". You may not use the ULOG level with fireparse and
# you must not embed white space in the LOGMARKER value.
# 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.
LOGMARKER="Shorewall:"
LOGFORMAT="Shorewall:%s:%s:"
#
# LOG RATE LIMITING

2
Lrp/etc/shorewall/zones
View File

@ -3,7 +3,7 @@
#
# This file determines your network zones. Columns are:
#
# ZONE Short name of the zone
# ZONE Short name of the zone (5 Characters or less in length).
# DISPLAY Display name of the zone
# COMMENTS Comments about the zone
#

18
Lrp/sbin/shorewall
View File

@ -135,7 +135,9 @@ get_config() {
[ -n "$FW" ] || FW=fw
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
[ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}"
[ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:"
}
#
@ -261,9 +263,9 @@ packet_log() # $1 = number of messages
[ -n "$realtail" ] && options="-n$1"
grep "${LOGMARKER}\|ipt_unclean" $LOGFILE | \
grep "${LOGFORMAT}\|ipt_unclean" $LOGFILE | \
sed s/" kernel:"// | \
sed s/" $host $LOGMARKER"/" "/ | \
sed s/" $host $LOGFORMAT"/" "/ | \
sed s/" $host kernel: ipt_unclean: "/" "/ | \
sed 's/MAC=.*SRC=/SRC=/' | \
tail $options
@ -734,27 +736,27 @@ case "$1" in
timeout=30
if [ `grep -c "$LOGMARKER" $LOGFILE ` -gt 0 ] ; then
if [ `grep -c "$LOGFORMAT" $LOGFILE ` -gt 0 ] ; then
echo " HITS IP DATE"
echo " ---- --------------- ------"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn
echo ""
echo " HITS IP PORT"
echo " ---- --------------- -----"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/
t
s/\(.*SRC=\)\(.*\)\( DST=.*\)/\2/' | sort | uniq -c | sort -rn
echo ""
echo " HITS DATE"
echo " ---- ------"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn
echo ""
echo " HITS PORT SERVICE(S)"
echo " ---- ----- ----------"
grep '${LOGMARKER}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
while read count port ; do
# List all services defined for the given port
srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u`

232
Lrp/usr/share/shorewall/firewall
View File

@ -904,6 +904,55 @@ run_user_exit() # $1 = file name
fi
}
#
# Add a logging rule.
#
log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates for the rule
{
local level=$1
local chain=$2
local disposition=$3
local rulenum=
shift;shift;shift
if [ -n "$LOGRULENUMBERS" ]; then
eval rulenum=\$${chain}_logrules
[ -z "$rulenum" ] && rulenum=1
case $level in
ULOG)
eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"'
;;
*)
eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"'
;;
esac
if [ $? -ne 0 ] ; then
[ -z "$stopping" ] && { stop_firewall; exit 2; }
fi
rulenum=$(($rulenum + 1))
eval ${chain}_logrules=$rulenum
else
case $level in
ULOG)
eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"'
;;
*)
eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"'
;;
esac
if [ $? -ne 0 ] ; then
[ -z "$stopping" ] && { stop_firewall; exit 2; }
fi
fi
}
#
# Stop the Firewall
#
@ -1281,18 +1330,6 @@ setup_mac_lists() {
fi
done < $TMP_DIR/maclist
#
# Setup Logging variables
#
if [ -n "$MACLIST_LOG_LEVEL" ]; then
if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then
logpart="-j ULOG $LOGPARMS --ulog-prefix"
else
logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix"
fi
else
logpart=
fi
#
# Must take care of our own broadcasts and multicasts then terminate the verification
# chains
#
@ -1322,8 +1359,9 @@ setup_mac_lists() {
shift
done
[ -n "$logpart" ] && \
run_iptables -A $chain $logpart "${LOGMARKER}$chain:$MACLIST_DISPOSITION:"
if [ -n "$MACLIST_LOG_LEVEL" ]; then
log_rule $MACLIST_LOG_LEVEL $chain $MACLIST_DISPOSITION
fi
run_iptables -A $chain -j $maclist_target
done
@ -1832,6 +1870,13 @@ add_nat_rule() {
fi
for adr in $addr; do
if [ -n "$loglevel" ]; then
ensurenatchain $chain
log_rule $loglevel $chain $logtarget -t nat \
`fix_bang $proto $cli $sports -d $adr $multiport $dports`
loglevel=
fi
addnatrule $chain $proto $cli $sports \
-d $adr $multiport $dports -j $target1
done
@ -2017,21 +2062,11 @@ add_a_rule()
if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then
serv="${serv:+-d $serv}"
if [ -n "$loglevel" ]; then
if [ "$loglevel" = ULOG ]; then
run_iptables2 -A $chain $proto $multiport \
$state $cli $sports $serv $dports -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}$chain:$logtarget:"
else
run_iptables2 -A $chain $proto $multiport \
$state $cli $sports $serv $dports -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}$chain:$logtarget:" \
--log-level $loglevel
fi
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $sports $multiport $state $cli $serv $dports`
fi
run_iptables2 -A $chain $proto $multiport $state $cli $sports \
$serv $dports -j $target
fi
@ -2046,16 +2081,8 @@ add_a_rule()
if [ $command != check ]; then
if [ -n "$loglevel" ]; then
if [ "$loglevel" = ULOG ]; then
run_iptables2 -A $chain $proto $multiport \
$dest_interface $state $cli $sports $dports -j ULOG \
$LOGPARMS --ulog-prefix "${LOGMARKER}$chain:$logtarget:"
else
run_iptables2 -A $chain $proto $multiport \
$dest_interface $state $cli $sports $dports -j LOG \
$LOGPARMS --log-prefix "${LOGMARKER}$chain:$logtarget:" \
--log-level $loglevel
fi
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $multiport $dest_interface $state $cli $sports $dports`
fi
if [ $logtarget != LOG ]; then
@ -2123,6 +2150,17 @@ process_rule() # $1 = target
servers="$FW::$servers"
fi
;;
REDIRECT-)
target=ACCEPT
logtarget=REDIRECT
dnat_only=Yes
address=${address:=all}
if [ "x-" = "x$servers" ]; then
servers=$FW
else
servers="$FW::$servers"
fi
;;
esac
# Parse and validate source
@ -2263,7 +2301,7 @@ process_rules() # $1 = name of rules file
while read xtarget xclients xservers xprotocol xports xcports xaddress; do
case "${xtarget%:*}" in
ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|LOG|CONTINUE)
ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE)
expandv xclients xservers xprotocol xports xcports xaddress
if [ "x$xclients" = xall ]; then
@ -2556,13 +2594,7 @@ policy_rules() # $1 = chain to add rules to
esac
if [ $# -eq 3 -a "x${3}" != "x-" ]; then
if [ "$3" = ULOG ]; then
run_iptables -A $1 -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}${1}:${2}:"
else
run_iptables -A $1 -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}${1}:${2}:" --log-level $3
fi
log_rule $3 $1 $2
fi
[ -n "$target" ] && run_iptables -A $1 -j $target
@ -2882,16 +2914,7 @@ setup_masq()
#
add_blacklist_rule() {
if [ -n "$BLACKLIST_LOGLEVEL" ]; then
if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then
run_iptables2 -A blacklst $source $proto $dport -j \
ULOG $LOGPARMS --ulog-prefix \
"${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:"
else
run_iptables2 -A blacklst $source $proto $dport -j \
LOG $LOGPARMS --log-prefix \
"${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" \
--log-level $BLACKLIST_LOGLEVEL
fi
log_rule $BLACKLIST_LOGLEVEL blacklst $BLACKLIST_DISPOSITION `fix_bang $source $proto $dport`
fi
run_iptables2 -A blacklst $source $proto $dport -j $disposition
@ -3227,13 +3250,7 @@ initialize_netfilter () {
createchain newnotsyn no
run_user_exit newnotsyn
if [ -n "$LOGNEWNOTSYN" ]; then
if [ "$LOGNEWNOTSYN" = ULOG ]; then
run_iptables -A newnotsyn -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}newnotsyn:DROP:"
else
run_iptables -A newnotsyn -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}newnotsyn:DROP:" --log-level $LOGNEWNOTSYN
fi
log_rule $LOGNEWNOTSYN newnotsyn DROP
fi
run_iptables -A newnotsyn -j DROP
@ -3304,14 +3321,7 @@ build_common_chain() {
# Construct zone-independent rules
#
add_common_rules() {
logdisp() # $1 = Chain Name
{
if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then
echo "ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}${1}:DROP:"
else
echo "LOG $LOGPARMS --log-prefix ${LOGMARKER}${1}:DROP: --log-level $RFC1918_LOG_LEVEL"
fi
}
local savelogparms="$LOGPARMS"
#
# Reject Rules
#
@ -3336,16 +3346,16 @@ add_common_rules() {
createchain badpkt no
if [ -n "$LOGUNCLEAN" ]; then
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}badpkt:DROP:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}badpkt:DROP:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi
LOGPARMS="$LOGPARMS --log-ip-options"
run_iptables -A badpkt -p tcp $logoptions --log-tcp-options
run_iptables -A badpkt -p ! tcp $logoptions
log_rule $LOGUNCLEAN badpkt DROP -p ! tcp
LOGPARMS="$LOGPARMS --log-tcp-options"
log_rule $LOGUNCLEAN badpkt DROP -p tcp
LOGPARMS="$savelogparms"
fi
run_iptables -A badpkt -j DROP
@ -3368,16 +3378,15 @@ add_common_rules() {
[ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}logpkt:LOG:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}logpkt:LOG:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi
LOGPARMS="$LOGPARMS --log-ip-options"
run_iptables -A logpkt -p tcp $logoptions --log-tcp-options
run_iptables -A logpkt -p ! tcp $logoptions
log_rule $LOGUNCLEAN logpkt DROP -p ! tcp
LOGPARMS="$LOGPARMS --log-tcp-options"
log_rule $LOGUNCLEAN logpkt DROP -p tcp
LOGPARMS="$savelogparms"
echo "Mangled/Invalid Packet Logging enabled on:"
@ -3414,7 +3423,9 @@ add_common_rules() {
createchain rfc1918 no
createchain logdrop no
run_iptables -A logdrop -j `logdisp rfc1918`
log_rule $RFC1918_LOG_LEVEL logdrop DROP
run_iptables -A logdrop -j DROP
if [ -n "$MANGLE_ENABLED" ]; then
@ -3427,7 +3438,7 @@ add_common_rules() {
#
run_iptables -t mangle -N man1918
run_iptables -t mangle -N logdrop
run_iptables -t mangle -A logdrop -j `logdisp man1918`
log_rule $RFC1918_LOG_LEVEL logdrop DROP -t mangle
run_iptables -t mangle -A logdrop -j DROP
fi
@ -3471,16 +3482,14 @@ add_common_rules() {
if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then
createchain logflags no
if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then
run_iptables -A logflags -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \
--log-tcp-options --log-ip-options
else
run_iptables -A logflags -j LOG $LOGPARMS \
--log-level $TCP_FLAGS_LOG_LEVEL \
--log-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \
--log-tcp-options --log-ip-options
fi
savelogparms="$LOGPARMS"
LOGPARMS="$LOGPARMS --log-ip-options"
log_rule $TCP_FLAGS_LOG_LEVEL logflags $TCP_FLAGS_DISPOSITION
LOGPARMS="$savelogparms"
case $TCP_FLAGS_DISPOSITION in
REJECT)
run_iptables -A logflags -j REJECT --reject-with tcp-reset
@ -4344,7 +4353,8 @@ do_initialize() {
SHARED_DIR=/usr/share/shorewall
FUNCTIONS=
VERSION_FILE=
LOGMARKER=
LOGFORMAT=
LOGRULENUMBERS=
stopping=
have_mutex=
@ -4470,9 +4480,27 @@ do_initialize() {
else
CLEAR_TC=
fi
if [ -n "$LOGFORMAT" ]; then
if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then
LOGRULENUMBERS=Yes
temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
else
temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
fi
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
if [ ${#temp} -gt 29 ]; then
startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\""
fi
else
LOGFORMAT="Shorewall:%s:%s:"
fi
#
# Strip the files that we use often
#

2
Lrp/usr/share/shorewall/version
View File

@ -1 +1 @@
1.4.3
1.4.4a

2
Lrp/var/lib/lrpkg/shorwall.version
View File

@ -1 +1 @@
1.4.3
1.4.4a

14
STABLE/changelog.txt
View File

@ -1,13 +1,13 @@
Changes since 1.4.2
Changes since 1.4.3a
1. The 'add' and 'delete' commands no longer leave behind a temporary
directory in /tmp.
1. Implement REDIRECT-.
2. Added support for 6to4 tunnels.
2. Change LOGMARKER to a printf mask and allow embedded spaces. Renamed
it LOGFORMAT to avoid confusion.
3. Added $LOGMARKER for fireparse support
3. DNAT and REDIRECT logging is moved from the filter table to the nat
table.
4. Return more appropriate ICMP responses if the systems supports them.
4. Don't include log rule number when LOGFORMAT doesn't include "%d".
5. Silently drop UDP 135 in common.def.

200
STABLE/documentation/6to4.htm
View File

@ -1,141 +1,143 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>6to4 Tunnels</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">6to4 Tunnels</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<h3>The 6to4 tunnel documentation is provided by Eric de Thouars.<br>
</h3>
<h3><font color="#ff6633">Warning: </font>The 6to4 tunnel feature of Shorewall
only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security
</h3>
<h3><font color="#ff6633">Warning: </font>The 6to4 tunnel feature of Shorewall
only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security
measures.</h3>
<p>6to4 tunneling with Shorewall can be used to connect your IPv6 network
<p>6to4 tunneling with Shorewall can be used to connect your IPv6 network
to another IPv6 network over an IPv4 infrastructure</p>
<p>More information on Linux and IPv6 can be found in the <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO</a>.
Details on how to setup a 6to4 tunnels are described in the section <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html">Setup
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO</a>. Details
on how to setup a 6to4 tunnels are described in the section <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html">Setup
of 6to4 tunnels</a>.</p>
<h2>Connecting two IPv6 Networks</h2>
<p>Suppose that we have the following situation:</p>
<p align="center"> <img border="0" src="images/TwoIPv6Nets1.png"
width="745" height="427" alt="">
</p>
<p align="left">We want systems in the 2002:100:333::/64 subnetwork to be
able to communicate with the systems in the 2002:488:999::/64 network. This
is accomplished through use of the /etc/shorewall/tunnels file and the "ip"
</p>
<p align="left">We want systems in the 2002:100:333::/64 subnetwork to be
able to communicate with the systems in the 2002:488:999::/64 network. This
is accomplished through use of the /etc/shorewall/tunnels file and the "ip"
utility for network interface and routing configuration.</p>
<p align="left">Unlike GRE and IPIP tunneling, the /etc/shorewall/policy,
/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There
is no need to declare a zone to represent the remote IPv6 network. This
remote network is not visible on IPv4 interfaces and to iptables. All that
is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic.
Separate IPv6 interfaces and ip6tables rules need to be defined to handle
this traffic. </p>
<p align="left">Unlike GRE and IPIP tunneling, the /etc/shorewall/policy,
/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There
is no need to declare a zone to represent the remote IPv6 network. This remote
network is not visible on IPv4 interfaces and to iptables. All that is visible
on the IPv4 level is an IPv4 stream which contains IPv6 traffic. Separate
IPv6 interfaces and ip6tables rules need to be defined to handle this traffic.
</p>
<p align="left">In /etc/shorewall/tunnels on system A, we need the following:</p>
<blockquote>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>6to4</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
<td>6to4</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6
encapsulation protocol (41) will be accepted to/from the remote gateway.</p>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6
encapsulation protocol (41) will be accepted to/from the remote gateway.</p>
<p>Use the following commands to setup system A:</p>
<blockquote>
<blockquote>
<p>&gt;ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2<br>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4<br>
&gt;ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2</p>
</blockquote>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4<br>
&gt;ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2</p>
</blockquote>
<p>Similarly, in /etc/shorewall/tunnels on system B we have:</p>
<blockquote>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>6to4</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
<td>6to4</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>And use the following commands to setup system B:</p>
<blockquote>
<blockquote>
<p>&gt;ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9<br>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4<br>
&gt;ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1</p>
</blockquote>
<p>On both systems, restart Shorewall and issue the configuration commands
as listed above. The systems in both IPv6 subnetworks can now talk to each
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4<br>
&gt;ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1</p>
</blockquote>
<p>On both systems, restart Shorewall and issue the configuration commands
as listed above. The systems in both IPv6 subnetworks can now talk to each
other using IPv6.</p>
<p><font size="2">Updated 5/18/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font size="2">Updated 5/18/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003Thomas M. Eastep.</font></a></p>
<br>
size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.</font></a></p>
<br>
<br>
<br>
</body>
</html>

5589
STABLE/documentation/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

2403
STABLE/documentation/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

365
STABLE/documentation/Install.htm
View File

@ -1,219 +1,220 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Installation</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Installation and
Upgrade</font></h1>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Installation and
Upgrade</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="center"><b>Before upgrading, be sure to review the <a
href="upgrade_issues.htm">Upgrade Issues<br>
</a></b></p>
<div align="left"><b>Before attempting installation, I strongly urge you
to read and print a copy of the <a
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide</a>
for the configuration that most closely matches your own.</b><br>
</div>
</a></b></p>
<div align="left"><b>Before attempting installation, I strongly urge you to
read and print a copy of the <a
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide</a>
for the configuration that most closely matches your own.</b><br>
</div>
<p><font size="4"><b><a href="#Install_RPM">Install using RPM</a><br>
<a href="#Install_Tarball">Install using tarball<br>
</a><a href="#LRP">Install the .lrp</a><br>
<a href="#Upgrade_RPM">Upgrade using RPM</a><br>
<a href="#Upgrade_Tarball">Upgrade using tarball<br>
</a><a href="#LRP_Upgrade">Upgrade the .lrp</a><br>
<a href="#Config_Files">Configuring Shorewall</a><br>
<a href="fallback.htm">Uninstall/Fallback</a></b></font></p>
<a href="#Install_Tarball">Install using tarball<br>
</a><a href="#LRP">Install the .lrp</a><br>
<a href="#Upgrade_RPM">Upgrade using RPM</a><br>
<a href="#Upgrade_Tarball">Upgrade using tarball<br>
</a><a href="#LRP_Upgrade">Upgrade the .lrp</a><br>
<a href="#Config_Files">Configuring Shorewall</a><br>
<a href="fallback.htm">Uninstall/Fallback</a></b></font></p>
<p><a name="Install_RPM"></a>To install Shorewall using the RPM:</p>
<p><b>If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
shell prompt, type "/sbin/iptables --version"), you must upgrade to version
1.2.4 either from the <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update
site</a> or from the <a href="errata.htm">Shorewall Errata page</a> before
attempting to start Shorewall.</b></p>
<p><b>If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
shell prompt, type "/sbin/iptables --version"), you must upgrade to
version 1.2.4 either from the <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update
site</a> or from the <a href="errata.htm">Shorewall Errata page</a>
before attempting to start Shorewall.</b></p>
<ul>
<li>Install the RPM (rpm -ivh &lt;shorewall rpm&gt;).<br>
<br>
<b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -ivh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with the
diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<li>Install the RPM (rpm -ivh &lt;shorewall rpm&gt;).<br>
<br>
<b>Note1: </b>Some SuSE  users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -ivh --nodeps &lt;shorewall rpm&gt;.<br>
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -ivh
--nodeps &lt;shorewall rpm&gt;).<br>
<br>
</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration. <font color="#ff0000"><b>WARNING - YOU CAN
<u>NOT</u> SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND.
SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU
ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM
WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall
clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<li>Start the firewall by typing "shorewall start"</li>
</ul>
<p><a name="Install_Tarball"></a>To install Shorewall using the tarball
and install script: </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in the
directory name as in "shorewall-1.1.10").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using <a href="http://www.suse.com">SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration.</li>
<li>Start the firewall by typing "shorewall start"</li>
<li>If the install script was unable to configure Shorewall to
be started automatically at boot, see <a
href="starting_and_stopping_shorewall.htm">these instructions</a>.</li>
</ul>
<p><a name="LRP"></a>To install my version of Shorewall on a fresh Bering
disk, simply replace the "shorwall.lrp" file on the image with the file
that you downloaded. See the <a href="two-interface.htm">two-interface
QuickStart Guide</a> for information about further steps required.</p>
<p><a name="Upgrade_RPM"></a>If you already have the Shorewall RPM installed
and are upgrading to a new version:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or
and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file. Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for
details.</p>
<ul>
<li>Upgrade the RPM (rpm -Uvh &lt;shorewall rpm file&gt;) <b>Note:
</b>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the "--oldpackage" option to rpm (e.g.,
"rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
<p> <b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with the
diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.x-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;). </p>
</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall (shorewall restart).</li>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -ivh
--nodeps &lt;shorewall rpm&gt;).<br>
<br>
</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration. <font color="#ff0000"><b>WARNING - YOU CAN
<u>NOT</u> SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND.
SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU
ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL
NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall
clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<li>Start the firewall by typing "shorewall start"</li>
</ul>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed
and are upgrading to a new version using the tarball:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file.  Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a>
for details. </p>
<p><a name="Install_Tarball"></a>To install Shorewall using the tarball
and install script: </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in the
directory name as in "shorewall-3.0.1").</li>
<li>If you are using <a
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in
the directory name as in "shorewall-1.1.10").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
<li>If you are using <a href="http://www.suse.com">SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration.</li>
<li>Start the firewall by typing "shorewall start"</li>
<li>If the install script was unable to configure Shorewall to
be started automatically at boot, see <a
href="starting_and_stopping_shorewall.htm">these instructions</a>.</li>
</ul>
<a name="LRP_Upgrade"></a>If you already have a running Bering
installation and wish to upgrade to a later version of Shorewall:<br>
<br>
    <b>UNDER CONSTRUCTION...</b><br>
<h3><a name="Config_Files"></a>Configuring Shorewall</h3>
<p>You will need to edit some or all of the configuration files to match your
setup. In most cases, the <a href="shorewall_quickstart_guide.htm">Shorewall
QuickStart Guides</a> contain all of the information you need.</p>
<p><a name="LRP"></a>To install my version of Shorewall on a fresh Bering
disk, simply replace the "shorwall.lrp" file on the image with the file
that you downloaded. See the <a href="two-interface.htm">two-interface QuickStart
Guide</a> for information about further steps required.</p>
<p><a name="Upgrade_RPM"></a>If you already have the Shorewall RPM installed
and are upgrading to a new version:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
or and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file. Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for
details.</p>
<ul>
<li>Upgrade the RPM (rpm -Uvh &lt;shorewall rpm file&gt;) <b>Note:
</b>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the "--oldpackage" option to rpm
(e.g., "rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
<p> <b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note3: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;). </p>
</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall (shorewall restart).</li>
</ul>
<p><font size="2">Updated 4/8/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed and
are upgrading to a new version using the tarball:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version and
you have entries in the /etc/shorewall/hosts file then please check your
/etc/shorewall/interfaces file to be sure that it contains an entry for
each interface mentioned in the hosts file.  Also, there are certain 1.2
rule forms that are no longer supported under 1.4 (you must use the new
1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a> for
details. </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in
the directory name as in "shorewall-3.0.1").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
</ul>
<a name="LRP_Upgrade"></a>If you already have a running Bering
installation and wish to upgrade to a later version of Shorewall:<br>
<br>
    <b>UNDER CONSTRUCTION...</b><br>
<h3><a name="Config_Files"></a>Configuring Shorewall</h3>
<p>You will need to edit some or all of the configuration files to match
your setup. In most cases, the <a href="shorewall_quickstart_guide.htm">Shorewall
QuickStart Guides</a> contain all of the information you need.</p>
<ul>
</ul>
<p><font size="2">Updated 4/8/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</p>
<br>
</body>
</html>

4521
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

370
STABLE/documentation/errata.htm
View File

@ -1,274 +1,298 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall 1.4 Errata</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Errata/Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p align="center"> <b><u>IMPORTANT</u></b></p>
<ol>
<li>
<li>
<p align="left"> <b><u>I</u>f you use a Windows system to download
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
style="text-decoration: none;"> dos2unix</a></u> after you have moved
it to your Linux system.</b></p>
</li>
<li>
it to your Linux system.</b></p>
</li>
<li>
<p align="left"> <b>If you are installing Shorewall for the first
time and plan to use the .tgz and install.sh script, you can untar
the archive, replace the 'firewall' script in the untarred directory
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /usr/share/shorewall/firewall, you
firewall script in /usr/share/shorewall/firewall, you
may rename the existing file before copying in the new file.</b></p>
</li>
<li>
</li>
<li>
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are
running 1.3.7c.</font></b><br>
</p>
</li>
</p>
</li>
</ol>
<ul>
<li><b><a href="upgrade_issues.htm">Upgrade
Issues</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
<li><b><a href="upgrade_issues.htm">Upgrade
Issues</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
href="errata_3.html">Problems in Version 1.3</a></b></li>
<li> <b><a
<li> <b><a
href="errata_2.htm">Problems in Version 1.2</a></b></li>
<li> <b><font
<li> <b><font
color="#660066"> <a href="errata_1.htm">Problems in Version 1.1</a></font></b></li>
<li> <b><font
<li> <b><font
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a
on RH7.2</a></font></b></li>
<li> <b><a
href="#Debug">Problems with kernels &gt;= 2.4.18 and RedHat
iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with
iptables version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
</ul>
<hr>
<hr>
<h2 align="left"><a name="V1.4"></a>Problems in Version 1.4</h2>
<h3></h3>
<h3>1.4.2</h3>
<h3>1.4.4<br>
</h3>
<ul>
<li> If you have zone names that are 5 characters long, you may experience
problems starting Shorewall because the --log-prefix in a logging rule is
too long. Upgrade to Version 1.4.4a to fix this problem..</li>
</ul>
<h3>1.4.3</h3>
<ul>
<li>When an 'add' or 'delete' command is executed, a temporary directory
created in /tmp is not being removed. This problem may be corrected by installing
<a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.2/firewall"
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
described ablve. <br>
<li>The LOGMARKER variable introduced in version 1.4.3 was intended to
allow integration of Shorewall with Fireparse (http://www.firewparse.com).
Unfortunately, LOGMARKER only solved part of the integration problem. I have
implimented a new LOGFORMAT variable which will replace LOGMARKER which has
completely solved this problem and is currently in production with fireparse
here at shorewall.net. The updated files may be found at <a
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/"
target="_top">ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/</a>.
See the 0README.txt file for details.<br>
</li>
</ul>
<h3>1.4.1a, 1.4.1 and 1.4.0</h3>
<ul>
<li>Some TCP requests are rejected in the 'common' chain with an ICMP
port-unreachable response rather than the more appropriate TCP RST response.
This problem is corrected in <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1a/common.def"
target="_top">this updated common.def file</a> which may be installed in
/etc/shorewall/common.def.<br>
</li>
</ul>
<h3>1.4.1</h3>
<h3>1.4.2</h3>
<ul>
<li>When a "shorewall check" command is executed, each "rule" produces
the harmless additional message:<br>
<br>
     /usr/share/shorewall/firewall: line 2174: [: =: unary operator expected<br>
<br>
You may correct the problem by installing <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1/firewall"
target="_top">this corrected script</a> in /usr/share/shorewall/firewall
as described above.<br>
<li>When an 'add' or 'delete' command is executed, a temporary directory
created in /tmp is not being removed. This problem may be corrected by installing
<a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.2/firewall"
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
described ablve. <br>
</li>
</ul>
<h3>1.4.0</h3>
<h3>1.4.1a, 1.4.1 and 1.4.0</h3>
<ul>
<li>When running under certain shells Shorewall will attempt to create
ECN rules even when /etc/shorewall/ecn is empty. You may either just remove
/etc/shorewall/ecn or you can install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
<li>Some TCP requests are rejected in the 'common' chain with an ICMP
port-unreachable response rather than the more appropriate TCP RST response.
This problem is corrected in <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1a/common.def"
target="_top">this updated common.def file</a> which may be installed in
/etc/shorewall/common.def.<br>
</li>
</ul>
<hr width="100%" size="2">
<h3>1.4.1</h3>
<ul>
<li>When a "shorewall check" command is executed, each "rule" produces
the harmless additional message:<br>
<br>
     /usr/share/shorewall/firewall: line 2174: [: =: unary operator
expected<br>
<br>
You may correct the problem by installing <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1/firewall"
target="_top">this corrected script</a> in /usr/share/shorewall/firewall
as described above.<br>
</li>
</ul>
<h3>1.4.0</h3>
<ul>
<li>When running under certain shells Shorewall will attempt to create
ECN rules even when /etc/shorewall/ecn is empty. You may either just remove
/etc/shorewall/ecn or you can install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
</li>
</ul>
<hr width="100%" size="2">
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
<p align="left">The upgrade issues have moved to <a
href="upgrade_issues.htm">a separate page</a>.</p>
<hr>
<hr>
<h3 align="left"><a name="iptables"></a><font color="#660066"> Problem with
iptables version 1.2.3</font></h3>
<blockquote>
iptables version 1.2.3</font></h3>
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
corrected 1.2.3 rpm which you can download here</a>  and I
corrected 1.2.3 rpm which you can download here</a>  and I
have also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
has released an iptables-1.2.4 RPM of their own which you
can download from<font color="#ff6633"> <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
</font>I have installed this RPM on my firewall and it works
fine.</p>
</font>I have installed this RPM on my firewall and it
works fine.</p>
<p align="left">If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This <a
the patches are available for download. This <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</a>
which corrects a problem with parsing of the --log-level
specification while this <a
which corrects a problem with parsing of the --log-level
specification while this <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</a>
corrects a problem in handling the  TOS target.</p>
corrects a problem in handling the  TOS target.</p>
<p align="left">To install one of the above patches:</p>
<ul>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
</ul>
</blockquote>
</blockquote>
<h3><a name="Debug"></a>Problems with kernels &gt;= 2.4.18 and
RedHat iptables</h3>
<blockquote>
<blockquote>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
<blockquote>
may experience the following:</p>
<blockquote>
<pre># shorewall start<br>Processing /etc/shorewall/shorewall.conf ...<br>Processing /etc/shorewall/params ...<br>Starting Shorewall...<br>Loading Modules...<br>Initializing...<br>Determining Zones...<br>Zones: net<br>Validating interfaces file...<br>Validating hosts file...<br>Determining Hosts in Zones...<br>Net Zone: eth0:0.0.0.0/0<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br></pre>
</blockquote>
</blockquote>
<p>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by
installing <a
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. If you are already running a 1.2.5
version of iptables, you will need to specify the --oldpackage
option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
this iptables RPM</a>. If you are already running a 1.2.5
version of iptables, you will need to specify the --oldpackage
option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
<h3><a name="SuSE"></a>Problems installing/upgrading
RPM on SuSE</h3>
RPM on SuSE</h3>
<p>If you find that rpm complains about a conflict with kernel &lt;=
2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps"
option to rpm.</p>
2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps"
option to rpm.</p>
<p>Installing: rpm -ivh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<p>Upgrading: rpm -Uvh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<h3><a name="Multiport"></a><b>Problems with iptables version 1.2.7 and
MULTIPORT=Yes</b></h3>
MULTIPORT=Yes</b></h3>
<p>The iptables 1.2.7 release of iptables has made an incompatible
change to the syntax used to specify multiport match rules; as
a consequence, if you install iptables 1.2.7 you must be
running Shorewall 1.3.7a or later or:</p>
change to the syntax used to specify multiport match rules; as
a consequence, if you install iptables 1.2.7 you must
be running Shorewall 1.3.7a or later or:</p>
<ul>
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or
</li>
<li>if you are
running Shorewall 1.3.6 you may
install <a
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or
</li>
<li>if you are
running Shorewall 1.3.6 you may
install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
this firewall script</a> in /var/lib/shorewall/firewall
as described above.</li>
as described above.</li>
</ul>
<h3><a name="NAT"></a>Problems with RH Kernel 2.4.18-10 and NAT<br>
</h3>
/etc/shorewall/nat entries of the following form will
result in Shorewall being unable to start:<br>
<br>
</h3>
/etc/shorewall/nat entries of the following form will
result in Shorewall being unable to start:<br>
<br>
<pre>#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL<br>192.0.2.22    eth0    192.168.9.22   yes     yes<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
Error message is:<br>
Error message is:<br>
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
The solution is to put "no" in the LOCAL column. Kernel
support for LOCAL=yes has never worked properly and 2.4.18-10 has
disabled it. The 2.4.19 kernel contains corrected support under a
new kernel configuraiton option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 5/11/2003 - <a href="support.htm">Tom Eastep</a></font>
The solution is to put "no" in the LOCAL column. Kernel
support for LOCAL=yes has never worked properly and 2.4.18-10
has disabled it. The 2.4.19 kernel contains corrected support under
a new kernel configuraiton option; see <a
href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
</p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
</p>
</body>
</html>

BIN
STABLE/documentation/images/Legend.png Executable file
View File

Binary file not shown.

506
STABLE/documentation/seattlefirewall_index.htm
View File

@ -2,107 +2,117 @@
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base
target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%" height="90">
<tbody>
<tr>
<td width="100%" height="90">
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><a
href="http://www.shorewall.net" target="_top"><img border="1"
src="images/shorewall.jpg" width="119" height="38" hspace="4"
alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<small><small><small><small><a
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
</a></i></font><a href="http://www.shorewall.net"
target="_top"><img border="1" src="images/shorewall.jpg" width="119"
height="38" hspace="4" alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<small><small><small><small><a
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
<div align="center">
<div align="center">
<h1><font color="#ffffff"> Shorewall 1.4</font><i><font
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i><a
href="1.3" target="_top"><font color="#ffffff"><br>
</font></a><br>
</font></a><br>
</h1>
</div>
</h1>
</div>
<p><a href="http://www.shorewall.net" target="_top"> </a> </p>
</td>
</tr>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<tbody>
<td width="90%">
<tr>
<td width="90%">
<h2 align="left">What is it?</h2>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This
program is distributed in the hope that
it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.<br>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
Foundation.<br>
<br>
You
should have received a copy of the GNU
General Public License along with
this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the
GNU General Public License along
with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -110,216 +120,288 @@ GNU General Public License</a> as published by the Free Software
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to your
setup. If you want to use the documentation that you find here, it is best
if you uninstall what you have and install a setup that matches the documentation
on this site. See the <a href="two-interface.htm">Two-interface QuickStart
Guide</a> for details.<br>
<h2> Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to
your setup. If you want to use the documentation that you find here, it
is best if you uninstall what you have and install a setup that matches
the documentation on this site. See the <a href="two-interface.htm">Two-interface
QuickStart Guide</a> for details.<br>
<h2> Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>News</h2>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b><img border="0"
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b><br>
</p>
This version primarily corrects the documentation included in the .tgz and
in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are running
iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies
as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3 </b><b><img border="0"
</b></p>
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out
that the code in 1.4.4 restricts the length of short zone names to 4 characters.
I've produced version 1.4.4a that restores the previous 5-character limit
by conditionally omitting the log rule number when the LOGFORMAT doesn't
contain '%d'.
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
    <b>Problems Corrected:<br>
</b><b> </b></p>
I apologize for the rapid-fire releases but since there is a potential
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
it a full release rather than just a bug-fix release. <br>
<br>
<b>    Problems corrected:</b><br>
<blockquote>None.<br>
</blockquote>
<b>    New Features:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to remove
a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets. This
insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a> now supported
in the /etc/shorewall/tunnels file.</li>
<li>Shorewall can now be easily integrated with fireparse (http://www.fireparse.com)
by setting LOGMARKER="fp=" in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
<li>A REDIRECT- rule target has been added. This target behaves
for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
nat table REDIRECT rule is added but not the companion filter table ACCEPT
rule.<br>
<br>
</li>
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
been changed to a 'printf' formatting template which accepts three arguments
(the chain name, logging rule number and the disposition). To use LOGFORMAT
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
set it as:<br>
 <br>
       LOGFORMAT="fp=%s:%d a=%s "<br>
 <br>
<b>CAUTION: </b>/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.<br>
<br>
</li>
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
the logging now takes place in the nat table rather than in the filter table.
This way, only those connections that actually undergo DNAT or redirection
will be logged.<br>
</li>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
</ol>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
</p>
This version primarily corrects the documentation included in the .tgz
and in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are
running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
replies as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to
remove a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets.
This insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a> now
supported in the /etc/shorewall/tunnels file.</li>
<li>You may now change the leading portion of the --log-prefix
used by Shorewall using the LOGMARKER variable in shorewall.conf. By default,
"Shorewall:" is used.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<blockquote>This morning, I gave <a href="GSLUG.htm" target="_top">a
Shorewall presentation to GSLUG</a>. The presentation is
in HTML format but was generated from Microsoft PowerPoint and is best
viewed using Internet Explorer (although Konqueror also seems to work
reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape work
well to view the presentation.<br>
</blockquote>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<blockquote>This morning, I gave <a href="GSLUG.htm" target="_top">a
Shorewall presentation to GSLUG</a>. The presentation is
in HTML format but was generated from Microsoft PowerPoint and is best
viewed using Internet Explorer (although Konqueror also seems to work
reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.<br>
</blockquote>
<p><b></b></p>
<blockquote>
<blockquote>
<ol>
</ol>
</blockquote>
</blockquote>
<p><a href="News.htm">More News</a></p>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</a>Jacques
Nilo and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that
features Shorewall-1.3.14 and Kernel-2.4.20.
You can find their work at: <a
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their
work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
</a></p>
<b>Congratulations to Jacques and Eric on the recent release of Bering
1.2!!! </b><br>
<b>Congratulations to Jacques and Eric on the recent release
of Bering 1.2!!! </b><br>
<h2><a name="Donations"></a>Donations</h2>
</td>
</td>
<td width="88" bgcolor="#4b017c" valign="top" align="center">
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font color="#ffffff"><b>Note:
</b></font></strong><font color="#ffffff">Search is unavailable
Daily 0200-0330 GMT.</font><br>
<strong></strong>
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font color="#ffffff"><b>Note:
</b></font></strong><font color="#ffffff">Search is unavailable
Daily 0200-0330 GMT.</font><br>
<strong></strong>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial"
size="-1"> <input type="text" name="words" size="15"></font><font
size="-1"> </font> <font face="Arial" size="-1"> <input
type="hidden" name="format" value="long"> <input type="hidden"
name="method" value="and"> <input type="hidden" name="config"
value="htdig"> <input type="submit" value="Search"></font> </p>
<font face="Arial"> <input
type="hidden" name="exclude"
<font
face="Arial" size="-1"> <input type="text" name="words"
size="15"></font><font size="-1"> </font> <font face="Arial"
size="-1"> <input type="hidden" name="format" value="long"> <input
type="hidden" name="method" value="and"> <input type="hidden"
name="config" value="htdig"> <input type="submit" value="Search"></font>
</p>
<font
face="Arial"> <input type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font> </form>
<p><font color="#ffffff"><b><a
href="http://lists.shorewall.net/htdig/search.html"><font
color="#ffffff">Extended Search</font></a></b></font></p>
<br>
</td>
<br>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</div>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td
width="100%" style="margin-top: 1px;">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
</tbody>
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 5/19/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

499
STABLE/documentation/shorewall_firewall_structure.htm
View File

@ -1,175 +1,334 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Shorewall Firewall Structure</title>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Firewall Structure</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Firewall Structure</font></h1>
</td>
</tr>
</table>
<p>
Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw"
which refers to the firewall system itself . The /etc/shorewall/zones file
is used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li>
net -- the (untrusted) internet.</li>
<li>
dmz - systems that must be accessible from the internet and from the
local network.  These systems cannot be trusted completely since their servers
may have been compromised through a security exploit.</li>
<li>
loc - systems in your local network(s). These systems must be protected
from the internet and from the DMZ and in some cases, from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall zone</a>.
For ease of description in this documentation, it is assumed
that the firewall zone is named &quot;fw&quot;.</p>
<p>It can't be stressed enough that
with the exception of the firewall zone, Shorewall itself attaches no meaning to
zone names. Zone names are simply labels used to refer to a collection of
network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>For a general picture of how packets traverse a Netfilter firewall, see
<a href="http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES">
http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.</a><br>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Firewall Structure</font></h1>
</td>
</tr>
</tbody>
</table>
<p> Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw" which
refers to the firewall system itself . The /etc/shorewall/zones file is
used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li> net -- the (untrusted) internet.</li>
<li> dmz - systems that must be accessible from the internet
and from the local network.  These systems cannot be trusted completely
since their servers may have been compromised through a security exploit.</li>
<li> loc - systems in your local network(s). These systems
must be protected from the internet and from the DMZ and in some cases,
from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall
zone</a>. For ease of description in this documentation, it is assumed
that the firewall zone is named "fw".</p>
<p>It can't be stressed enough that with the exception of the firewall zone,
Shorewall itself attaches no meaning to zone names. Zone names are simply
labels used to refer to a collection of network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the purpose
of this document, we will consider Netfilter to have three tables:</p>
<ol>
<li>Filter table -- this is the main table for packet filtering and can
be displayed with the command "shorewall show".</li>
<li>Nat table -- used for all forms of Network Address Translation (NAT);
SNAT, DNAT and MASQUERADE.</li>
<li>Mangle table -- used to modify fields in the packet header.<br>
</li>
</ol>
<p>Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
as shown in this table.<br>
</p>
<div align="center">
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">CHAIN<br>
</td>
<td valign="top">Filter<br>
</td>
<td valign="top">Nat<br>
</td>
<td valign="top">Mangle<br>
</td>
</tr>
<tr>
<td valign="top">PREROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">INPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">OUTPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">FORWARD<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">POSTROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
</tbody>
</table>
</div>
<p>Shorewall doesn't create rules in all of the builtin chains. In the large
diagram below are boxes such as  shown below.  This box represents in INPUT
chain and shows that packets first flow through the INPUT chain in the Mangle
table followed by the INPUT chain in the Filter table. The parentheses around
"Mangle" indicate that while the packets will flow through the INPUT chain
in the Mangle table, Shorewall does not create any rules in that chain.<br>
</p>
<div align="center"><img src="images/Legend.png" alt="(Box Legend)"
width="145" height="97" align="middle">
<br>
Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing &quot;shorewall show
mangle&quot;). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b>&nbsp; which will drop
the packet if its destination IP address is reserved (as specified in the
/etc/shorewall/rfc1918 file). Next the packet passes through the<b> pretos</b>
chain to set its TOS field as specified in the /etc/shorewall/tos file.
Finally, if traffic control/shaping is being used, the packet is sent through
the<b> tcpre</b> chain to be marked for later use in policy routing or traffic
control.</p>
<p>Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table by
typing &quot;shorewall show nat&quot;). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on the
setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on then
packets will ender a chain called <i>interface_</i>in where <i>interface</i> is
the name of the interface on which the packet entered. Here it's destination IP
is compared to each of the <i>EXTERNAL</i> IP addresses from /etc/shorewall/nat
that correspond to this interface; if there is a match, DNAT is applied and the
packet header is modified to the IP in the <i>INTERNAL</i> column of the nat
file record. If the destination address doesn't match any of the rules in the
<i>interface_</i>in chain then the packet enters a chain called <i>sourcezone</i>_dnat
</div>
<p></p>
<p>Here is a picture of how packets traverse the various chains and tables
in Netfilter. In that diagram, "Local Process" refers to a process running
on the Firewall itself (in the 'fw' zone).</p>
<div align="center"><img src="images/Netfilter.png"
alt="Netfilter Flow Diagram" width="541" height="767">
</div>
<p><br>
<br>
In the text that follows, the paragraph numbers correspond to the box number
in the diagram above.<br>
</p>
<ol>
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing "shorewall show
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b> chain which will
drop the packet if its destination IP address is reserved (as specified
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
file. Finally, if traffic control/shaping is being used, the packet is sent
through the<b> tcpre</b> chain to be marked for later use in policy routing
or traffic control.<br>
<br>
Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
by typing "shorewall show nat"). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on
the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
on then packets will ender a chain called<b> <i>interface_</i>in</b> where
<i>interface</i> is the name of the interface on which the packet entered.
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP
addresses from /etc/shorewall/nat that correspond to this interface; if
there is a match, DNAT is applied and the packet header is modified to
the IP in the <i>INTERNAL</i> column of the nat file record. If the destination
address doesn't match any of the rules in the <b><i>interface_</i>in</b>
chain then the packet enters a chain called <b><i>sourcezone</i>_dnat</b>
where <i>sourcezone</i> is the source zone of the packet. There it is compared
for a match against each of the DNAT records in the rules file that specify <i>
sourcezone </i>as the source zone. If a match is found, the destination IP
address (and possibly the destination port) is modified based on the rule
matched. If NAT_BEFORE_RULES is off, then the order of traversal of the <i>
interface_</i>in and <i>sourcezone</i>_dnat is reversed.</p>
<p>
Traffic is next sent to an<i> input </i>chain in the mail Netfilter table
(called 'filter'). If the traffic is destined for the
firewall itself, the name of the input chain is formed by appending &quot;_in&quot; to
the interface name. So traffic on eth0 destined for the firewall will enter a
chain called <i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending &quot;_fwd&quot; to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character (&quot;+&quot;) in
/etc/shorewall/interfaces, share input chains. if <i>ppp+ </i>appears in
/etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will share
the input chains <i>ppp_in</i> and <i>ppp_fwd</i>. In other words, &quot;+&quot; is
deleted from the name before forming the input chain names.</p>
<p>
While the use of input chains may seem wasteful in simple environments, in
complex setups it substantially reduces the number of rules that each packet
must traverse.&nbsp; </p>
<p>
Traffic directed from a zone to the firewall itself is sent through a
chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">
 </font></p>
<p>
Traffic being forwarded between two zones (or from one interface to a
zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to
as the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p>
For each record in the /etc/shorewall/policy file, a chain is created. Policies
in that file are expressed in terms of a source zone and destination zone
where these zones may be a zone defined in /etc/shorewall/zones, "fw" or
"all". Policies specifying the pseudo-zone "all" matches all defined zones
and "fw". These chains are referred to as <i>Policy Chains.</i> Notice that
for an ordered pair of zones (za,zb), the canonical chain (za2zb) may also
be the policy chain for the pair or the policy chain may be a different
chain (za2all, for example). Packets from one zone to another will traverse
chains as follows:</p>
<ol>
<li>
If the canonical chain exists, packets first traverse that chain.</li>
<li>
If the canonical chain and policy chain are different and the packet
does not match a rule in the canonical chain, it then is sent to the
policy chain.</li>
<li>
If the canonical chain does not exist, packets are sent immediately
to the policy chain.</li>
</ol>
<p>
The canonical chain from zone za to zone zb will be created only if there
are exception rules defined in /etc/shorewall/rules for packets going from
za to zb.</p>
<p>
Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
<ol>
<li>
Identify the client's zone.</li>
<li>
Identify the server's zone.</li>
<li>
If the POLICY from the client's zone to the server's zone is what you
want for this client/server pair, you need do nothing further.</li>
<li>
If the POLICY is not what you want, then you must add a rule. That rule
is expressed in terms of the client's zone and the server's zone.</li>
</ol>
<p>
Just because connections of a particular type are allowed between zone A
and the firewall and are also allowed between the firewall and zone B <font color="#ff6633"><b><u>
DOES NOT mean that these connections are allowed between zone A and zone
B</u></b></font>. It rather means that you can have a proxy running on
the firewall that accepts a connection from zone A and then establishes
its own separate connection from the firewall to zone B.</p>
<p>
If you adopt the default policy of ACCEPT from the local zone to the internet
zone and you are having problems connecting from a local client to an internet
server, <font color="#ff6633"><b><u> adding a rule won't help</u></b></font>
(see point 3 above).</p>
<p><font size="2">Last modified 8/22/2002 - <a href="support.htm">Tom
Eastep</a></font><p><font face="Trebuchet MS"><a href="copyright.htm">
<font size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></body></html>
for a match against each of the DNAT records in the rules file that specify
<i> sourcezone </i>as the source zone. If a match is found, the destination
IP address (and possibly the destination port) is modified based on the
rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of
the <b><i> interface_</i>in</b> and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
<br>
</li>
<li>Depending on whether the packet is destined for the firewall itself
or for another system, it follows either the left or the right path. Traffic
going to the firewall goes through chains called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain. Traffic next passes the the
INPUT chain in the filter table where it is broken out based on the interface
on which the packet arrived; packets from interface <i>interface</i> are routed
to chain <b><i>interface</i>_in</b>. For example, packets arriving through
eth0 are passed to the chain <b>eth0_in.</b></li>
<ol>
<li>The first rule in <b><i>interface</i>_in</b> jumps to the chain
named <b>dynamic</b> which matches the source IP in the packet against all
of the addresses that have been blacklisted using <a
href="blacklisting_support.htm#Dynamic">dynamic blacklisting</a>.</li>
<li>If the the interface has the <b>norfc1918</b> option then the packet
is sent down the <b>rfc1918 </b>which checks the source address against those
listed in /etc/shorewall/rfc1918 and treats the packet according to the first
match in that file (if any).</li>
<li>If the interface has the  <b>dhcp </b>option, UDP packets to ports
67 and 68 are accepted.</li>
<li><br>
</li>
</ol>
<li>Traffic is next sent to an<i> input </i>chain in the mail Netfilter
table (called 'filter'). If the traffic is destined for the firewall itself,
the name of the input chain is formed by appending "_in" to the interface
name. So traffic on eth0 destined for the firewall will enter a chain called
<i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending "_fwd" to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces,
share input chains. if <i>ppp+ </i>appears in /etc/shorewall/interfaces
then all PPP interfaces (ppp0, ppp1, ...) will share the input chains <i>ppp_in</i>
and <i>ppp_fwd</i>. In other words, "+" is deleted from the name before
forming the input chain names.</li>
</ol>
<p> While the use of input chains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </p>
<p> Traffic directed from a zone to the firewall itself is sent through
a chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">  </font></p>
<p> Traffic being forwarded between two zones (or from one interface to
a zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to as
the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p> For each record in the /etc/shorewall/policy file, a chain is created.
Policies in that file are expressed in terms of a source zone and destination
zone where these zones may be a zone defined in /etc/shorewall/zones,
"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
zones and "fw". These chains are referred to as <i>Policy Chains.</i> Notice
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
may also be the policy chain for the pair or the policy chain may be a
different chain (za2all, for example). Packets from one zone to another
will traverse chains as follows:</p>
<ol>
<li> If the canonical chain exists, packets first traverse that
chain.</li>
<li> If the canonical chain and policy chain are different and
the packet does not match a rule in the canonical chain, it then is sent
to the policy chain.</li>
<li> If the canonical chain does not exist, packets are sent
immediately to the policy chain.</li>
</ol>
<p> The canonical chain from zone za to zone zb will be created only if
there are exception rules defined in /etc/shorewall/rules for packets going
from za to zb.</p>
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
<ol>
<li> Identify the client's zone.</li>
<li> Identify the server's zone.</li>
<li> If the POLICY from the client's zone to the server's zone
is what you want for this client/server pair, you need do nothing further.</li>
<li> If the POLICY is not what you want, then you must add a
rule. That rule is expressed in terms of the client's zone and the
server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed between zone
A and the firewall and are also allowed between the firewall and zone
B <font color="#ff6633"><b><u> DOES NOT mean that these connections
are allowed between zone A and zone B</u></b></font>. It rather means
that you can have a proxy running on the firewall that accepts a connection
from zone A and then establishes its own separate connection from the firewall
to zone B.</p>
<p> If you adopt the default policy of ACCEPT from the local zone to the
internet zone and you are having problems connecting from a local client
to an internet server, <font color="#ff6633"><b><u> adding a rule won't
help</u></b></font> (see point 3 above).</p>
<p><font size="2">Last modified 5/22/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
</body>
</html>

523
STABLE/documentation/sourceforge_index.htm
View File

@ -2,335 +2,420 @@
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<base target="_self">
<base
target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tr>
<tbody>
<td width="100%" height="90">
<tr>
<td width="100%" height="90">
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall 1.4 -
<font size="4">"<i>iptables made easy"</i></font></font><br>
<a target="_top" href="1.3/index.html"><font
</a></i></font><font color="#ffffff">Shorewall 1.4
- <font size="4">"<i>iptables made
easy"</i></font></font><br>
<a target="_top" href="1.3/index.html"><font
color="#ffffff"> </font></a><a target="_top"
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small><br>
</small></small></small></font></a>
</small></small></small></font></a>
</h1>
</td>
</tr>
</h1>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<tbody>
<td width="90%">
<tr>
<td width="90%">
<h2 align="left">What is it?</h2>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a>
(iptables) based firewall that can be used on
a dedicated firewall system, a multi-function gateway/router/server
or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the GNU
General Public License along with
this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a>
(iptables) based firewall that can be used
on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the
GNU General Public License along
with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to your
setup. If you want to use the documentation that you find here, it is best
if you uninstall what you have and install a setup that matches the documentation
on this site. See the <a href="two-interface.htm">Two-interface QuickStart
Guide</a> for details.<br>
If so, almost <b>NOTHING </b>on this site will apply directly to
your setup. If you want to use the documentation that you find here, it
is best if you uninstall what you have and install a setup that matches
the documentation on this site. See the <a href="two-interface.htm">Two-interface
QuickStart Guide</a> for details.<br>
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2><b>News</b></h2>
<b> </b>
<b> </b>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b><img border="0"
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b><br>
</p>
This version primarily corrects the documentation included in the .tgz and
in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are running
iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies
as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3 </b><b><img border="0"
</b></p>
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out
that the code in 1.4.4 restricts the length of short zone names to 4 characters.
I've produced version 1.4.4a that restores the previous 5-character limit
by conditionally omitting the log rule number when the LOGFORMAT doesn't
contain '%d'.
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
</b><b> </b></p>
I apologize for the rapid-fire releases but since there is a potential
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
it a full release rather than just a bug-fix release. <br>
<br>
<b>    Problems corrected:</b><br>
<blockquote>None.<br>
</blockquote>
<b>    New Features:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to remove
a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets. This
insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
<li>A REDIRECT- rule target has been added. This target behaves
for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
nat table REDIRECT rule is added but not the companion filter table ACCEPT
rule.<br>
<br>
</li>
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
been changed to a 'printf' formatting template which accepts three arguments
(the chain name, logging rule number and the disposition). To use LOGFORMAT
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
set it as:<br>
 <br>
       LOGFORMAT="fp=%s:%d a=%s "<br>
 <br>
<b>CAUTION: </b>/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.<br>
<br>
</li>
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
the logging now takes place in the nat table rather than in the filter table.
This way, only those connections that actually undergo DNAT or redirection
will be logged.</li>
</ol>
    <b>New Features:<br>
</b>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b>
</b><br>
</p>
This version primarily corrects the documentation included in the .tgz
and in the .rpm. In addition: <br>
<ol>
<li><a href="6to4.htm"> </a><a href="6to4.htm">IPV6-IPV4 (6to4)
tunnels </a>are now supported in the /etc/shorewall/tunnels file.</li>
<li>Shorewall can now be easily integrated with fireparse (<a
href="http://www.fireparse.com">http://www.fireparse.com</a>) by setting
LOGMARKER="fp=" in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
<li>(This change is in 1.4.3 but is not documented) If you are
running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
replies as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to
remove a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets.
This insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b>  </b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li><a href="6to4.htm"> </a><a href="6to4.htm">IPV6-IPV4 (6to4)
tunnels </a>are now supported in the /etc/shorewall/tunnels file.</li>
<li value="2">You may now change the leading portion of the
--log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf.
By default, "Shorewall:" is used.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b>  </b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<blockquote> This morning, I gave <a href="GSLUG.htm"
target="_top">a Shorewall presentation to GSLUG</a>. The presentation
is in HTML format but was generated from Microsoft PowerPoint and
is best viewed using Internet Explorer (although Konqueror also seems
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.</blockquote>
target="_top">a Shorewall presentation to GSLUG</a>. The presentation
is in HTML format but was generated from Microsoft PowerPoint and
is best viewed using Internet Explorer (although Konqueror also seems
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.</blockquote>
<p><b></b></p>
<blockquote>
<blockquote>
<ol>
</ol>
</blockquote>
</blockquote>
<p><a href="file:///Z:/Shorewall-docs/News.htm"></a></p>
<b> </b>
<b> </b>
<p><b><a href="News.htm">More News</a></b></p>
<b> </b>
<b> </b>
<h2><b> </b></h2>
<b> </b>
<b> </b>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work
at: <a href="http://leaf.sourceforge.net/devel/jnilo">
http://leaf.sourceforge.net/devel/jnilo</a></p>
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and Eric on
the recent release of Bering 1.2!!! </b><br>
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.2!!! </b><br>
<h1 align="center"><b><a href="http://www.sf.net"><img
align="left" alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
</a></b></h1>
<b> </b>
</a></b></h1>
<b> </b>
<h4><b> </b></h4>
<b> </b>
<b> </b>
<h2><b>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </b></h2>
<b> </b>
<b> </b>
<h2><b><a name="Donations"></a>Donations</b></h2>
<b> </b></td>
<b> </b></td>
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
action="http://lists.shorewall.net/cgi-bin/htsearch">
<p><strong><br>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
 </p>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
 </p>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial" size="-1"> <input
<font face="Arial" size="-1"> <input
type="text" name="words" size="15"></font><font size="-1"> </font><font
face="Arial" size="-1"> <input type="hidden" name="format"
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
type="submit" value="Search"></font> </p>
<font face="Arial"> <input type="hidden"
name="exclude" value="[http://lists.shorewall.net/pipermail/*]">
</font> </form>
<font face="Arial"> <input
type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font>
</form>
<p><font color="#ffffff"><b> <a
href="http://lists.shorewall.net/htdig/search.html"> <font
color="#ffffff">Extended Search</font></a></b></font></p>
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small></small></small></small></font></a><br>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</div>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 5/19/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

475
STABLE/documentation/support.htm
View File

@ -1,79 +1,81 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Support Guide</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td
width="100%">
<tbody>
<tr>
<td
width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Support Guide<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
</td>
</tr>
</tbody>
</font></h1>
</td>
</tr>
</tbody>
</table>
<h2>Before Reporting a Problem or Asking a Question<br>
</h2>
There are
a number of sources of Shorewall information. Please try these before
you post.
</h2>
There
are a number of sources of Shorewall information. Please try these
before you post.
<ul>
<li>Shorewall versions earlier
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has solutions
to more than 20 common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has
solutions to more than 20 common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li> The Site
and Mailing List Archives search facility can locate documents
and posts about similar problems: </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li> The Site
and Mailing List Archives search facility can locate documents
and posts about similar problems: </li>
</ul>
<h2>Site and Mailing List Archive Search</h2>
<blockquote>
<blockquote>
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
<select name="method">
<option value="and">All </option>
<option value="or">Any </option>
<option value="boolean">Boolean </option>
</select>
Format:
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -82,238 +84,233 @@ list have answers directly accessible from the <a
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font><input type="hidden" name="config"
</font><input type="hidden" name="config"
value="htdig"><input type="hidden" name="restrict" value=""><font
size="-1"> Include Mailing List Archives:
size="-1"> Include Mailing List Archives:
<select size="1" name="exclude">
<option value="">Yes</option>
<option value="[http://lists.shorewall.net/pipermail/.*]">No</option>
</select>
</font><br>
Search: <input type="text" size="30" name="words"
</font><br>
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"><br>
</form>
</blockquote>
</form>
</blockquote>
<h2>Problem Reporting Guidelines<br>
</h2>
</h2>
<ul>
<li>Please remember we only know what
is posted in your message. Do not leave out any information
that appears to be correct, or was mentioned in a previous
post. There have been countless posts by people who were sure
that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're
asking for <strong>free</strong> technical support.
Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. <em>Exact quoting </em> of
error messages, log entries, command output, and other output is better
than a paraphrase or summary.<br>
<br>
</li>
<li>
Please don't describe your environment and then ask us
to send you custom configuration files. We're here
to answer your questions but we can't do your
job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
<li>Please remember we only know what
is posted in your message. Do not leave out any information
that appears to be correct, or was mentioned in a previous post.
There have been countless posts by people who were sure that
some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is
lacking.<br>
<br>
</li>
<li>Please keep in mind that you're
asking for <strong>free</strong> technical support. Any
help we offer is an act of generosity, not an obligation. Try
to make it easy for us to help you. Follow good, courteous practices
in writing and formatting your e-mail. Provide details that we need
if you expect good answers. <em>Exact quoting </em> of error messages,
log entries, command output, and other output is better than a paraphrase
or summary.<br>
<br>
</li>
<li>
Please don't describe your environment and then ask us
to send you custom configuration files. We're here
to answer your questions but we can't do your
job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall
you are running.<br>
<br>
<b><font color="#009900">shorewall
version</font><br>
</b> <br>
</li>
<li>the exact version of Shorewall
you are running.<br>
<br>
<b><font color="#009900">shorewall
version</font><br>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version you are
running<br>
<br>
<font color="#009900"><b>uname -a<br>
<br>
</b></font></li>
<li>the exact kernel version you
are running<br>
<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr
show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip route
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr
show<br>
<br>
</b></font></li>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip route
show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
</ul>
</ul>
<ul>
<ul>
<li><font color="#ff0000"><u><i><big><b>If you are having connection
problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><br>
<br>
2. Try the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall status
<li><font color="#ff0000"><u><i><big><b>If you are having connection
problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><br>
<br>
2. Try the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall status
&gt; /tmp/status.txt</font></b><br>
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart
Guides, please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the
Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart
Guides, please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
</ul>
<li>As
a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
<li>As
a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages ("<b><font
color="#009900">/sbin/shorewall show log</font></b>") when
you exercise the function that is giving you problems? If so,
include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration
files (especially the /etc/shorewall/hosts file if
you have modified that file) that you think are relevant.
If you include /etc/shorewall/rules, please include /etc/shorewall/policy
as well (rules are meaningless unless one also knows the policies).<br>
<br>
</li>
<li>If an error occurs when you try to "<font
color="#009900"><b>shorewall start</b></font>", include a trace
(See the <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so don't
post GIFs of your network layout, etc. to
the Mailing List -- your post will be rejected.</b></li>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages ("<b><font
color="#009900">/sbin/shorewall show log</font></b>") when
you exercise the function that is giving you problems? If
so, include the message(s) in your post along with a copy of your
/etc/shorewall/interfaces file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration
files (especially the /etc/shorewall/hosts file
if you have modified that file) that you think are
relevant. If you include /etc/shorewall/rules, please include
/etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies).<br>
<br>
</li>
<li>If an error occurs when you try to "<font
color="#009900"><b>shorewall start</b></font>", include a trace
(See the <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so don't
post GIFs of your network layout, etc.
to the Mailing List -- your post will be rejected.</b></li>
</ul>
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<em>Olszewski</em> found at <a
href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
</blockquote>
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> A growing number of MTAs serving list subscribers are
rejecting all HTML traffic. At least one MTA has gone so far as to
blacklist shorewall.net "for continuous abuse" because it has been
my policy to allow HTML in list posts!!<br>
<br>
I think that blocking all HTML is
a Draconian way to control spam and that the ultimate losers
here are not the spammers but the list subscribers whose MTAs
are bouncing all shorewall.net mail. As one list subscriber wrote
to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML based
e-mail". Nevertheless, to allow subscribers to receive list posts
as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts.<br>
</blockquote>
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist
shorewall.net "for continuous abuse" because it has been my policy
to allow HTML in list posts!!<br>
<br>
I think that blocking all HTML is
a Draconian way to control spam and that the ultimate losers
here are not the spammers but the list subscribers whose
MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML
based e-mail". Nevertheless, to allow subscribers to receive
list posts as must as possible, I have now configured the list
server at shorewall.net to strip all HTML from outgoing posts.<br>
</blockquote>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote> <b>If you have a <u>quick</u> question about
capabilities or where to find something, you may use the</b> <a
href="http://www.developercube.com/forum/index.php?c=8">Shorewall Support
Forum</a>. <u><b>DO NOT POST THE OUTPUT OF "shorewall status" TO THE FORUM;
I WON'T LOOK AT IT.</b></u> <b>If you need to supply "shorewall status"
output, use the appropriate mailing list below.</b><br>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft
Multi Network Firewall (MNF) and you have not purchased an
MNF license from MandrakeSoft then you can post non MNF-specific
Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list.</b><br>
style="font-weight: 400;">please post your question or problem
to the <a
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft
Multi Network Firewall (MNF) and you have not purchased
an MNF license from MandrakeSoft then you can post non MNF-specific
Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> .</p>
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> .</p>
<p> To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
<p>For information on other Shorewall mailing lists, go to <a
href="http://lists.shorewall.net">http://lists.shorewall.net</a><br>
</p>
<p align="left"><font size="2">Last Updated 5/12/2003 - Tom Eastep</font></p>
</p>
<p align="left"><font size="2">Last Updated 5/19/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
<br>
</p>
</body>
</html>

1984
STABLE/documentation/three-interface.htm
View File

File diff suppressed because it is too large Load Diff

2009
STABLE/documentation/three-interface_fr.html
View File

File diff suppressed because it is too large Load Diff

1643
STABLE/documentation/two-interface.htm
View File

File diff suppressed because it is too large Load Diff

814
STABLE/documentation/upgrade_issues.htm
View File

@ -1,421 +1,441 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Upgrade Issues</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p>For upgrade instructions see the <a
href="Install.htm">Install/Upgrade page</a>.<br>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you are
currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be
a host address) accessed through a particular interface.<br>
</p>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you
are currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
be a host address) accessed through a particular interface.<br>
</p>
<p>Examples:<br>
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</p>
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</p>
<h3> </h3>
<h3>Version &gt;= 1.4.2</h3>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current documentation
and change your configuration accordingly.<br>
<h3>Version &gt;= 1.4.1</h3>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the same
zone is accepted by default. Previously, traffic from a zone to itself was
treated just like any other traffic; any matching rules were applied followed
by enforcement of the appropriate policy. With 1.4.1 and later versions,
unless you have explicit rules for traffic from Z to Z or you have an explicit
Z to Z policy (where "Z" is some zone) then traffic between the groups
in zone Z will be accepted. If you do have one or more explicit rules for
Z to Z or if you have an explicit Z to Z policy then the behavior is as it
was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
traffic between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that has
"all" in either the SOURCE or DESTINATION column) to prevent traffic between
two interfaces to a zone Z and you have no rules for Z-&gt;Z then you should
add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
<ul>
<li> Sometimes, you want two separate zones on one interface but you
don't want Shorewall to set up any infrastructure to handle traffic between
them. </li>
</ul>
<blockquote>Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to be
involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to handle
traffic between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is asymetric
routing where only the traffic on one direction flows through the firewall
and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then I recommend that you upgrade to Version
1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the iproute
package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package iproute2
which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm
-Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when there
are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts
file has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is
no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped by
default; there is no need for your own /etc/shorewall/common file simply
to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file
have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include
it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does
not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
     Beginning in version 1.3.14, Shorewall treats entries in
<a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently. The
change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet
on the interface (as shown by "ip addr show <i>interface</i>") and would
masquerade traffic from that subnet. Any other subnets that routed through
eth1 needed their own entry in /etc/shorewall/masq to be masqueraded
or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
routing table to determine ALL subnets routed through the named interface.
Traffic originating in ANY of those subnets is masqueraded or has SNAT
applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq with
an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- Suppose that your current config is as
follows:<br>
   <br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is like
this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254 <br> [root@gateway test]#</pre>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf then
OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the old
handling indefinitely so I urge current users to migrate to using the
new handling as soon as possible. See the <a href="ping.html">'Ping' handling
documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading
to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this file
if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall &gt;= 1.3.3</b></h3>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering floppy
with the later one. If you did not
obtain the later version from Jacques's site, see additional instructions
below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget
to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need
to add the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can be
rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks
to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 4/13/2003 - <a href="support.htm">Tom
Eastep</a></font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<h3>Version &gt;= 1.4.4</h3>
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
you must set the new LOGFORMAT variable appropriately and remove your setting
of LOGMARKER<br>
<br>
<h3>Version 1.4.4<br>
</h3>
If you have zone names that are 5 characters long, you may experience problems
starting Shorewall because the --log-prefix in a logging rule is too long.
Upgrade to Version 1.4.4a to fix this problem..<br>
<h3>Version &gt;= 1.4.2</h3>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current
documentation and change your configuration accordingly.<br>
<h3>Version &gt;= 1.4.1</h3>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the
same zone is accepted by default. Previously, traffic from a zone to itself
was treated just like any other traffic; any matching rules were applied
followed by enforcement of the appropriate policy. With 1.4.1 and later
versions, unless you have explicit rules for traffic from Z to Z or you
have an explicit Z to Z policy (where "Z" is some zone) then traffic between
the groups in zone Z will be accepted. If you do have one or more explicit
rules for Z to Z or if you have an explicit Z to Z policy then the behavior
is as it was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
traffic between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent traffic
between two interfaces to a zone Z and you have no rules for Z-&gt;Z then
you should add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
<ul>
<li> Sometimes, you want two separate zones on one interface but
you don't want Shorewall to set up any infrastructure to handle traffic
between them. </li>
</ul>
<blockquote>Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to
be involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to handle
traffic between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is
asymetric routing where only the traffic on one direction flows through
the firewall and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then I recommend that you upgrade to Version
1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the
iproute package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm
-Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when there
are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and
hosts file has been eliminated; use entries in the routestopped file
instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
is no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped
by default; there is no need for your own /etc/shorewall/common file
simply to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version'
file have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you
include it from /etc/shorewall/icmpdef, you will need to modify that
file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same
interface that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to
or from the destination zone. An explicit policy names both zones and
does not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same
then the rule must be explicit - it must name the zone in both the SOURCE
and DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
     Beginning in version 1.3.14, Shorewall treats entries
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST
subnet on the interface (as shown by "ip addr show <i>interface</i>")
and would masquerade traffic from that subnet. Any other subnets that
routed through eth1 needed their own entry in /etc/shorewall/masq to
be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the
firewall's routing table to determine ALL subnets routed through
the named interface. Traffic originating in ANY of those subnets
is masqueraded or has SNAT applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq
with an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- Suppose that your current config is
as follows:<br>
   <br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is
like this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254 <br> [root@gateway test]#</pre>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to
be used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting
the old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now
upgrading to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this
file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall &gt;= 1.3.3</b></h3>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering
floppy with the later one. If you did
not obtain the later version from Jacques's site, see additional
instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not
forget to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a
href="two-interface.htm">instructions for setting up a two-interface
firewall</a> plus you also need to add the following two Bering-specific
rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept
Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
</p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
</body>
</html>

2
STABLE/fallback.sh
View File

@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
VERSION=1.4.3a
VERSION=1.4.4a
usage() # $1 = exit status
{

232
STABLE/firewall
View File

@ -904,6 +904,55 @@ run_user_exit() # $1 = file name
fi
}
#
# Add a logging rule.
#
log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates for the rule
{
local level=$1
local chain=$2
local disposition=$3
local rulenum=
shift;shift;shift
if [ -n "$LOGRULENUMBERS" ]; then
eval rulenum=\$${chain}_logrules
[ -z "$rulenum" ] && rulenum=1
case $level in
ULOG)
eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"'
;;
*)
eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"'
;;
esac
if [ $? -ne 0 ] ; then
[ -z "$stopping" ] && { stop_firewall; exit 2; }
fi
rulenum=$(($rulenum + 1))
eval ${chain}_logrules=$rulenum
else
case $level in
ULOG)
eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"'
;;
*)
eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"'
;;
esac
if [ $? -ne 0 ] ; then
[ -z "$stopping" ] && { stop_firewall; exit 2; }
fi
fi
}
#
# Stop the Firewall
#
@ -1281,18 +1330,6 @@ setup_mac_lists() {
fi
done < $TMP_DIR/maclist
#
# Setup Logging variables
#
if [ -n "$MACLIST_LOG_LEVEL" ]; then
if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then
logpart="-j ULOG $LOGPARMS --ulog-prefix"
else
logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix"
fi
else
logpart=
fi
#
# Must take care of our own broadcasts and multicasts then terminate the verification
# chains
#
@ -1322,8 +1359,9 @@ setup_mac_lists() {
shift
done
[ -n "$logpart" ] && \
run_iptables -A $chain $logpart "${LOGMARKER}$chain:$MACLIST_DISPOSITION:"
if [ -n "$MACLIST_LOG_LEVEL" ]; then
log_rule $MACLIST_LOG_LEVEL $chain $MACLIST_DISPOSITION
fi
run_iptables -A $chain -j $maclist_target
done
@ -1832,6 +1870,13 @@ add_nat_rule() {
fi
for adr in $addr; do
if [ -n "$loglevel" ]; then
ensurenatchain $chain
log_rule $loglevel $chain $logtarget -t nat \
`fix_bang $proto $cli $sports -d $adr $multiport $dports`
loglevel=
fi
addnatrule $chain $proto $cli $sports \
-d $adr $multiport $dports -j $target1
done
@ -2017,21 +2062,11 @@ add_a_rule()
if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then
serv="${serv:+-d $serv}"
if [ -n "$loglevel" ]; then
if [ "$loglevel" = ULOG ]; then
run_iptables2 -A $chain $proto $multiport \
$state $cli $sports $serv $dports -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}$chain:$logtarget:"
else
run_iptables2 -A $chain $proto $multiport \
$state $cli $sports $serv $dports -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}$chain:$logtarget:" \
--log-level $loglevel
fi
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $sports $multiport $state $cli $serv $dports`
fi
run_iptables2 -A $chain $proto $multiport $state $cli $sports \
$serv $dports -j $target
fi
@ -2046,16 +2081,8 @@ add_a_rule()
if [ $command != check ]; then
if [ -n "$loglevel" ]; then
if [ "$loglevel" = ULOG ]; then
run_iptables2 -A $chain $proto $multiport \
$dest_interface $state $cli $sports $dports -j ULOG \
$LOGPARMS --ulog-prefix "${LOGMARKER}$chain:$logtarget:"
else
run_iptables2 -A $chain $proto $multiport \
$dest_interface $state $cli $sports $dports -j LOG \
$LOGPARMS --log-prefix "${LOGMARKER}$chain:$logtarget:" \
--log-level $loglevel
fi
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $multiport $dest_interface $state $cli $sports $dports`
fi
if [ $logtarget != LOG ]; then
@ -2123,6 +2150,17 @@ process_rule() # $1 = target
servers="$FW::$servers"
fi
;;
REDIRECT-)
target=ACCEPT
logtarget=REDIRECT
dnat_only=Yes
address=${address:=all}
if [ "x-" = "x$servers" ]; then
servers=$FW
else
servers="$FW::$servers"
fi
;;
esac
# Parse and validate source
@ -2263,7 +2301,7 @@ process_rules() # $1 = name of rules file
while read xtarget xclients xservers xprotocol xports xcports xaddress; do
case "${xtarget%:*}" in
ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|LOG|CONTINUE)
ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE)
expandv xclients xservers xprotocol xports xcports xaddress
if [ "x$xclients" = xall ]; then
@ -2556,13 +2594,7 @@ policy_rules() # $1 = chain to add rules to
esac
if [ $# -eq 3 -a "x${3}" != "x-" ]; then
if [ "$3" = ULOG ]; then
run_iptables -A $1 -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}${1}:${2}:"
else
run_iptables -A $1 -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}${1}:${2}:" --log-level $3
fi
log_rule $3 $1 $2
fi
[ -n "$target" ] && run_iptables -A $1 -j $target
@ -2882,16 +2914,7 @@ setup_masq()
#
add_blacklist_rule() {
if [ -n "$BLACKLIST_LOGLEVEL" ]; then
if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then
run_iptables2 -A blacklst $source $proto $dport -j \
ULOG $LOGPARMS --ulog-prefix \
"${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:"
else
run_iptables2 -A blacklst $source $proto $dport -j \
LOG $LOGPARMS --log-prefix \
"${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" \
--log-level $BLACKLIST_LOGLEVEL
fi
log_rule $BLACKLIST_LOGLEVEL blacklst $BLACKLIST_DISPOSITION `fix_bang $source $proto $dport`
fi
run_iptables2 -A blacklst $source $proto $dport -j $disposition
@ -3227,13 +3250,7 @@ initialize_netfilter () {
createchain newnotsyn no
run_user_exit newnotsyn
if [ -n "$LOGNEWNOTSYN" ]; then
if [ "$LOGNEWNOTSYN" = ULOG ]; then
run_iptables -A newnotsyn -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}newnotsyn:DROP:"
else
run_iptables -A newnotsyn -j LOG $LOGPARMS \
--log-prefix "${LOGMARKER}newnotsyn:DROP:" --log-level $LOGNEWNOTSYN
fi
log_rule $LOGNEWNOTSYN newnotsyn DROP
fi
run_iptables -A newnotsyn -j DROP
@ -3304,14 +3321,7 @@ build_common_chain() {
# Construct zone-independent rules
#
add_common_rules() {
logdisp() # $1 = Chain Name
{
if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then
echo "ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}${1}:DROP:"
else
echo "LOG $LOGPARMS --log-prefix ${LOGMARKER}${1}:DROP: --log-level $RFC1918_LOG_LEVEL"
fi
}
local savelogparms="$LOGPARMS"
#
# Reject Rules
#
@ -3336,16 +3346,16 @@ add_common_rules() {
createchain badpkt no
if [ -n "$LOGUNCLEAN" ]; then
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}badpkt:DROP:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}badpkt:DROP:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi
LOGPARMS="$LOGPARMS --log-ip-options"
run_iptables -A badpkt -p tcp $logoptions --log-tcp-options
run_iptables -A badpkt -p ! tcp $logoptions
log_rule $LOGUNCLEAN badpkt DROP -p ! tcp
LOGPARMS="$LOGPARMS --log-tcp-options"
log_rule $LOGUNCLEAN badpkt DROP -p tcp
LOGPARMS="$savelogparms"
fi
run_iptables -A badpkt -j DROP
@ -3368,16 +3378,15 @@ add_common_rules() {
[ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}logpkt:LOG:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}logpkt:LOG:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi
LOGPARMS="$LOGPARMS --log-ip-options"
run_iptables -A logpkt -p tcp $logoptions --log-tcp-options
run_iptables -A logpkt -p ! tcp $logoptions
log_rule $LOGUNCLEAN logpkt DROP -p ! tcp
LOGPARMS="$LOGPARMS --log-tcp-options"
log_rule $LOGUNCLEAN logpkt DROP -p tcp
LOGPARMS="$savelogparms"
echo "Mangled/Invalid Packet Logging enabled on:"
@ -3414,7 +3423,9 @@ add_common_rules() {
createchain rfc1918 no
createchain logdrop no
run_iptables -A logdrop -j `logdisp rfc1918`
log_rule $RFC1918_LOG_LEVEL logdrop DROP
run_iptables -A logdrop -j DROP
if [ -n "$MANGLE_ENABLED" ]; then
@ -3427,7 +3438,7 @@ add_common_rules() {
#
run_iptables -t mangle -N man1918
run_iptables -t mangle -N logdrop
run_iptables -t mangle -A logdrop -j `logdisp man1918`
log_rule $RFC1918_LOG_LEVEL logdrop DROP -t mangle
run_iptables -t mangle -A logdrop -j DROP
fi
@ -3471,16 +3482,14 @@ add_common_rules() {
if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then
createchain logflags no
if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then
run_iptables -A logflags -j ULOG $LOGPARMS \
--ulog-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \
--log-tcp-options --log-ip-options
else
run_iptables -A logflags -j LOG $LOGPARMS \
--log-level $TCP_FLAGS_LOG_LEVEL \
--log-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \
--log-tcp-options --log-ip-options
fi
savelogparms="$LOGPARMS"
LOGPARMS="$LOGPARMS --log-ip-options"
log_rule $TCP_FLAGS_LOG_LEVEL logflags $TCP_FLAGS_DISPOSITION
LOGPARMS="$savelogparms"
case $TCP_FLAGS_DISPOSITION in
REJECT)
run_iptables -A logflags -j REJECT --reject-with tcp-reset
@ -4344,7 +4353,8 @@ do_initialize() {
SHARED_DIR=/usr/share/shorewall
FUNCTIONS=
VERSION_FILE=
LOGMARKER=
LOGFORMAT=
LOGRULENUMBERS=
stopping=
have_mutex=
@ -4470,9 +4480,27 @@ do_initialize() {
else
CLEAR_TC=
fi
if [ -n "$LOGFORMAT" ]; then
if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then
LOGRULENUMBERS=Yes
temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
else
temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
fi
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
if [ ${#temp} -gt 29 ]; then
startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\""
fi
else
LOGFORMAT="Shorewall:%s:%s:"
fi
#
# Strip the files that we use often
#

2
STABLE/install.sh
View File

@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
VERSION=1.4.3a
VERSION=1.4.4a
usage() # $1 = exit status
{

46
STABLE/releasenotes.txt
View File

@ -2,36 +2,32 @@ This is a minor release of Shorewall.
Problems Corrected:
1) There were several cases where Shorewall would fail to remove a
temporary directory from /tmp. These cases have been corrected.
2) The rules for allowing all traffic via the loopback interface have
been moved to before the rule that drops status=INVALID
packets. This insures that all loopback traffic is allowed even if
Netfilter connection tracking is confused.
New Features:
1) IPV6-IPV4 (6to4) tunnels are now supported in the
/etc/shorewall/tunnels file.
1) A REDIRECT- rule target has been added. This target behaves for
REDIRECT in the same was as DNAT- does for DNAT in that the
Netfilter nat table REDIRECT rule is added but not the companion
filter table ACCEPT rule.
2) Shorewall can now be easily integrated with fireparse
(http://www.fireparse.com) by setting LOGMARKER="fp=" in
/etc/shorewall/shorewall.conf. Note: You may not use ULOG
with fireparse unless you modify fireparse.
2) The LOGMARKER variable has been renamed LOGFORMAT and has been
changed to a 'printf' formatting template which accepts three
arguments (the chain name, logging rule number (optional) and the
disposition). The logging rule number is included if the LOGFORMAT
value contains '%d'. For example, to use LOGFORMAT with fireparse,
set it as:
3) If you are running iptables 1.2.7a and kernel 2.4.20, then
Shorewall will return reject replies as follows:
LOGFORMAT="fp=%s:%d a=%s "
a) tcp - RST
b) udp - ICMP port unreachable
c) icmp - ICMP host unreachable
d) Otherwise - ICMP host prohibited
If you are running earlier software, Shorewall will follow it's
traditional convention:
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.
a) tcp - RST
b) Otherwise - ICMP port unreachable
3) When logging is specified on a DNAT[-] or REDIRECT[-] rule, the
logging now takes place in the nat table rather than in the filter
table. This way, only those connections that actually undergo DNAT
or redirection will be logged.
4) UDP Port 135 is now silently dropped in the common.def chain.

18
STABLE/shorewall
View File

@ -135,7 +135,9 @@ get_config() {
[ -n "$FW" ] || FW=fw
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
[ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}"
[ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:"
}
#
@ -261,9 +263,9 @@ packet_log() # $1 = number of messages
[ -n "$realtail" ] && options="-n$1"
grep "${LOGMARKER}\|ipt_unclean" $LOGFILE | \
grep "${LOGFORMAT}\|ipt_unclean" $LOGFILE | \
sed s/" kernel:"// | \
sed s/" $host $LOGMARKER"/" "/ | \
sed s/" $host $LOGFORMAT"/" "/ | \
sed s/" $host kernel: ipt_unclean: "/" "/ | \
sed 's/MAC=.*SRC=/SRC=/' | \
tail $options
@ -734,27 +736,27 @@ case "$1" in
timeout=30
if [ `grep -c "$LOGMARKER" $LOGFILE ` -gt 0 ] ; then
if [ `grep -c "$LOGFORMAT" $LOGFILE ` -gt 0 ] ; then
echo " HITS IP DATE"
echo " ---- --------------- ------"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn
echo ""
echo " HITS IP PORT"
echo " ---- --------------- -----"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/
t
s/\(.*SRC=\)\(.*\)\( DST=.*\)/\2/' | sort | uniq -c | sort -rn
echo ""
echo " HITS DATE"
echo " ---- ------"
grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn
grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn
echo ""
echo " HITS PORT SERVICE(S)"
echo " ---- ----- ----------"
grep '${LOGMARKER}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
while read count port ; do
# List all services defined for the given port
srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u`

27
STABLE/shorewall.conf
View File

@ -55,13 +55,30 @@
LOGFILE=/var/log/messages
#
# LOG MARKER
# LOG FORMAT
#
# Used to identify Shorewall log messages. If you are using fireparse, you must
# set this to "fp=Shorewall:". You may not use the ULOG level with fireparse and
# you must not embed white space in the LOGMARKER value.
# 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.
LOGMARKER="Shorewall:"
LOGFORMAT="Shorewall:%s:%s:"
#
# LOG RATE LIMITING

6
STABLE/shorewall.spec
View File

@ -1,5 +1,5 @@
%define name shorewall
%define version 1.4.3a
%define version 1.4.4a
%define release 1
%define prefix /usr
@ -105,6 +105,10 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Tue May 27 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.4a-1
* Thu May 22 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.4-1
* Mon May 19 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.3a-1
* Sun May 18 2003 Tom Eastep <tom@shorewall.net>

2
STABLE/uninstall.sh
View File

@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
VERSION=1.4.3a
VERSION=1.4.4a
usage() # $1 = exit status
{

2
STABLE/zones
View File

@ -3,7 +3,7 @@
#
# This file determines your network zones. Columns are:
#
# ZONE Short name of the zone
# ZONE Short name of the zone (5 Characters or less in length).
# DISPLAY Display name of the zone
# COMMENTS Comments about the zone
#

200
Shorewall-docs/6to4.htm
View File

@ -1,141 +1,143 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>6to4 Tunnels</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">6to4 Tunnels</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<h3>The 6to4 tunnel documentation is provided by Eric de Thouars.<br>
</h3>
<h3><font color="#ff6633">Warning: </font>The 6to4 tunnel feature of Shorewall
only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security
</h3>
<h3><font color="#ff6633">Warning: </font>The 6to4 tunnel feature of Shorewall
only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security
measures.</h3>
<p>6to4 tunneling with Shorewall can be used to connect your IPv6 network
<p>6to4 tunneling with Shorewall can be used to connect your IPv6 network
to another IPv6 network over an IPv4 infrastructure</p>
<p>More information on Linux and IPv6 can be found in the <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO</a>.
Details on how to setup a 6to4 tunnels are described in the section <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html">Setup
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO</a>. Details
on how to setup a 6to4 tunnels are described in the section <a
href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html">Setup
of 6to4 tunnels</a>.</p>
<h2>Connecting two IPv6 Networks</h2>
<p>Suppose that we have the following situation:</p>
<p align="center"> <img border="0" src="images/TwoIPv6Nets1.png"
width="745" height="427" alt="">
</p>
<p align="left">We want systems in the 2002:100:333::/64 subnetwork to be
able to communicate with the systems in the 2002:488:999::/64 network. This
is accomplished through use of the /etc/shorewall/tunnels file and the "ip"
</p>
<p align="left">We want systems in the 2002:100:333::/64 subnetwork to be
able to communicate with the systems in the 2002:488:999::/64 network. This
is accomplished through use of the /etc/shorewall/tunnels file and the "ip"
utility for network interface and routing configuration.</p>
<p align="left">Unlike GRE and IPIP tunneling, the /etc/shorewall/policy,
/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There
is no need to declare a zone to represent the remote IPv6 network. This
remote network is not visible on IPv4 interfaces and to iptables. All that
is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic.
Separate IPv6 interfaces and ip6tables rules need to be defined to handle
this traffic. </p>
<p align="left">Unlike GRE and IPIP tunneling, the /etc/shorewall/policy,
/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There
is no need to declare a zone to represent the remote IPv6 network. This remote
network is not visible on IPv4 interfaces and to iptables. All that is visible
on the IPv4 level is an IPv4 stream which contains IPv6 traffic. Separate
IPv6 interfaces and ip6tables rules need to be defined to handle this traffic.
</p>
<p align="left">In /etc/shorewall/tunnels on system A, we need the following:</p>
<blockquote>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>6to4</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
<td>6to4</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6
encapsulation protocol (41) will be accepted to/from the remote gateway.</p>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6
encapsulation protocol (41) will be accepted to/from the remote gateway.</p>
<p>Use the following commands to setup system A:</p>
<blockquote>
<blockquote>
<p>&gt;ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2<br>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4<br>
&gt;ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2</p>
</blockquote>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4<br>
&gt;ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2</p>
</blockquote>
<p>Similarly, in /etc/shorewall/tunnels on system B we have:</p>
<blockquote>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>6to4</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
<td>6to4</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>And use the following commands to setup system B:</p>
<blockquote>
<blockquote>
<p>&gt;ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9<br>
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4<br>
&gt;ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1</p>
</blockquote>
<p>On both systems, restart Shorewall and issue the configuration commands
as listed above. The systems in both IPv6 subnetworks can now talk to each
&gt;ip link set dev tun6to4 up<br>
&gt;ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4<br>
&gt;ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1</p>
</blockquote>
<p>On both systems, restart Shorewall and issue the configuration commands
as listed above. The systems in both IPv6 subnetworks can now talk to each
other using IPv6.</p>
<p><font size="2">Updated 5/18/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font size="2">Updated 5/18/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003Thomas M. Eastep.</font></a></p>
<br>
size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.</font></a></p>
<br>
<br>
<br>
</body>
</html>

5589
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

2403
Shorewall-docs/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

365
Shorewall-docs/Install.htm
View File

@ -1,219 +1,220 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Installation</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Installation and
Upgrade</font></h1>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Installation and
Upgrade</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="center"><b>Before upgrading, be sure to review the <a
href="upgrade_issues.htm">Upgrade Issues<br>
</a></b></p>
<div align="left"><b>Before attempting installation, I strongly urge you
to read and print a copy of the <a
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide</a>
for the configuration that most closely matches your own.</b><br>
</div>
</a></b></p>
<div align="left"><b>Before attempting installation, I strongly urge you to
read and print a copy of the <a
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide</a>
for the configuration that most closely matches your own.</b><br>
</div>
<p><font size="4"><b><a href="#Install_RPM">Install using RPM</a><br>
<a href="#Install_Tarball">Install using tarball<br>
</a><a href="#LRP">Install the .lrp</a><br>
<a href="#Upgrade_RPM">Upgrade using RPM</a><br>
<a href="#Upgrade_Tarball">Upgrade using tarball<br>
</a><a href="#LRP_Upgrade">Upgrade the .lrp</a><br>
<a href="#Config_Files">Configuring Shorewall</a><br>
<a href="fallback.htm">Uninstall/Fallback</a></b></font></p>
<a href="#Install_Tarball">Install using tarball<br>
</a><a href="#LRP">Install the .lrp</a><br>
<a href="#Upgrade_RPM">Upgrade using RPM</a><br>
<a href="#Upgrade_Tarball">Upgrade using tarball<br>
</a><a href="#LRP_Upgrade">Upgrade the .lrp</a><br>
<a href="#Config_Files">Configuring Shorewall</a><br>
<a href="fallback.htm">Uninstall/Fallback</a></b></font></p>
<p><a name="Install_RPM"></a>To install Shorewall using the RPM:</p>
<p><b>If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
shell prompt, type "/sbin/iptables --version"), you must upgrade to version
1.2.4 either from the <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update
site</a> or from the <a href="errata.htm">Shorewall Errata page</a> before
attempting to start Shorewall.</b></p>
<p><b>If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
shell prompt, type "/sbin/iptables --version"), you must upgrade to
version 1.2.4 either from the <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update
site</a> or from the <a href="errata.htm">Shorewall Errata page</a>
before attempting to start Shorewall.</b></p>
<ul>
<li>Install the RPM (rpm -ivh &lt;shorewall rpm&gt;).<br>
<br>
<b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -ivh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with the
diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<li>Install the RPM (rpm -ivh &lt;shorewall rpm&gt;).<br>
<br>
<b>Note1: </b>Some SuSE  users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -ivh --nodeps &lt;shorewall rpm&gt;.<br>
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -ivh
--nodeps &lt;shorewall rpm&gt;).<br>
<br>
</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration. <font color="#ff0000"><b>WARNING - YOU CAN
<u>NOT</u> SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND.
SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU
ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM
WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall
clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<li>Start the firewall by typing "shorewall start"</li>
</ul>
<p><a name="Install_Tarball"></a>To install Shorewall using the tarball
and install script: </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in the
directory name as in "shorewall-1.1.10").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using <a href="http://www.suse.com">SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration.</li>
<li>Start the firewall by typing "shorewall start"</li>
<li>If the install script was unable to configure Shorewall to
be started automatically at boot, see <a
href="starting_and_stopping_shorewall.htm">these instructions</a>.</li>
</ul>
<p><a name="LRP"></a>To install my version of Shorewall on a fresh Bering
disk, simply replace the "shorwall.lrp" file on the image with the file
that you downloaded. See the <a href="two-interface.htm">two-interface
QuickStart Guide</a> for information about further steps required.</p>
<p><a name="Upgrade_RPM"></a>If you already have the Shorewall RPM installed
and are upgrading to a new version:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or
and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file. Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for
details.</p>
<ul>
<li>Upgrade the RPM (rpm -Uvh &lt;shorewall rpm file&gt;) <b>Note:
</b>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the "--oldpackage" option to rpm (e.g.,
"rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
<p> <b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with the
diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.x-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;). </p>
</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall (shorewall restart).</li>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -ivh
--nodeps &lt;shorewall rpm&gt;).<br>
<br>
</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration. <font color="#ff0000"><b>WARNING - YOU CAN
<u>NOT</u> SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND.
SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU
ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL
NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall
clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<li>Start the firewall by typing "shorewall start"</li>
</ul>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed
and are upgrading to a new version using the tarball:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file.  Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a>
for details. </p>
<p><a name="Install_Tarball"></a>To install Shorewall using the tarball
and install script: </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in the
directory name as in "shorewall-3.0.1").</li>
<li>If you are using <a
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in
the directory name as in "shorewall-1.1.10").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
<li>If you are using <a href="http://www.suse.com">SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
<li>Edit the <a href="#Config_Files"> configuration files</a>
to match your configuration.</li>
<li>Start the firewall by typing "shorewall start"</li>
<li>If the install script was unable to configure Shorewall to
be started automatically at boot, see <a
href="starting_and_stopping_shorewall.htm">these instructions</a>.</li>
</ul>
<a name="LRP_Upgrade"></a>If you already have a running Bering
installation and wish to upgrade to a later version of Shorewall:<br>
<br>
    <b>UNDER CONSTRUCTION...</b><br>
<h3><a name="Config_Files"></a>Configuring Shorewall</h3>
<p>You will need to edit some or all of the configuration files to match your
setup. In most cases, the <a href="shorewall_quickstart_guide.htm">Shorewall
QuickStart Guides</a> contain all of the information you need.</p>
<p><a name="LRP"></a>To install my version of Shorewall on a fresh Bering
disk, simply replace the "shorwall.lrp" file on the image with the file
that you downloaded. See the <a href="two-interface.htm">two-interface QuickStart
Guide</a> for information about further steps required.</p>
<p><a name="Upgrade_RPM"></a>If you already have the Shorewall RPM installed
and are upgrading to a new version:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
or and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file. Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for
details.</p>
<ul>
<li>Upgrade the RPM (rpm -Uvh &lt;shorewall rpm file&gt;) <b>Note:
</b>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the "--oldpackage" option to rpm
(e.g., "rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
<p> <b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note3: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;). </p>
</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall (shorewall restart).</li>
</ul>
<p><font size="2">Updated 4/8/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed and
are upgrading to a new version using the tarball:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version and
you have entries in the /etc/shorewall/hosts file then please check your
/etc/shorewall/interfaces file to be sure that it contains an entry for
each interface mentioned in the hosts file.  Also, there are certain 1.2
rule forms that are no longer supported under 1.4 (you must use the new
1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a> for
details. </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
<li>cd to the shorewall directory (the version is encoded in
the directory name as in "shorewall-3.0.1").</li>
<li>If you are using <a
href="http://www.caldera.com/openstore/openlinux/">Caldera</a>, <a
href="http://www.redhat.com">RedHat</a>, <a
href="http://www.linux-mandrake.com">Mandrake</a>, <a
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your
distribution installs init scripts and type "./install.sh
&lt;init script directory&gt;</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
</ul>
<a name="LRP_Upgrade"></a>If you already have a running Bering
installation and wish to upgrade to a later version of Shorewall:<br>
<br>
    <b>UNDER CONSTRUCTION...</b><br>
<h3><a name="Config_Files"></a>Configuring Shorewall</h3>
<p>You will need to edit some or all of the configuration files to match
your setup. In most cases, the <a href="shorewall_quickstart_guide.htm">Shorewall
QuickStart Guides</a> contain all of the information you need.</p>
<ul>
</ul>
<p><font size="2">Updated 4/8/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</p>
<br>
</body>
</html>

4521
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

370
Shorewall-docs/errata.htm
View File

@ -1,274 +1,298 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall 1.4 Errata</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Errata/Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p align="center"> <b><u>IMPORTANT</u></b></p>
<ol>
<li>
<li>
<p align="left"> <b><u>I</u>f you use a Windows system to download
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
style="text-decoration: none;"> dos2unix</a></u> after you have moved
it to your Linux system.</b></p>
</li>
<li>
it to your Linux system.</b></p>
</li>
<li>
<p align="left"> <b>If you are installing Shorewall for the first
time and plan to use the .tgz and install.sh script, you can untar
the archive, replace the 'firewall' script in the untarred directory
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /usr/share/shorewall/firewall, you
firewall script in /usr/share/shorewall/firewall, you
may rename the existing file before copying in the new file.</b></p>
</li>
<li>
</li>
<li>
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are
running 1.3.7c.</font></b><br>
</p>
</li>
</p>
</li>
</ol>
<ul>
<li><b><a href="upgrade_issues.htm">Upgrade
Issues</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
<li><b><a href="upgrade_issues.htm">Upgrade
Issues</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
href="errata_3.html">Problems in Version 1.3</a></b></li>
<li> <b><a
<li> <b><a
href="errata_2.htm">Problems in Version 1.2</a></b></li>
<li> <b><font
<li> <b><font
color="#660066"> <a href="errata_1.htm">Problems in Version 1.1</a></font></b></li>
<li> <b><font
<li> <b><font
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a
on RH7.2</a></font></b></li>
<li> <b><a
href="#Debug">Problems with kernels &gt;= 2.4.18 and RedHat
iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with
iptables version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
</ul>
<hr>
<hr>
<h2 align="left"><a name="V1.4"></a>Problems in Version 1.4</h2>
<h3></h3>
<h3>1.4.2</h3>
<h3>1.4.4<br>
</h3>
<ul>
<li> If you have zone names that are 5 characters long, you may experience
problems starting Shorewall because the --log-prefix in a logging rule is
too long. Upgrade to Version 1.4.4a to fix this problem..</li>
</ul>
<h3>1.4.3</h3>
<ul>
<li>When an 'add' or 'delete' command is executed, a temporary directory
created in /tmp is not being removed. This problem may be corrected by installing
<a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.2/firewall"
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
described ablve. <br>
<li>The LOGMARKER variable introduced in version 1.4.3 was intended to
allow integration of Shorewall with Fireparse (http://www.firewparse.com).
Unfortunately, LOGMARKER only solved part of the integration problem. I have
implimented a new LOGFORMAT variable which will replace LOGMARKER which has
completely solved this problem and is currently in production with fireparse
here at shorewall.net. The updated files may be found at <a
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/"
target="_top">ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/</a>.
See the 0README.txt file for details.<br>
</li>
</ul>
<h3>1.4.1a, 1.4.1 and 1.4.0</h3>
<ul>
<li>Some TCP requests are rejected in the 'common' chain with an ICMP
port-unreachable response rather than the more appropriate TCP RST response.
This problem is corrected in <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1a/common.def"
target="_top">this updated common.def file</a> which may be installed in
/etc/shorewall/common.def.<br>
</li>
</ul>
<h3>1.4.1</h3>
<h3>1.4.2</h3>
<ul>
<li>When a "shorewall check" command is executed, each "rule" produces
the harmless additional message:<br>
<br>
     /usr/share/shorewall/firewall: line 2174: [: =: unary operator expected<br>
<br>
You may correct the problem by installing <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1/firewall"
target="_top">this corrected script</a> in /usr/share/shorewall/firewall
as described above.<br>
<li>When an 'add' or 'delete' command is executed, a temporary directory
created in /tmp is not being removed. This problem may be corrected by installing
<a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.2/firewall"
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
described ablve. <br>
</li>
</ul>
<h3>1.4.0</h3>
<h3>1.4.1a, 1.4.1 and 1.4.0</h3>
<ul>
<li>When running under certain shells Shorewall will attempt to create
ECN rules even when /etc/shorewall/ecn is empty. You may either just remove
/etc/shorewall/ecn or you can install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
<li>Some TCP requests are rejected in the 'common' chain with an ICMP
port-unreachable response rather than the more appropriate TCP RST response.
This problem is corrected in <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1a/common.def"
target="_top">this updated common.def file</a> which may be installed in
/etc/shorewall/common.def.<br>
</li>
</ul>
<hr width="100%" size="2">
<h3>1.4.1</h3>
<ul>
<li>When a "shorewall check" command is executed, each "rule" produces
the harmless additional message:<br>
<br>
     /usr/share/shorewall/firewall: line 2174: [: =: unary operator
expected<br>
<br>
You may correct the problem by installing <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1/firewall"
target="_top">this corrected script</a> in /usr/share/shorewall/firewall
as described above.<br>
</li>
</ul>
<h3>1.4.0</h3>
<ul>
<li>When running under certain shells Shorewall will attempt to create
ECN rules even when /etc/shorewall/ecn is empty. You may either just remove
/etc/shorewall/ecn or you can install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
</li>
</ul>
<hr width="100%" size="2">
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
<p align="left">The upgrade issues have moved to <a
href="upgrade_issues.htm">a separate page</a>.</p>
<hr>
<hr>
<h3 align="left"><a name="iptables"></a><font color="#660066"> Problem with
iptables version 1.2.3</font></h3>
<blockquote>
iptables version 1.2.3</font></h3>
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
corrected 1.2.3 rpm which you can download here</a>  and I
corrected 1.2.3 rpm which you can download here</a>  and I
have also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
has released an iptables-1.2.4 RPM of their own which you
can download from<font color="#ff6633"> <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
</font>I have installed this RPM on my firewall and it works
fine.</p>
</font>I have installed this RPM on my firewall and it
works fine.</p>
<p align="left">If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This <a
the patches are available for download. This <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</a>
which corrects a problem with parsing of the --log-level
specification while this <a
which corrects a problem with parsing of the --log-level
specification while this <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</a>
corrects a problem in handling the  TOS target.</p>
corrects a problem in handling the  TOS target.</p>
<p align="left">To install one of the above patches:</p>
<ul>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
</ul>
</blockquote>
</blockquote>
<h3><a name="Debug"></a>Problems with kernels &gt;= 2.4.18 and
RedHat iptables</h3>
<blockquote>
<blockquote>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
<blockquote>
may experience the following:</p>
<blockquote>
<pre># shorewall start<br>Processing /etc/shorewall/shorewall.conf ...<br>Processing /etc/shorewall/params ...<br>Starting Shorewall...<br>Loading Modules...<br>Initializing...<br>Determining Zones...<br>Zones: net<br>Validating interfaces file...<br>Validating hosts file...<br>Determining Hosts in Zones...<br>Net Zone: eth0:0.0.0.0/0<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br></pre>
</blockquote>
</blockquote>
<p>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by
installing <a
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. If you are already running a 1.2.5
version of iptables, you will need to specify the --oldpackage
option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
this iptables RPM</a>. If you are already running a 1.2.5
version of iptables, you will need to specify the --oldpackage
option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
<h3><a name="SuSE"></a>Problems installing/upgrading
RPM on SuSE</h3>
RPM on SuSE</h3>
<p>If you find that rpm complains about a conflict with kernel &lt;=
2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps"
option to rpm.</p>
2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps"
option to rpm.</p>
<p>Installing: rpm -ivh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<p>Upgrading: rpm -Uvh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<h3><a name="Multiport"></a><b>Problems with iptables version 1.2.7 and
MULTIPORT=Yes</b></h3>
MULTIPORT=Yes</b></h3>
<p>The iptables 1.2.7 release of iptables has made an incompatible
change to the syntax used to specify multiport match rules; as
a consequence, if you install iptables 1.2.7 you must be
running Shorewall 1.3.7a or later or:</p>
change to the syntax used to specify multiport match rules; as
a consequence, if you install iptables 1.2.7 you must
be running Shorewall 1.3.7a or later or:</p>
<ul>
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or
</li>
<li>if you are
running Shorewall 1.3.6 you may
install <a
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or
</li>
<li>if you are
running Shorewall 1.3.6 you may
install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
this firewall script</a> in /var/lib/shorewall/firewall
as described above.</li>
as described above.</li>
</ul>
<h3><a name="NAT"></a>Problems with RH Kernel 2.4.18-10 and NAT<br>
</h3>
/etc/shorewall/nat entries of the following form will
result in Shorewall being unable to start:<br>
<br>
</h3>
/etc/shorewall/nat entries of the following form will
result in Shorewall being unable to start:<br>
<br>
<pre>#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL<br>192.0.2.22    eth0    192.168.9.22   yes     yes<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
Error message is:<br>
Error message is:<br>
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
The solution is to put "no" in the LOCAL column. Kernel
support for LOCAL=yes has never worked properly and 2.4.18-10 has
disabled it. The 2.4.19 kernel contains corrected support under a
new kernel configuraiton option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 5/11/2003 - <a href="support.htm">Tom Eastep</a></font>
The solution is to put "no" in the LOCAL column. Kernel
support for LOCAL=yes has never worked properly and 2.4.18-10
has disabled it. The 2.4.19 kernel contains corrected support under
a new kernel configuraiton option; see <a
href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
</p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
</p>
</body>
</html>

BIN
Shorewall-docs/images/Legend.png Executable file
View File

Binary file not shown.

BIN
Shorewall-docs/images/Thumbs.db
View File

Binary file not shown.

506
Shorewall-docs/seattlefirewall_index.htm
View File

@ -2,107 +2,117 @@
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base
target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%" height="90">
<tbody>
<tr>
<td width="100%" height="90">
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><a
href="http://www.shorewall.net" target="_top"><img border="1"
src="images/shorewall.jpg" width="119" height="38" hspace="4"
alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<small><small><small><small><a
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
</a></i></font><a href="http://www.shorewall.net"
target="_top"><img border="1" src="images/shorewall.jpg" width="119"
height="38" hspace="4" alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<small><small><small><small><a
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
<div align="center">
<div align="center">
<h1><font color="#ffffff"> Shorewall 1.4</font><i><font
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i><a
href="1.3" target="_top"><font color="#ffffff"><br>
</font></a><br>
</font></a><br>
</h1>
</div>
</h1>
</div>
<p><a href="http://www.shorewall.net" target="_top"> </a> </p>
</td>
</tr>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<tbody>
<td width="90%">
<tr>
<td width="90%">
<h2 align="left">What is it?</h2>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This
program is distributed in the hope that
it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.<br>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
Foundation.<br>
<br>
You
should have received a copy of the GNU
General Public License along with
this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the
GNU General Public License along
with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -110,216 +120,288 @@ GNU General Public License</a> as published by the Free Software
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to your
setup. If you want to use the documentation that you find here, it is best
if you uninstall what you have and install a setup that matches the documentation
on this site. See the <a href="two-interface.htm">Two-interface QuickStart
Guide</a> for details.<br>
<h2> Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to
your setup. If you want to use the documentation that you find here, it
is best if you uninstall what you have and install a setup that matches
the documentation on this site. See the <a href="two-interface.htm">Two-interface
QuickStart Guide</a> for details.<br>
<h2> Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>News</h2>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b><img border="0"
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b><br>
</p>
This version primarily corrects the documentation included in the .tgz and
in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are running
iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies
as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3 </b><b><img border="0"
</b></p>
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out
that the code in 1.4.4 restricts the length of short zone names to 4 characters.
I've produced version 1.4.4a that restores the previous 5-character limit
by conditionally omitting the log rule number when the LOGFORMAT doesn't
contain '%d'.
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
    <b>Problems Corrected:<br>
</b><b> </b></p>
I apologize for the rapid-fire releases but since there is a potential
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
it a full release rather than just a bug-fix release. <br>
<br>
<b>    Problems corrected:</b><br>
<blockquote>None.<br>
</blockquote>
<b>    New Features:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to remove
a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets. This
insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a> now supported
in the /etc/shorewall/tunnels file.</li>
<li>Shorewall can now be easily integrated with fireparse (http://www.fireparse.com)
by setting LOGMARKER="fp=" in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
<li>A REDIRECT- rule target has been added. This target behaves
for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
nat table REDIRECT rule is added but not the companion filter table ACCEPT
rule.<br>
<br>
</li>
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
been changed to a 'printf' formatting template which accepts three arguments
(the chain name, logging rule number and the disposition). To use LOGFORMAT
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
set it as:<br>
 <br>
       LOGFORMAT="fp=%s:%d a=%s "<br>
 <br>
<b>CAUTION: </b>/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.<br>
<br>
</li>
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
the logging now takes place in the nat table rather than in the filter table.
This way, only those connections that actually undergo DNAT or redirection
will be logged.<br>
</li>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
</ol>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
</p>
This version primarily corrects the documentation included in the .tgz
and in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are
running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
replies as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to
remove a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets.
This insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a> now
supported in the /etc/shorewall/tunnels file.</li>
<li>You may now change the leading portion of the --log-prefix
used by Shorewall using the LOGMARKER variable in shorewall.conf. By default,
"Shorewall:" is used.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<blockquote>This morning, I gave <a href="GSLUG.htm" target="_top">a
Shorewall presentation to GSLUG</a>. The presentation is
in HTML format but was generated from Microsoft PowerPoint and is best
viewed using Internet Explorer (although Konqueror also seems to work
reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape work
well to view the presentation.<br>
</blockquote>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<blockquote>This morning, I gave <a href="GSLUG.htm" target="_top">a
Shorewall presentation to GSLUG</a>. The presentation is
in HTML format but was generated from Microsoft PowerPoint and is best
viewed using Internet Explorer (although Konqueror also seems to work
reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.<br>
</blockquote>
<p><b></b></p>
<blockquote>
<blockquote>
<ol>
</ol>
</blockquote>
</blockquote>
<p><a href="News.htm">More News</a></p>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</a>Jacques
Nilo and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that
features Shorewall-1.3.14 and Kernel-2.4.20.
You can find their work at: <a
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their
work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
</a></p>
<b>Congratulations to Jacques and Eric on the recent release of Bering
1.2!!! </b><br>
<b>Congratulations to Jacques and Eric on the recent release
of Bering 1.2!!! </b><br>
<h2><a name="Donations"></a>Donations</h2>
</td>
</td>
<td width="88" bgcolor="#4b017c" valign="top" align="center">
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font color="#ffffff"><b>Note:
</b></font></strong><font color="#ffffff">Search is unavailable
Daily 0200-0330 GMT.</font><br>
<strong></strong>
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font color="#ffffff"><b>Note:
</b></font></strong><font color="#ffffff">Search is unavailable
Daily 0200-0330 GMT.</font><br>
<strong></strong>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial"
size="-1"> <input type="text" name="words" size="15"></font><font
size="-1"> </font> <font face="Arial" size="-1"> <input
type="hidden" name="format" value="long"> <input type="hidden"
name="method" value="and"> <input type="hidden" name="config"
value="htdig"> <input type="submit" value="Search"></font> </p>
<font face="Arial"> <input
type="hidden" name="exclude"
<font
face="Arial" size="-1"> <input type="text" name="words"
size="15"></font><font size="-1"> </font> <font face="Arial"
size="-1"> <input type="hidden" name="format" value="long"> <input
type="hidden" name="method" value="and"> <input type="hidden"
name="config" value="htdig"> <input type="submit" value="Search"></font>
</p>
<font
face="Arial"> <input type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font> </form>
<p><font color="#ffffff"><b><a
href="http://lists.shorewall.net/htdig/search.html"><font
color="#ffffff">Extended Search</font></a></b></font></p>
<br>
</td>
<br>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</div>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td
width="100%" style="margin-top: 1px;">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
</tbody>
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 5/19/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

499
Shorewall-docs/shorewall_firewall_structure.htm
View File

@ -1,175 +1,334 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Shorewall Firewall Structure</title>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Firewall Structure</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Firewall Structure</font></h1>
</td>
</tr>
</table>
<p>
Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw"
which refers to the firewall system itself . The /etc/shorewall/zones file
is used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li>
net -- the (untrusted) internet.</li>
<li>
dmz - systems that must be accessible from the internet and from the
local network.  These systems cannot be trusted completely since their servers
may have been compromised through a security exploit.</li>
<li>
loc - systems in your local network(s). These systems must be protected
from the internet and from the DMZ and in some cases, from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall zone</a>.
For ease of description in this documentation, it is assumed
that the firewall zone is named &quot;fw&quot;.</p>
<p>It can't be stressed enough that
with the exception of the firewall zone, Shorewall itself attaches no meaning to
zone names. Zone names are simply labels used to refer to a collection of
network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>For a general picture of how packets traverse a Netfilter firewall, see
<a href="http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES">
http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.</a><br>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Firewall Structure</font></h1>
</td>
</tr>
</tbody>
</table>
<p> Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw" which
refers to the firewall system itself . The /etc/shorewall/zones file is
used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li> net -- the (untrusted) internet.</li>
<li> dmz - systems that must be accessible from the internet
and from the local network.  These systems cannot be trusted completely
since their servers may have been compromised through a security exploit.</li>
<li> loc - systems in your local network(s). These systems
must be protected from the internet and from the DMZ and in some cases,
from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall
zone</a>. For ease of description in this documentation, it is assumed
that the firewall zone is named "fw".</p>
<p>It can't be stressed enough that with the exception of the firewall zone,
Shorewall itself attaches no meaning to zone names. Zone names are simply
labels used to refer to a collection of network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the purpose
of this document, we will consider Netfilter to have three tables:</p>
<ol>
<li>Filter table -- this is the main table for packet filtering and can
be displayed with the command "shorewall show".</li>
<li>Nat table -- used for all forms of Network Address Translation (NAT);
SNAT, DNAT and MASQUERADE.</li>
<li>Mangle table -- used to modify fields in the packet header.<br>
</li>
</ol>
<p>Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
as shown in this table.<br>
</p>
<div align="center">
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">CHAIN<br>
</td>
<td valign="top">Filter<br>
</td>
<td valign="top">Nat<br>
</td>
<td valign="top">Mangle<br>
</td>
</tr>
<tr>
<td valign="top">PREROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">INPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">OUTPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">FORWARD<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">POSTROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
</tbody>
</table>
</div>
<p>Shorewall doesn't create rules in all of the builtin chains. In the large
diagram below are boxes such as  shown below.  This box represents in INPUT
chain and shows that packets first flow through the INPUT chain in the Mangle
table followed by the INPUT chain in the Filter table. The parentheses around
"Mangle" indicate that while the packets will flow through the INPUT chain
in the Mangle table, Shorewall does not create any rules in that chain.<br>
</p>
<div align="center"><img src="images/Legend.png" alt="(Box Legend)"
width="145" height="97" align="middle">
<br>
Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing &quot;shorewall show
mangle&quot;). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b>&nbsp; which will drop
the packet if its destination IP address is reserved (as specified in the
/etc/shorewall/rfc1918 file). Next the packet passes through the<b> pretos</b>
chain to set its TOS field as specified in the /etc/shorewall/tos file.
Finally, if traffic control/shaping is being used, the packet is sent through
the<b> tcpre</b> chain to be marked for later use in policy routing or traffic
control.</p>
<p>Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table by
typing &quot;shorewall show nat&quot;). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on the
setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on then
packets will ender a chain called <i>interface_</i>in where <i>interface</i> is
the name of the interface on which the packet entered. Here it's destination IP
is compared to each of the <i>EXTERNAL</i> IP addresses from /etc/shorewall/nat
that correspond to this interface; if there is a match, DNAT is applied and the
packet header is modified to the IP in the <i>INTERNAL</i> column of the nat
file record. If the destination address doesn't match any of the rules in the
<i>interface_</i>in chain then the packet enters a chain called <i>sourcezone</i>_dnat
</div>
<p></p>
<p>Here is a picture of how packets traverse the various chains and tables
in Netfilter. In that diagram, "Local Process" refers to a process running
on the Firewall itself (in the 'fw' zone).</p>
<div align="center"><img src="images/Netfilter.png"
alt="Netfilter Flow Diagram" width="541" height="767">
</div>
<p><br>
<br>
In the text that follows, the paragraph numbers correspond to the box number
in the diagram above.<br>
</p>
<ol>
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing "shorewall show
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b> chain which will
drop the packet if its destination IP address is reserved (as specified
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
file. Finally, if traffic control/shaping is being used, the packet is sent
through the<b> tcpre</b> chain to be marked for later use in policy routing
or traffic control.<br>
<br>
Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
by typing "shorewall show nat"). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on
the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
on then packets will ender a chain called<b> <i>interface_</i>in</b> where
<i>interface</i> is the name of the interface on which the packet entered.
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP
addresses from /etc/shorewall/nat that correspond to this interface; if
there is a match, DNAT is applied and the packet header is modified to
the IP in the <i>INTERNAL</i> column of the nat file record. If the destination
address doesn't match any of the rules in the <b><i>interface_</i>in</b>
chain then the packet enters a chain called <b><i>sourcezone</i>_dnat</b>
where <i>sourcezone</i> is the source zone of the packet. There it is compared
for a match against each of the DNAT records in the rules file that specify <i>
sourcezone </i>as the source zone. If a match is found, the destination IP
address (and possibly the destination port) is modified based on the rule
matched. If NAT_BEFORE_RULES is off, then the order of traversal of the <i>
interface_</i>in and <i>sourcezone</i>_dnat is reversed.</p>
<p>
Traffic is next sent to an<i> input </i>chain in the mail Netfilter table
(called 'filter'). If the traffic is destined for the
firewall itself, the name of the input chain is formed by appending &quot;_in&quot; to
the interface name. So traffic on eth0 destined for the firewall will enter a
chain called <i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending &quot;_fwd&quot; to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character (&quot;+&quot;) in
/etc/shorewall/interfaces, share input chains. if <i>ppp+ </i>appears in
/etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will share
the input chains <i>ppp_in</i> and <i>ppp_fwd</i>. In other words, &quot;+&quot; is
deleted from the name before forming the input chain names.</p>
<p>
While the use of input chains may seem wasteful in simple environments, in
complex setups it substantially reduces the number of rules that each packet
must traverse.&nbsp; </p>
<p>
Traffic directed from a zone to the firewall itself is sent through a
chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">
 </font></p>
<p>
Traffic being forwarded between two zones (or from one interface to a
zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to
as the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p>
For each record in the /etc/shorewall/policy file, a chain is created. Policies
in that file are expressed in terms of a source zone and destination zone
where these zones may be a zone defined in /etc/shorewall/zones, "fw" or
"all". Policies specifying the pseudo-zone "all" matches all defined zones
and "fw". These chains are referred to as <i>Policy Chains.</i> Notice that
for an ordered pair of zones (za,zb), the canonical chain (za2zb) may also
be the policy chain for the pair or the policy chain may be a different
chain (za2all, for example). Packets from one zone to another will traverse
chains as follows:</p>
<ol>
<li>
If the canonical chain exists, packets first traverse that chain.</li>
<li>
If the canonical chain and policy chain are different and the packet
does not match a rule in the canonical chain, it then is sent to the
policy chain.</li>
<li>
If the canonical chain does not exist, packets are sent immediately
to the policy chain.</li>
</ol>
<p>
The canonical chain from zone za to zone zb will be created only if there
are exception rules defined in /etc/shorewall/rules for packets going from
za to zb.</p>
<p>
Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
<ol>
<li>
Identify the client's zone.</li>
<li>
Identify the server's zone.</li>
<li>
If the POLICY from the client's zone to the server's zone is what you
want for this client/server pair, you need do nothing further.</li>
<li>
If the POLICY is not what you want, then you must add a rule. That rule
is expressed in terms of the client's zone and the server's zone.</li>
</ol>
<p>
Just because connections of a particular type are allowed between zone A
and the firewall and are also allowed between the firewall and zone B <font color="#ff6633"><b><u>
DOES NOT mean that these connections are allowed between zone A and zone
B</u></b></font>. It rather means that you can have a proxy running on
the firewall that accepts a connection from zone A and then establishes
its own separate connection from the firewall to zone B.</p>
<p>
If you adopt the default policy of ACCEPT from the local zone to the internet
zone and you are having problems connecting from a local client to an internet
server, <font color="#ff6633"><b><u> adding a rule won't help</u></b></font>
(see point 3 above).</p>
<p><font size="2">Last modified 8/22/2002 - <a href="support.htm">Tom
Eastep</a></font><p><font face="Trebuchet MS"><a href="copyright.htm">
<font size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></body></html>
for a match against each of the DNAT records in the rules file that specify
<i> sourcezone </i>as the source zone. If a match is found, the destination
IP address (and possibly the destination port) is modified based on the
rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of
the <b><i> interface_</i>in</b> and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
<br>
</li>
<li>Depending on whether the packet is destined for the firewall itself
or for another system, it follows either the left or the right path. Traffic
going to the firewall goes through chains called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain. Traffic next passes the the
INPUT chain in the filter table where it is broken out based on the interface
on which the packet arrived; packets from interface <i>interface</i> are routed
to chain <b><i>interface</i>_in</b>. For example, packets arriving through
eth0 are passed to the chain <b>eth0_in.</b></li>
<ol>
<li>The first rule in <b><i>interface</i>_in</b> jumps to the chain
named <b>dynamic</b> which matches the source IP in the packet against all
of the addresses that have been blacklisted using <a
href="blacklisting_support.htm#Dynamic">dynamic blacklisting</a>.</li>
<li>If the the interface has the <b>norfc1918</b> option then the packet
is sent down the <b>rfc1918 </b>which checks the source address against those
listed in /etc/shorewall/rfc1918 and treats the packet according to the first
match in that file (if any).</li>
<li>If the interface has the  <b>dhcp </b>option, UDP packets to ports
67 and 68 are accepted.</li>
<li><br>
</li>
</ol>
<li>Traffic is next sent to an<i> input </i>chain in the mail Netfilter
table (called 'filter'). If the traffic is destined for the firewall itself,
the name of the input chain is formed by appending "_in" to the interface
name. So traffic on eth0 destined for the firewall will enter a chain called
<i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending "_fwd" to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces,
share input chains. if <i>ppp+ </i>appears in /etc/shorewall/interfaces
then all PPP interfaces (ppp0, ppp1, ...) will share the input chains <i>ppp_in</i>
and <i>ppp_fwd</i>. In other words, "+" is deleted from the name before
forming the input chain names.</li>
</ol>
<p> While the use of input chains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </p>
<p> Traffic directed from a zone to the firewall itself is sent through
a chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">  </font></p>
<p> Traffic being forwarded between two zones (or from one interface to
a zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to as
the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p> For each record in the /etc/shorewall/policy file, a chain is created.
Policies in that file are expressed in terms of a source zone and destination
zone where these zones may be a zone defined in /etc/shorewall/zones,
"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
zones and "fw". These chains are referred to as <i>Policy Chains.</i> Notice
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
may also be the policy chain for the pair or the policy chain may be a
different chain (za2all, for example). Packets from one zone to another
will traverse chains as follows:</p>
<ol>
<li> If the canonical chain exists, packets first traverse that
chain.</li>
<li> If the canonical chain and policy chain are different and
the packet does not match a rule in the canonical chain, it then is sent
to the policy chain.</li>
<li> If the canonical chain does not exist, packets are sent
immediately to the policy chain.</li>
</ol>
<p> The canonical chain from zone za to zone zb will be created only if
there are exception rules defined in /etc/shorewall/rules for packets going
from za to zb.</p>
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
<ol>
<li> Identify the client's zone.</li>
<li> Identify the server's zone.</li>
<li> If the POLICY from the client's zone to the server's zone
is what you want for this client/server pair, you need do nothing further.</li>
<li> If the POLICY is not what you want, then you must add a
rule. That rule is expressed in terms of the client's zone and the
server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed between zone
A and the firewall and are also allowed between the firewall and zone
B <font color="#ff6633"><b><u> DOES NOT mean that these connections
are allowed between zone A and zone B</u></b></font>. It rather means
that you can have a proxy running on the firewall that accepts a connection
from zone A and then establishes its own separate connection from the firewall
to zone B.</p>
<p> If you adopt the default policy of ACCEPT from the local zone to the
internet zone and you are having problems connecting from a local client
to an internet server, <font color="#ff6633"><b><u> adding a rule won't
help</u></b></font> (see point 3 above).</p>
<p><font size="2">Last modified 5/22/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
</body>
</html>

523
Shorewall-docs/sourceforge_index.htm
View File

@ -2,335 +2,420 @@
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<base target="_self">
<base
target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tr>
<tbody>
<td width="100%" height="90">
<tr>
<td width="100%" height="90">
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall 1.4 -
<font size="4">"<i>iptables made easy"</i></font></font><br>
<a target="_top" href="1.3/index.html"><font
</a></i></font><font color="#ffffff">Shorewall 1.4
- <font size="4">"<i>iptables made
easy"</i></font></font><br>
<a target="_top" href="1.3/index.html"><font
color="#ffffff"> </font></a><a target="_top"
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small><br>
</small></small></small></font></a>
</small></small></small></font></a>
</h1>
</td>
</tr>
</h1>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<tbody>
<td width="90%">
<tr>
<td width="90%">
<h2 align="left">What is it?</h2>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a>
(iptables) based firewall that can be used on
a dedicated firewall system, a multi-function gateway/router/server
or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the GNU
General Public License along with
this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a>
(iptables) based firewall that can be used
on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of the
GNU General Public License along
with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, almost <b>NOTHING </b>on this site will apply directly to your
setup. If you want to use the documentation that you find here, it is best
if you uninstall what you have and install a setup that matches the documentation
on this site. See the <a href="two-interface.htm">Two-interface QuickStart
Guide</a> for details.<br>
If so, almost <b>NOTHING </b>on this site will apply directly to
your setup. If you want to use the documentation that you find here, it
is best if you uninstall what you have and install a setup that matches
the documentation on this site. See the <a href="two-interface.htm">Two-interface
QuickStart Guide</a> for details.<br>
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2><b>News</b></h2>
<b> </b>
<b> </b>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b><img border="0"
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b><br>
</p>
This version primarily corrects the documentation included in the .tgz and
in the .rpm. In addition: <br>
<ol>
<li>(This change is in 1.4.3 but is not documented) If you are running
iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies
as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/18/2003 - Shorewall 1.4.3 </b><b><img border="0"
</b></p>
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out
that the code in 1.4.4 restricts the length of short zone names to 4 characters.
I've produced version 1.4.4a that restores the previous 5-character limit
by conditionally omitting the log rule number when the LOGFORMAT doesn't
contain '%d'.
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
</b><b> </b></p>
I apologize for the rapid-fire releases but since there is a potential
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
it a full release rather than just a bug-fix release. <br>
<br>
<b>    Problems corrected:</b><br>
<blockquote>None.<br>
</blockquote>
<b>    New Features:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to remove
a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets. This
insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
<li>A REDIRECT- rule target has been added. This target behaves
for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
nat table REDIRECT rule is added but not the companion filter table ACCEPT
rule.<br>
<br>
</li>
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
been changed to a 'printf' formatting template which accepts three arguments
(the chain name, logging rule number and the disposition). To use LOGFORMAT
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
set it as:<br>
 <br>
       LOGFORMAT="fp=%s:%d a=%s "<br>
 <br>
<b>CAUTION: </b>/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.<br>
<br>
</li>
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
the logging now takes place in the nat table rather than in the filter table.
This way, only those connections that actually undergo DNAT or redirection
will be logged.</li>
</ol>
    <b>New Features:<br>
</b>
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b>
</b><br>
</p>
This version primarily corrects the documentation included in the .tgz
and in the .rpm. In addition: <br>
<ol>
<li><a href="6to4.htm"> </a><a href="6to4.htm">IPV6-IPV4 (6to4)
tunnels </a>are now supported in the /etc/shorewall/tunnels file.</li>
<li>Shorewall can now be easily integrated with fireparse (<a
href="http://www.fireparse.com">http://www.fireparse.com</a>) by setting
LOGMARKER="fp=" in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
<li>(This change is in 1.4.3 but is not documented) If you are
running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
replies as follows:<br>
   a) tcp - RST<br>
   b) udp - ICMP port unreachable<br>
   c) icmp - ICMP host unreachable<br>
   d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's traditional
convention:<br>
   a) tcp - RST<br>
   b) Otherwise - ICMP port unreachable</li>
<li>UDP port 135 is now silently dropped in the common.def chain.
Remember that this chain is traversed just before a DROP or REJECT policy
is enforced.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
</p>
    <b>Problems Corrected:<br>
</b>
<ol>
<li>There were several cases where Shorewall would fail to
remove a temporary directory from /tmp. These cases have been corrected.</li>
<li>The rules for allowing all traffic via the loopback interface
have been moved to before the rule that drops status=INVALID packets.
This insures that all loopback traffic is allowed even if Netfilter connection
tracking is confused.</li>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b>  </b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
</ol>
    <b>New Features:<br>
</b>
<ol>
<li><a href="6to4.htm"> </a><a href="6to4.htm">IPV6-IPV4 (6to4)
tunnels </a>are now supported in the /etc/shorewall/tunnels file.</li>
<li value="2">You may now change the leading portion of the
--log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf.
By default, "Shorewall:" is used.<br>
</li>
</ol>
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
</p>
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b>  </b></p>
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b>  </b></p>
<p>The list server will be down this morning for upgrade to RH9.0.<br>
</p>
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
</b></p>
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
to Shorewall version 1.4.2.</p>
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
</b></p>
<blockquote> This morning, I gave <a href="GSLUG.htm"
target="_top">a Shorewall presentation to GSLUG</a>. The presentation
is in HTML format but was generated from Microsoft PowerPoint and
is best viewed using Internet Explorer (although Konqueror also seems
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.</blockquote>
target="_top">a Shorewall presentation to GSLUG</a>. The presentation
is in HTML format but was generated from Microsoft PowerPoint and
is best viewed using Internet Explorer (although Konqueror also seems
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
work well to view the presentation.</blockquote>
<p><b></b></p>
<blockquote>
<blockquote>
<ol>
</ol>
</blockquote>
</blockquote>
<p><a href="file:///Z:/Shorewall-docs/News.htm"></a></p>
<b> </b>
<b> </b>
<p><b><a href="News.htm">More News</a></b></p>
<b> </b>
<b> </b>
<h2><b> </b></h2>
<b> </b>
<b> </b>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work
at: <a href="http://leaf.sourceforge.net/devel/jnilo">
http://leaf.sourceforge.net/devel/jnilo</a></p>
</a>Jacques Nilo and Eric Wolzak have
a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called
<i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and Eric on
the recent release of Bering 1.2!!! </b><br>
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.2!!! </b><br>
<h1 align="center"><b><a href="http://www.sf.net"><img
align="left" alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
</a></b></h1>
<b> </b>
</a></b></h1>
<b> </b>
<h4><b> </b></h4>
<b> </b>
<b> </b>
<h2><b>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </b></h2>
<b> </b>
<b> </b>
<h2><b><a name="Donations"></a>Donations</b></h2>
<b> </b></td>
<b> </b></td>
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
action="http://lists.shorewall.net/cgi-bin/htsearch">
<p><strong><br>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
 </p>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
 </p>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial" size="-1"> <input
<font face="Arial" size="-1"> <input
type="text" name="words" size="15"></font><font size="-1"> </font><font
face="Arial" size="-1"> <input type="hidden" name="format"
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
type="submit" value="Search"></font> </p>
<font face="Arial"> <input type="hidden"
name="exclude" value="[http://lists.shorewall.net/pipermail/*]">
</font> </form>
<font face="Arial"> <input
type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font>
</form>
<p><font color="#ffffff"><b> <a
href="http://lists.shorewall.net/htdig/search.html"> <font
color="#ffffff">Extended Search</font></a></b></font></p>
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small></small></small></small></font></a><br>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</div>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<tbody>
<tr>
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 5/19/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

475
Shorewall-docs/support.htm
View File

@ -1,79 +1,81 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Support Guide</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td
width="100%">
<tbody>
<tr>
<td
width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Support Guide<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
</td>
</tr>
</tbody>
</font></h1>
</td>
</tr>
</tbody>
</table>
<h2>Before Reporting a Problem or Asking a Question<br>
</h2>
There are
a number of sources of Shorewall information. Please try these before
you post.
</h2>
There
are a number of sources of Shorewall information. Please try these
before you post.
<ul>
<li>Shorewall versions earlier
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has solutions
to more than 20 common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has
solutions to more than 20 common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li> The Site
and Mailing List Archives search facility can locate documents
and posts about similar problems: </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li> The Site
and Mailing List Archives search facility can locate documents
and posts about similar problems: </li>
</ul>
<h2>Site and Mailing List Archive Search</h2>
<blockquote>
<blockquote>
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
<select name="method">
<option value="and">All </option>
<option value="or">Any </option>
<option value="boolean">Boolean </option>
</select>
Format:
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -82,238 +84,233 @@ list have answers directly accessible from the <a
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font><input type="hidden" name="config"
</font><input type="hidden" name="config"
value="htdig"><input type="hidden" name="restrict" value=""><font
size="-1"> Include Mailing List Archives:
size="-1"> Include Mailing List Archives:
<select size="1" name="exclude">
<option value="">Yes</option>
<option value="[http://lists.shorewall.net/pipermail/.*]">No</option>
</select>
</font><br>
Search: <input type="text" size="30" name="words"
</font><br>
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"><br>
</form>
</blockquote>
</form>
</blockquote>
<h2>Problem Reporting Guidelines<br>
</h2>
</h2>
<ul>
<li>Please remember we only know what
is posted in your message. Do not leave out any information
that appears to be correct, or was mentioned in a previous
post. There have been countless posts by people who were sure
that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're
asking for <strong>free</strong> technical support.
Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. <em>Exact quoting </em> of
error messages, log entries, command output, and other output is better
than a paraphrase or summary.<br>
<br>
</li>
<li>
Please don't describe your environment and then ask us
to send you custom configuration files. We're here
to answer your questions but we can't do your
job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
<li>Please remember we only know what
is posted in your message. Do not leave out any information
that appears to be correct, or was mentioned in a previous post.
There have been countless posts by people who were sure that
some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is
lacking.<br>
<br>
</li>
<li>Please keep in mind that you're
asking for <strong>free</strong> technical support. Any
help we offer is an act of generosity, not an obligation. Try
to make it easy for us to help you. Follow good, courteous practices
in writing and formatting your e-mail. Provide details that we need
if you expect good answers. <em>Exact quoting </em> of error messages,
log entries, command output, and other output is better than a paraphrase
or summary.<br>
<br>
</li>
<li>
Please don't describe your environment and then ask us
to send you custom configuration files. We're here
to answer your questions but we can't do your
job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall
you are running.<br>
<br>
<b><font color="#009900">shorewall
version</font><br>
</b> <br>
</li>
<li>the exact version of Shorewall
you are running.<br>
<br>
<b><font color="#009900">shorewall
version</font><br>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version you are
running<br>
<br>
<font color="#009900"><b>uname -a<br>
<br>
</b></font></li>
<li>the exact kernel version you
are running<br>
<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr
show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip route
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr
show<br>
<br>
</b></font></li>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip route
show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
</ul>
</ul>
<ul>
<ul>
<li><font color="#ff0000"><u><i><big><b>If you are having connection
problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><br>
<br>
2. Try the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall status
<li><font color="#ff0000"><u><i><big><b>If you are having connection
problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><br>
<br>
2. Try the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall status
&gt; /tmp/status.txt</font></b><br>
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart
Guides, please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the
Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart
Guides, please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
</ul>
<li>As
a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
<li>As
a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages ("<b><font
color="#009900">/sbin/shorewall show log</font></b>") when
you exercise the function that is giving you problems? If so,
include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration
files (especially the /etc/shorewall/hosts file if
you have modified that file) that you think are relevant.
If you include /etc/shorewall/rules, please include /etc/shorewall/policy
as well (rules are meaningless unless one also knows the policies).<br>
<br>
</li>
<li>If an error occurs when you try to "<font
color="#009900"><b>shorewall start</b></font>", include a trace
(See the <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so don't
post GIFs of your network layout, etc. to
the Mailing List -- your post will be rejected.</b></li>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages ("<b><font
color="#009900">/sbin/shorewall show log</font></b>") when
you exercise the function that is giving you problems? If
so, include the message(s) in your post along with a copy of your
/etc/shorewall/interfaces file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration
files (especially the /etc/shorewall/hosts file
if you have modified that file) that you think are
relevant. If you include /etc/shorewall/rules, please include
/etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies).<br>
<br>
</li>
<li>If an error occurs when you try to "<font
color="#009900"><b>shorewall start</b></font>", include a trace
(See the <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so don't
post GIFs of your network layout, etc.
to the Mailing List -- your post will be rejected.</b></li>
</ul>
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<em>Olszewski</em> found at <a
href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
</blockquote>
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> A growing number of MTAs serving list subscribers are
rejecting all HTML traffic. At least one MTA has gone so far as to
blacklist shorewall.net "for continuous abuse" because it has been
my policy to allow HTML in list posts!!<br>
<br>
I think that blocking all HTML is
a Draconian way to control spam and that the ultimate losers
here are not the spammers but the list subscribers whose MTAs
are bouncing all shorewall.net mail. As one list subscriber wrote
to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML based
e-mail". Nevertheless, to allow subscribers to receive list posts
as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts.<br>
</blockquote>
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist
shorewall.net "for continuous abuse" because it has been my policy
to allow HTML in list posts!!<br>
<br>
I think that blocking all HTML is
a Draconian way to control spam and that the ultimate losers
here are not the spammers but the list subscribers whose
MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML
based e-mail". Nevertheless, to allow subscribers to receive
list posts as must as possible, I have now configured the list
server at shorewall.net to strip all HTML from outgoing posts.<br>
</blockquote>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote> <b>If you have a <u>quick</u> question about
capabilities or where to find something, you may use the</b> <a
href="http://www.developercube.com/forum/index.php?c=8">Shorewall Support
Forum</a>. <u><b>DO NOT POST THE OUTPUT OF "shorewall status" TO THE FORUM;
I WON'T LOOK AT IT.</b></u> <b>If you need to supply "shorewall status"
output, use the appropriate mailing list below.</b><br>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft
Multi Network Firewall (MNF) and you have not purchased an
MNF license from MandrakeSoft then you can post non MNF-specific
Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list.</b><br>
style="font-weight: 400;">please post your question or problem
to the <a
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft
Multi Network Firewall (MNF) and you have not purchased
an MNF license from MandrakeSoft then you can post non MNF-specific
Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> .</p>
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> .</p>
<p> To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
<p>For information on other Shorewall mailing lists, go to <a
href="http://lists.shorewall.net">http://lists.shorewall.net</a><br>
</p>
<p align="left"><font size="2">Last Updated 5/12/2003 - Tom Eastep</font></p>
</p>
<p align="left"><font size="2">Last Updated 5/19/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
<br>
</p>
</body>
</html>

1984
Shorewall-docs/three-interface.htm
View File

File diff suppressed because it is too large Load Diff

2009
Shorewall-docs/three-interface_fr.html
View File

File diff suppressed because it is too large Load Diff

1643
Shorewall-docs/two-interface.htm
View File

File diff suppressed because it is too large Load Diff

814
Shorewall-docs/upgrade_issues.htm
View File

@ -1,421 +1,441 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Upgrade Issues</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p>For upgrade instructions see the <a
href="Install.htm">Install/Upgrade page</a>.<br>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you are
currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be
a host address) accessed through a particular interface.<br>
</p>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you
are currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
be a host address) accessed through a particular interface.<br>
</p>
<p>Examples:<br>
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</p>
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</p>
<h3> </h3>
<h3>Version &gt;= 1.4.2</h3>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current documentation
and change your configuration accordingly.<br>
<h3>Version &gt;= 1.4.1</h3>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the same
zone is accepted by default. Previously, traffic from a zone to itself was
treated just like any other traffic; any matching rules were applied followed
by enforcement of the appropriate policy. With 1.4.1 and later versions,
unless you have explicit rules for traffic from Z to Z or you have an explicit
Z to Z policy (where "Z" is some zone) then traffic between the groups
in zone Z will be accepted. If you do have one or more explicit rules for
Z to Z or if you have an explicit Z to Z policy then the behavior is as it
was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
traffic between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that has
"all" in either the SOURCE or DESTINATION column) to prevent traffic between
two interfaces to a zone Z and you have no rules for Z-&gt;Z then you should
add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
<ul>
<li> Sometimes, you want two separate zones on one interface but you
don't want Shorewall to set up any infrastructure to handle traffic between
them. </li>
</ul>
<blockquote>Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to be
involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to handle
traffic between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is asymetric
routing where only the traffic on one direction flows through the firewall
and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then I recommend that you upgrade to Version
1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the iproute
package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package iproute2
which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm
-Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when there
are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts
file has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is
no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped by
default; there is no need for your own /etc/shorewall/common file simply
to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file
have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include
it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does
not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
     Beginning in version 1.3.14, Shorewall treats entries in
<a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently. The
change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet
on the interface (as shown by "ip addr show <i>interface</i>") and would
masquerade traffic from that subnet. Any other subnets that routed through
eth1 needed their own entry in /etc/shorewall/masq to be masqueraded
or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
routing table to determine ALL subnets routed through the named interface.
Traffic originating in ANY of those subnets is masqueraded or has SNAT
applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq with
an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- Suppose that your current config is as
follows:<br>
   <br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is like
this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254 <br> [root@gateway test]#</pre>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf then
OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the old
handling indefinitely so I urge current users to migrate to using the
new handling as soon as possible. See the <a href="ping.html">'Ping' handling
documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading
to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this file
if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall &gt;= 1.3.3</b></h3>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering floppy
with the later one. If you did not
obtain the later version from Jacques's site, see additional instructions
below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget
to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need
to add the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can be
rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks
to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 4/13/2003 - <a href="support.htm">Tom
Eastep</a></font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<h3>Version &gt;= 1.4.4</h3>
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
you must set the new LOGFORMAT variable appropriately and remove your setting
of LOGMARKER<br>
<br>
<h3>Version 1.4.4<br>
</h3>
If you have zone names that are 5 characters long, you may experience problems
starting Shorewall because the --log-prefix in a logging rule is too long.
Upgrade to Version 1.4.4a to fix this problem..<br>
<h3>Version &gt;= 1.4.2</h3>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current
documentation and change your configuration accordingly.<br>
<h3>Version &gt;= 1.4.1</h3>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the
same zone is accepted by default. Previously, traffic from a zone to itself
was treated just like any other traffic; any matching rules were applied
followed by enforcement of the appropriate policy. With 1.4.1 and later
versions, unless you have explicit rules for traffic from Z to Z or you
have an explicit Z to Z policy (where "Z" is some zone) then traffic between
the groups in zone Z will be accepted. If you do have one or more explicit
rules for Z to Z or if you have an explicit Z to Z policy then the behavior
is as it was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
traffic between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent traffic
between two interfaces to a zone Z and you have no rules for Z-&gt;Z then
you should add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
<ul>
<li> Sometimes, you want two separate zones on one interface but
you don't want Shorewall to set up any infrastructure to handle traffic
between them. </li>
</ul>
<blockquote>Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to
be involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to handle
traffic between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is
asymetric routing where only the traffic on one direction flows through
the firewall and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then I recommend that you upgrade to Version
1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the
iproute package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm
-Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when there
are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and
hosts file has been eliminated; use entries in the routestopped file
instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
is no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped
by default; there is no need for your own /etc/shorewall/common file
simply to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version'
file have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you
include it from /etc/shorewall/icmpdef, you will need to modify that
file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same
interface that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to
or from the destination zone. An explicit policy names both zones and
does not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same
then the rule must be explicit - it must name the zone in both the SOURCE
and DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
     Beginning in version 1.3.14, Shorewall treats entries
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST
subnet on the interface (as shown by "ip addr show <i>interface</i>")
and would masquerade traffic from that subnet. Any other subnets that
routed through eth1 needed their own entry in /etc/shorewall/masq to
be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the
firewall's routing table to determine ALL subnets routed through
the named interface. Traffic originating in ANY of those subnets
is masqueraded or has SNAT applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq
with an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- Suppose that your current config is
as follows:<br>
   <br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is
like this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254 <br> [root@gateway test]#</pre>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to
be used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting
the old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now
upgrading to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this
file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall &gt;= 1.3.3</b></h3>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering
floppy with the later one. If you did
not obtain the later version from Jacques's site, see additional
instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not
forget to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a
href="two-interface.htm">instructions for setting up a two-interface
firewall</a> plus you also need to add the following two Bering-specific
rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept
Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
</p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
</body>
</html>

2
Shorewall/changelog.txt
View File

@ -8,4 +8,6 @@ Changes since 1.4.3a
3. DNAT and REDIRECT logging is moved from the filter table to the nat
table.
4. Don't include log rule number when LOGFORMAT doesn't include "%d".

2
Shorewall/fallback.sh
View File

@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
VERSION=1.4.4
VERSION=1.4.4a
usage() # $1 = exit status
{

10
Shorewall/firewall
View File

@ -4484,14 +4484,20 @@ do_initialize() {
if [ -n "$LOGFORMAT" ]; then
if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then
LOGRULENUMBERS=Yes
if ! qt printf "$LOGFORMAT" foo 1 bar ; then
temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
else
if ! qt printf "$LOGFORMAT" foo bar ; then
temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null`
if [ $? -ne 0 ]; then
startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\""
fi
fi
if [ ${#temp} -gt 29 ]; then
startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\""
fi
else
LOGFORMAT="Shorewall:%s:%s:"
fi

2
Shorewall/install.sh
View File

@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
VERSION=1.4.4
VERSION=1.4.4a
usage() # $1 = exit status
{

7
Shorewall/releasenotes.txt
View File

@ -11,8 +11,10 @@ New Features:
2) The LOGMARKER variable has been renamed LOGFORMAT and has been
changed to a 'printf' formatting template which accepts three
arguments (the chain name, logging rule number and the disposition).
To use LOGFORMAT with fireparse, set it as:
arguments (the chain name, logging rule number (optional) and the
disposition). The logging rule number is included if the LOGFORMAT
value contains '%d'. For example, to use LOGFORMAT with fireparse,
set it as:
LOGFORMAT="fp=%s:%d a=%s "
@ -28,3 +30,4 @@ New Features:
logging now takes place in the nat table rather than in the filter
table. This way, only those connections that actually undergo DNAT
or redirection will be logged.

4
Shorewall/shorewall.spec
View File

@ -1,5 +1,5 @@
%define name shorewall
%define version 1.4.4
%define version 1.4.4a
%define release 1
%define prefix /usr
@ -105,6 +105,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Tue May 27 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.4a-1
* Thu May 22 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.4-1
* Mon May 19 2003 Tom Eastep <tom@shorewall.net>

2
Shorewall/uninstall.sh
View File

@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
VERSION=1.4.4
VERSION=1.4.4a
usage() # $1 = exit status
{