holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests 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`

230
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,20 +2062,10 @@ 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
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $sports $multiport $state $cli $serv $dports`
fi
fi
run_iptables2 -A $chain $proto $multiport $state $cli $sports \
$serv $dports -j $target
@ -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
run_iptables -A badpkt -p tcp $logoptions --log-tcp-options
run_iptables -A badpkt -p ! tcp $logoptions
LOGPARMS="$LOGPARMS --log-ip-options"
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=
@ -4471,8 +4481,26 @@ do_initialize() {
CLEAR_TC=
fi
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
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
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.

18
STABLE/documentation/6to4.htm
View File

@ -27,6 +27,7 @@
<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
measures.</h3>
@ -35,8 +36,8 @@ measures.</h3>
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">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>
@ -55,11 +56,11 @@ 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>
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>
@ -134,7 +135,8 @@ other using IPv6.</p>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003Thomas M. Eastep.</font></a></p>
size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.</font></a></p>
<br>
<br>
<br>
</body>

1421
STABLE/documentation/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

303
STABLE/documentation/FAQ.htm
View File

@ -49,9 +49,9 @@
<p align="left"><b>1b. </b><a href="#faq1b">I'm still having problems with
port forwarding</a></p>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to
<b>connect to port 1022</b> on my firewall and have the <b>firewall forward
the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to <b>connect
to port 1022</b> on my firewall and have the <b>firewall forward the connection
to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
</p>
<h1><b>DNS and PORT FORWARDING/NAT<br>
@ -64,10 +64,11 @@ the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a>
clients can't</b>.</a></p>
<p align="left"><b>2a. </b><a href="#faq3">I have a zone "Z" with an RFC1918
subnet and I use <b>static NAT</b> to assign non-RFC1918
addresses to hosts in Z. Hosts in Z cannot communicate
with each other using their external (non-RFC1918 addresses)
so they <b>can't access each other using their DNS names.</b></a></p>
subnet and I use <b>static NAT</b> to assign
non-RFC1918 addresses to hosts in Z. Hosts in Z
cannot communicate with each other using their external
(non-RFC1918 addresses) so they <b>can't access each other
using their DNS names.</b></a></p>
<h1><b>NETMEETING/MSN<br>
</b></h1>
@ -87,15 +88,15 @@ the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a>
of my firewall and it showed 100s of ports as
open!!!!<br>
</a></p>
<b>4b</b>. <a href="#faq4b">I have a port that I can't close no matter how
I change my rules. </a>
<b>4b</b>. <a href="#faq4b">I have a port that I can't close no matter
how I change my rules. </a>
<h1>CONNECTION PROBLEMS</h1>
<p align="left"><b>5. </b><a href="#faq5">I've installed Shorewall and now
I <b> can't ping</b> through the firewall</a><br>
<b><br>
15. </b><a href="#faq15"><b>My local systems can't see out
to the net</b></a></p>
15. </b><a href="#faq15"><b>My local systems can't see
out to the net</b></a></p>
<h1>LOGGING<br>
</h1>
@ -135,8 +136,8 @@ I change my rules.
<h1>STARTING AND STOPPING<br>
</h1>
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using 'shorewall
stop', I can't connect to anything</b>. Why doesn't that command
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using
'shorewall stop', I can't connect to anything</b>. Why doesn't that command
work?</a></p>
<p align="left"><b>8. </b><a href="#faq8">When I try to <b>start Shorewall
@ -160,13 +161,14 @@ stop', I can't connect to anything</b>. Why doesn't that command
<p align="left"><b>10. </b><a href="#faq10">What <b>distributions</b> does
it work with?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it support?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Is there a <b>GUI?</b></a></p>
<p align="left"><b>13. </b><a href="#faq13">Why do you call it <b>"Shorewall"?</b></a></p>
<b>23. </b><a href="#faq23">Why do you use
such <b>ugly fonts</b> on your <b>web site</b>?</a><br>
<b>23. </b><a href="#faq23">Why do you
use such <b>ugly fonts</b> on your <b>web site</b>?</a><br>
<b><br>
25. </b><a href="#faq25">How to I tell <b>which version of Shorewall</b>
I am <b>running</b>?</a><br>
@ -182,8 +184,8 @@ me to configure/monitor it but as expected if I enable
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC
1918 address. If I enable RFC 1918 filtering on my external
interface, <b>my DHCP client cannot renew its lease</b>.</a></p>
1918 address. If I enable RFC 1918 filtering on my
external interface, <b>my DHCP client cannot renew its lease</b>.</a></p>
<h1>ALIAS IP ADDRESSES/VIRTUAL INTERFACES<br>
</h1>
@ -334,10 +336,10 @@ the PORT column specify the range as <i>low-port</i>:<i>high-port</i>.<b
<li>You are trying
to test from inside your firewall (no, that won't
work -- see <a href="#faq2">FAQ #2</a>).</li>
<li>You have a
more basic problem with your local system such as an
incorrect default gateway configured (it should be set to
the IP address of your firewall's internal interface).</li>
<li>You have
a more basic problem with your local system such as
an incorrect default gateway configured (it should be
set to the IP address of your firewall's internal interface).</li>
<li>Your ISP is blocking that particular port inbound.<br>
</li>
@ -361,8 +363,8 @@ diagnose this problem:<br>
zone&gt;</i>_dnat ('net_dnat' in the above examples).</li>
<li>Is the packet count
in the first column non-zero? If so, the connection
request is reaching the firewall and is being redirected
to the server. In this case, the problem is usually a missing
request is reaching the firewall and is being redirected to
the server. In this case, the problem is usually a missing
or incorrect default gateway setting on the server (the server's
default gateway should be the IP address of the firewall's
interface to the server).</li>
@ -379,8 +381,8 @@ your rule is only redirecting the primary IP address (You need
to specify the secondary IP address in the "ORIG. DEST." column
in your DNAT rule); or</li>
<li>your DNAT rule doesn't
match the connection request in some other way. In that
case, you may have to use a packet sniffer such as tcpdump
match the connection request in some other way. In
that case, you may have to use a packet sniffer such as tcpdump
or ethereal to further diagnose the problem.<br>
</li>
@ -389,8 +391,8 @@ or ethereal to further diagnose the problem.<br>
</ul>
<h4 align="left"><a name="faq1c"></a><b>1c. </b>From the internet, I want
to connect to port 1022 on my firewall and have the firewall forward the
connection to port 22 on local system 192.168.1.3. How do I do that?</h4>
to connect to port 1022 on my firewall and have the firewall forward
the connection to port 22 on local system 192.168.1.3. How do I do that?</h4>
<div align="left">
<blockquote>
@ -428,8 +430,8 @@ or ethereal to further diagnose the problem.<br>
</div>
<h4 align="left"><a name="faq2"></a>2. I port forward www requests to www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in my
local network. External clients can browse http://www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in
my local network. External clients can browse http://www.mydomain.com
but internal clients can't.</h4>
<p align="left"><b>Answer: </b>I have two objections to this setup.</p>
@ -438,19 +440,19 @@ or ethereal to further diagnose the problem.<br>
<li>Having an
internet-accessible server in your local network
is like raising foxes in the corner of your hen house. If
the server is compromised, there's nothing between
that server and your other internal systems. For the cost
of another NIC and a cross-over cable, you can put your
server in a DMZ such that it is isolated from your local systems
- assuming that the Server can be located near the Firewall,
of course :-)</li>
the server is compromised, there's nothing between that
server and your other internal systems. For the cost of
another NIC and a cross-over cable, you can put your server
in a DMZ such that it is isolated from your local systems -
assuming that the Server can be located near the Firewall, of course
:-)</li>
<li>The accessibility
problem is best solved using <a
href="shorewall_setup_guide.htm#DNS">Bind Version 9 "views"</a>
(or using a separate DNS server for local clients) such that www.mydomain.com
resolves to 130.141.100.69 externally and 192.168.1.5 internally.
That's what I do here at shorewall.net for my local systems
that use static NAT.</li>
resolves to 130.141.100.69 externally and 192.168.1.5
internally. That's what I do here at shorewall.net for my
local systems that use static NAT.</li>
</ul>
@ -462,8 +464,8 @@ of another NIC and a cross-over cable, you can put your
</p>
<p align="left">If you are running Shorewall 1.4.0 or earlier see <a
href="file:///Z:/Shorewall-docs/1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions
suitable for those releases.<br>
href="1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions suitable for
those releases.<br>
</p>
<p align="left">If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
@ -615,17 +617,17 @@ this in /etc/shorewall/init:</p>
so they can't access each other using their DNS names.</h4>
<p align="left"><b>Answer: </b>This is another problem that is best solved
using Bind Version 9 "views". It allows both external
and internal clients to access a NATed host using
the host's DNS name.</p>
using Bind Version 9 "views". It allows both
external and internal clients to access a NATed
host using the host's DNS name.</p>
<p align="left">Another good way to approach this problem is to switch from
static NAT to Proxy ARP. That way, the hosts in
Z have non-RFC1918 addresses and can be accessed externally
and internally using the same address. </p>
static NAT to Proxy ARP. That way, the hosts
in Z have non-RFC1918 addresses and can be accessed
externally and internally using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">a) Set the Z-&gt;Z policy to ACCEPT.<br>
b) Masquerade Z
@ -720,10 +722,11 @@ to itself.<br>
<p align="left"><b>Answer: </b>There is an <a
href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection
tracking/NAT module</a> that may help with Netmeeting.
Look <a href="http://linux-igd.sourceforge.net">here</a> for a
solution for MSN IM but be aware that there are significant security
risks involved with this solution. Also check the Netfilter mailing
list archives at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
Look <a href="http://linux-igd.sourceforge.net">here</a> for
a solution for MSN IM but be aware that there are significant security
risks involved with this solution. Also check the Netfilter
mailing list archives at <a
href="http://www.netfilter.org">http://www.netfilter.org</a>.
</p>
<h4 align="left"><a name="faq4"></a>4. I just used an online port scanner
@ -731,20 +734,20 @@ risks involved with this solution. Also check the Netfilter mailing
as 'closed' rather than 'blocked'. Why?</h4>
<p align="left"><b>Answer: </b>The common.def included with version 1.3.x
always rejects connection requests on TCP port
113 rather than dropping them. This is necessary
to prevent outgoing connection problems to services
that use the 'Auth' mechanism for identifying requesting
users. Shorewall also rejects TCP ports 135, 137 and 139
as well as UDP ports 137-139. These are ports that are used
by Windows (Windows <u>can</u> be configured to use the DCE cell
locator on port 135). Rejecting these connection requests rather
than dropping them cuts down slightly on the amount of Windows chatter
always rejects connection requests on TCP
port 113 rather than dropping them. This is necessary
to prevent outgoing connection problems to services that
use the 'Auth' mechanism for identifying requesting users.
Shorewall also rejects TCP ports 135, 137 and 139 as well
as UDP ports 137-139. These are ports that are used by Windows
(Windows <u>can</u> be configured to use the DCE cell locator
on port 135). Rejecting these connection requests rather than
dropping them cuts down slightly on the amount of Windows chatter
on LAN segments connected to the Firewall. </p>
<p align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web server
in violation of your Service Agreement.</p>
your ISP preventing you from running a web
server in violation of your Service Agreement.</p>
<h4 align="left"><a name="faq4a"></a>4a. I just ran an nmap UDP scan of my
firewall and it showed 100s of ports as open!!!!</h4>
@ -752,20 +755,22 @@ on LAN segments connected to the Firewall. </p>
<p align="left"><b>Answer: </b>Take a deep breath and read the nmap man page
section about UDP scans. If nmap gets <b>nothing</b>
back from your firewall then it reports the port
as open. If you want to see which UDP ports are really
open, temporarily change your net-&gt;all policy to REJECT,
as open. If you want to see which UDP ports are really open,
temporarily change your net-&gt;all policy to REJECT,
restart Shorewall and do the nmap UDP scan again.<br>
</p>
<h4><a name="faq4b"></a>4b. I have a port that I can't close no matter how
I change my rules. </h4>
I had a rule that allowed telnet from my local network to my firewall; I
removed that rule and restarted Shorewall but my telnet session still works!!!<br>
I had a rule that allowed telnet from my local network to my firewall;
I removed that rule and restarted Shorewall but my telnet session still
works!!!<br>
<br>
<b>Answer: </b> Rules only govern the establishment of new connections.
Once a connection is established through the firewall it will be usable until
disconnected (tcp) or until it times out (other protocols).  If you stop telnet
and try to establish a new session your firerwall will block that attempt.<br>
disconnected (tcp) or until it times out (other protocols).  If you stop
telnet and try to establish a new session your firerwall will block that
attempt.<br>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
can't ping through the firewall</h4>
@ -791,11 +796,11 @@ the first command in the file is ". /etc/shorewall/common.def"<br>
<h4 align="left"><a name="faq6"></a>6. Where are the log messages written
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure
to restart syslogd (on a RedHat system, "service syslog
@ -803,8 +808,8 @@ restart"). </p>
<p align="left">By default, older versions of Shorewall ratelimited log messages
through <a href="Documentation.htm#Conf">settings</a>
in /etc/shorewall/shorewall.conf -- If you want to
log all messages, set: </p>
in /etc/shorewall/shorewall.conf -- If you want
to log all messages, set: </p>
<div align="left">
<pre align="left"> LOGLIMIT=""<br> LOGBURST=""<br></pre>
@ -859,8 +864,8 @@ i exclude these error messages for this port temporarily from logging
<b>logunclean</b> option (<a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
on your external interface (eth0 in the above example). If they get
logged twice, they are corrupted. I solve this problem by using
an /etc/shorewall/common file like this:<br>
logged twice, they are corrupted. I solve this problem by using an
/etc/shorewall/common file like this:<br>
<blockquote>
<pre>#<br># Include the standard common.def file<br>#<br>. /etc/shorewall/common.def<br>#<br># The following rule is non-standard and compensates for tardy<br># DNS replies<br>#<br>run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</pre>
@ -898,10 +903,10 @@ an /etc/shorewall/common file like this:<br>
that command work?</h4>
<p align="left">The 'stop' command is intended to place your firewall into
a safe state whereby only those hosts listed in
/etc/shorewall/routestopped' are activated. If
you want to totally open up your firewall, you must use the
'shorewall clear' command. </p>
a safe state whereby only those hosts listed
in /etc/shorewall/routestopped' are activated.
If you want to totally open up your firewall, you must use
the 'shorewall clear' command. </p>
<h4 align="left"><a name="faq8"></a>8. When I try to start Shorewall on RedHat,
I get messages about insmod failing -- what's wrong?</h4>
@ -945,9 +950,9 @@ you want to totally open up your firewall, you must use the
</div>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The
Net zone is defined as all hosts that are connected through eth0 and the
local zone is defined as all hosts connected through eth1</p>
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
zone is defined as all hosts connected through eth1</p>
</div>
<h4 align="left"><a name="faq10"></a>10. What Distributions does it work
@ -978,18 +983,17 @@ local zone is defined as all hosts connected through eth1</p>
<h4 align="left"> <a name="faq14"></a>14. I'm connected via a cable modem
and it has an internal web server that allows
me to configure/monitor it but as expected if I enable
rfc1918 blocking for my eth0 interface (the internet one),
it also blocks the cable modems web server.</h4>
me to configure/monitor it but as expected if I
enable rfc1918 blocking for my eth0 interface (the internet
one), it also blocks the cable modems web server.</h4>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1
address of the modem in/out but still block all other
rfc1918 addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -1026,9 +1030,9 @@ following:</p>
</p>
<p align="left">Note: If you add a second IP address to your external firewall
interface to correspond to the modem address, you
must also make an entry in /etc/shorewall/rfc1918 for
that address. For example, if you configure the address
interface to correspond to the modem address,
you must also make an entry in /etc/shorewall/rfc1918
for that address. For example, if you configure the address
192.168.100.2 on your firewall, then you would add two entries
to /etc/shorewall/rfc1918: <br>
</p>
@ -1067,10 +1071,10 @@ following:</p>
</div>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable
RFC 1918 filtering on my external interface, my DHCP client cannot renew
its lease.</h4>
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.</h4>
</div>
<div align="left">
@ -1113,16 +1117,16 @@ firewall to the internet.</p>
<p align="left"><b>Answer: </b>"man dmesg" -- add a suitable 'dmesg' command
to your startup scripts or place it in /etc/shorewall/start.
Under RedHat, the max log level that is sent to
the console is specified in /etc/sysconfig/init in the
LOGLEVEL variable.<br>
Under RedHat, the max log level that is sent
to the console is specified in /etc/sysconfig/init in
the LOGLEVEL variable.<br>
</p>
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
logged?</h4>
<b>Answer: </b>Logging
occurs out of a number of chains (as indicated in
the log message) in Shorewall:<br>
occurs out of a number of chains (as indicated in the
log message) in Shorewall:<br>
<ol>
<li><b>man1918 - </b>The
@ -1134,25 +1138,26 @@ the log message) in Shorewall:<br>
with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>all2&lt;zone&gt;</b>,
<b>&lt;zone&gt;2all</b> or <b>all2all </b>-
You have a<a href="Documentation.htm#Policy"> policy</a> that specifies
a log level and this packet is being logged under that policy.
If you intend to ACCEPT this traffic then you need a <a
href="Documentation.htm#Rules">rule</a> to that effect.<br>
<b>&lt;zone&gt;2all</b> or <b>all2all
</b>- You have a<a href="Documentation.htm#Policy"> policy</a>
that specifies a log level and this packet is being
logged under that policy. If you intend to ACCEPT this
traffic then you need a <a href="Documentation.htm#Rules">rule</a> to
that effect.<br>
</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt;
</b>- Either you have a<a
href="Documentation.htm#Policy"> policy</a> for <b>&lt;zone1&gt;
</b>to <b>&lt;zone2&gt;</b> that specifies a log level and
this packet is being logged under that policy or this packet
matches a <a href="Documentation.htm#Rules">rule</a> that includes
a log level.</li>
matches a <a href="Documentation.htm#Rules">rule</a> that
includes a log level.</li>
<li><b>&lt;interface&gt;_mac</b>
- The packet is being logged under the <b>maclist</b>
<a href="Documentation.htm#Interfaces">interface option</a>.<br>
</li>
<li><b>logpkt</b> -
The packet is being logged under the <b>logunclean</b>
<li><b>logpkt</b>
- The packet is being logged under the <b>logunclean</b>
<a href="Documentation.htm#Interfaces">interface option</a>.</li>
<li><b>badpkt </b>-
The packet is being logged under the <b>dropunclean</b>
@ -1185,23 +1190,23 @@ syn packet. Options affecting the logging of such packets include
<h4><a name="faq18"></a>18. Is there any way to use <b>aliased ip addresses</b>
with Shorewall, and maintain separate rulesets for
different IPs?</h4>
<b>Answer: </b>Yes. See <a
href="Shorewall_and_Aliased_Interfaces.html">Shorewall and Aliased Interfaces</a>.
<b>Answer: </b>Yes. See
<a href="Shorewall_and_Aliased_Interfaces.html">Shorewall and Aliased Interfaces</a>.
<h4><b><a name="faq19"></a>19. </b>I have added entries to /etc/shorewall/tcrules
but they don't seem to do anything. Why?</h4>
You probably haven't set TC_ENABLED=Yes
in /etc/shorewall/shorewall.conf so the contents of the
tcrules file are simply being ignored.<br>
in /etc/shorewall/shorewall.conf so the contents of
the tcrules file are simply being ignored.<br>
<h4><a name="faq20"></a><b>20. </b>I have just set up a server. <b>Do I have
to change Shorewall to allow access to my server from
the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1216,34 +1221,34 @@ rules for your server.<br>
<b>Answer: </b>While most people
associate the Internet Control Message Protocol (ICMP)
with 'ping', ICMP is a key piece of the internet. ICMP is
used to report problems back to the sender of a packet; this is
what is happening here. Unfortunately, where NAT is involved (including
SNAT, DNAT and Masquerade), there are a lot of broken implementations.
That is what you are seeing with these messages.<br>
used to report problems back to the sender of a packet; this
is what is happening here. Unfortunately, where NAT is involved
(including SNAT, DNAT and Masquerade), there are a lot of broken
implementations. That is what you are seeing with these messages.<br>
<br>
Here is my interpretation of what
is happening -- to confirm this analysis, one would have to
have packet sniffers placed a both ends of the connection.<br>
is happening -- to confirm this analysis, one would have
to have packet sniffers placed a both ends of the connection.<br>
<br>
Host 172.16.1.10 behind NAT gateway
206.124.146.179 sent a UDP DNS query to 192.0.2.3 and your
DNS server tried to send a response (the response information
is in the brackets -- note source port 53 which marks this as a
DNS reply). When the response was returned to to 206.124.146.179,
it rewrote the destination IP TO 172.16.1.10 and forwarded the packet
to 172.16.1.10 who no longer had a connection on UDP port 2857.
This causes a port unreachable (type 3, code 3) to be generated back
to 192.0.2.3. As this packet is sent back through 206.124.146.179,
206.124.146.179 sent a UDP DNS query to 192.0.2.3 and
your DNS server tried to send a response (the response information
is in the brackets -- note source port 53 which marks this as
a DNS reply). When the response was returned to to 206.124.146.179,
it rewrote the destination IP TO 172.16.1.10 and forwarded the
packet to 172.16.1.10 who no longer had a connection on UDP port
2857. This causes a port unreachable (type 3, code 3) to be generated
back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has
no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
appear to be related to anything that was sent. The final result
is that the packet gets logged and dropped in the all2all chain. I have
also seen cases where the source IP in the ICMP itself isn't set back
to the external IP of the remote NAT gateway; that causes your firewall
to log and drop the packet out of the rfc1918 chain because the source
IP is reserved by RFC 1918.<br>
is that the packet gets logged and dropped in the all2all chain. I
have also seen cases where the source IP in the ICMP itself isn't set
back to the external IP of the remote NAT gateway; that causes your
firewall to log and drop the packet out of the rfc1918 chain because
the source IP is reserved by RFC 1918.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do
@ -1253,21 +1258,22 @@ one of the <a href="shorewall_extension_scripts.htm">Shorewall Extension
Scripts</a>. Be sure that you look at the contents of the chain(s) that
you will be modifying with your commands to be sure that the
commands will do what they are intended. Many iptables commands
published in HOWTOs and other instructional material use the -A
command which adds the rules to the end of the chain. Most chains
that Shorewall constructs end with an unconditional DROP, ACCEPT or
REJECT rule and any rules that you add after that will be ignored.
Check "man iptables" and look at the -I (--insert) command.<br>
published in HOWTOs and other instructional material use the -A command
which adds the rules to the end of the chain. Most chains that Shorewall
constructs end with an unconditional DROP, ACCEPT or REJECT rule and
any rules that you add after that will be ignored. Check "man iptables"
and look at the -I (--insert) command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
The Shorewall web site is almost font neutral
(it doesn't explicitly specify fonts except on a few pages)
so the fonts you see are largely the default fonts configured in
your browser. If you don't like them then reconfigure your browser.<br>
(it doesn't explicitly specify fonts except on a few pages) so
the fonts you see are largely the default fonts configured in your
browser. If you don't like them then reconfigure your browser.<br>
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
the ssh port only<b> from specific IP Addresses</b> on the internet?</h4>
the ssh port only<b> from specific IP Addresses</b> on the
internet?</h4>
In the SOURCE column of the rule, follow "net"
by a colon and a list of the host/subnet addresses as a comma-separated
list.<br>
@ -1294,5 +1300,6 @@ your browser. If you don't like them then reconfigure your browser.<br>
<br>
<br>
<br>
<br>
</body>
</html>

75
STABLE/documentation/Install.htm
View File

@ -30,8 +30,8 @@
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
<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>
@ -48,26 +48,26 @@ to read and print a copy of the <a
<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
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>
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
<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>
(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
     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 -ivh
@ -78,8 +78,8 @@ diagnostic:<br>
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
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>
@ -90,8 +90,8 @@ clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<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>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
@ -117,14 +117,14 @@ be started automatically at boot, see <a
<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>
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
<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
@ -134,15 +134,15 @@ your /etc/shorewall/interfaces file to be sure that it contains an entry
<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").
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
<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>
@ -153,27 +153,27 @@ your /etc/shorewall/interfaces file to be sure that it contains an entry
--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>
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall (shorewall restart).</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><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>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>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
@ -189,8 +189,8 @@ for details. </p>
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>
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
</ul>
@ -201,8 +201,8 @@ distribution installs init scripts and type "./install.sh
<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
<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>
@ -215,5 +215,6 @@ distribution installs init scripts and type "./install.sh
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
</body>
</html>

1609
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

52
STABLE/documentation/errata.htm
View File

@ -80,8 +80,8 @@ Issues</a></b></li>
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="#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>
@ -93,6 +93,29 @@ iptables</a></b></li>
<h3></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>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.2</h3>
<ul>
@ -125,7 +148,8 @@ This problem is corrected in <a
<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>
     /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"
@ -172,11 +196,11 @@ have also built an <a
<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
@ -232,8 +256,8 @@ option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i3
<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>
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
@ -259,16 +283,16 @@ running Shorewall 1.3.6 you may
<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>
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>
<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>
</body>
</html>

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

Binary file not shown.

226
STABLE/documentation/seattlefirewall_index.htm
View File

@ -7,27 +7,31 @@
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">
<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></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>
@ -62,44 +66,50 @@
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<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
<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
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>
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>
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>
@ -111,12 +121,13 @@ 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>
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
@ -128,16 +139,66 @@ if you uninstall what you have and install a setup that matches the documentati
<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>
</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><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>(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>
<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>
</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>
@ -150,30 +211,31 @@ convention:<br>
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"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
<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>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
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>
<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>
@ -181,11 +243,14 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
@ -197,36 +262,43 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
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>
<ol>
</ol>
</blockquote>
<p><a href="News.htm">More News</a></p>
@ -234,25 +306,26 @@ well to view the presentation.<br>
<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>
<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 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">
@ -264,14 +337,15 @@ well to view the presentation.<br>
<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>
@ -286,6 +360,7 @@ well to view the presentation.<br>
</tbody>
</table>
</center>
</div>
@ -293,9 +368,11 @@ well to view the presentation.<br>
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td
width="100%" style="margin-top: 1px;">
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
@ -306,20 +383,25 @@ well to view the presentation.<br>
<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
<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>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

421
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">
<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">
<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>
<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
<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>
<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><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>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>
<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
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 (&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
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>
<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
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>
<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
<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
<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>
<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>
<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>

181
STABLE/documentation/sourceforge_index.htm
View File

@ -7,7 +7,8 @@
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<base target="_self">
<base
target="_self">
</head>
<body>
@ -16,18 +17,21 @@
bgcolor="#4b017c">
<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><font color="#ffffff">Shorewall 1.4 -
<font size="4">"<i>iptables made easy"</i></font></font><br>
</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>
@ -47,28 +51,32 @@
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<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>
(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
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>
@ -82,11 +90,12 @@ This program is distributed in the hope
<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>
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>
@ -96,32 +105,83 @@ You should have received a copy of the GNU
<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>
<h2><b>News</b></h2>
<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>
</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><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>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>
<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>
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>
<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>
@ -134,19 +194,19 @@ convention:<br>
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"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
<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>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
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>
@ -155,10 +215,10 @@ is enforced.<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 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>
@ -166,11 +226,14 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
@ -190,6 +253,7 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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
@ -198,13 +262,16 @@ 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>
<ol>
</ol>
</blockquote>
@ -214,14 +281,17 @@ to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
<b> </b>
<p><b><a href="News.htm">More News</a></b></p>
<b> </b>
<h2><b> </b></h2>
<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)">
@ -229,13 +299,13 @@ to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
</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>
<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"
@ -245,15 +315,18 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<b> </b>
<h4><b> </b></h4>
<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>
<h2><b><a name="Donations"></a>Donations</b></h2>
<b> </b></td>
@ -263,6 +336,7 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<form method="post"
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
@ -277,9 +351,11 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
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
@ -295,13 +371,17 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
</tbody>
</table>
</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;">
@ -316,21 +396,26 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<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
<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>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

103
STABLE/documentation/support.htm
View File

@ -29,9 +29,9 @@
<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.
There
are a number of sources of Shorewall information. Please try these
before you post.
<ul>
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
@ -42,8 +42,8 @@ list have answers directly accessible from the <a
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>
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
@ -69,11 +69,13 @@ list have answers directly accessible from the <a
<option value="boolean">Boolean </option>
</select>
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -102,21 +104,21 @@ list have answers directly accessible from the <a
<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>
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>
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>
@ -145,10 +147,11 @@ you are running.<br>
</ul>
<ul>
<li>the exact kernel version you are
running<br>
<li>the exact kernel version you
are running<br>
<br>
<font color="#009900"><b>uname -a<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
@ -209,8 +212,8 @@ the exact output from<br>
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>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
@ -226,16 +229,17 @@ the SMTP headers of your post).<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>
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>
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
@ -245,8 +249,8 @@ you have modified that file) that you think are relevant
<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>
post GIFs of your network layout, etc.
to the Mailing List -- your post will be rejected.</b></li>
</ul>
@ -258,39 +262,33 @@ the Mailing List -- your post will be rejected.</b></li>
<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>
<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>
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
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>
@ -309,11 +307,10 @@ output, use the appropriate mailing list below.</b><br>
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 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>

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

@ -42,8 +42,8 @@
local network.</li>
<li>Single public IP address.</li>
<li>DMZ connected to a separate ethernet interface.</li>
<li>Connection through DSL, Cable Modem, ISDN, Frame Relay,
dial-up, ...</li>
<li>Connection through DSL, Cable Modem, ISDN, Frame
Relay, dial-up, ...</li>
</ul>
@ -55,9 +55,9 @@ local network.</li>
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b>
program on your firewall system. As root, you can use the 'which'
command to check for this program:</p>
tell if this package is installed by the presence of an <b>ip</b> program
on your firewall system. As root, you can use the 'which' command
to check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -79,11 +79,12 @@ floppy disk, you must run dos2unix against the copy before using it with
Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
href="http://www.simtel.net/pub/pd/51438.html">Windows Version of
dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version of
dos2unix</a></li>
</ul>
@ -246,9 +247,9 @@ and make any changes that you wish.</p>
</p>
<p align="left">The firewall has three network interfaces. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External
Interface</i> will be the ethernet adapter that is connected to
that "Modem" (e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter that is connected to that "Modem" (e.g.,
<b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
@ -270,15 +271,15 @@ the computer using a <i>cross-over </i> cable).</p>
<p align="left">Your <i>DMZ Interface</i> will also be an ethernet adapter
(eth0, eth1 or eth2) and will be connected to a hub or switch. Your
DMZ computers will be connected to the same switch (note: If you have
only a single DMZ system, you can connect the firewall directly to
the computer using a <i>cross-over </i> cable).</p>
only a single DMZ system, you can connect the firewall directly to the
computer using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect more than one interface to the same
hub or switch (even for testing). It won't work the way that you
expect it to and you will end up confused and believing that Shorewall
doesn't work at all.</p>
hub or switch (even for testing). It won't work the way that you expect
it to and you will end up confused and believing that Shorewall doesn't
work at all.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
@ -286,8 +287,8 @@ doesn't work at all.</p>
that the external interface is <b>eth0, </b>the local interface is
<b>eth1 </b>and the DMZ interface is <b> eth2</b>. If your configuration
is different, you will have to modify the sample /etc/shorewall/interfaces
file accordingly. While you are there, you may wish to review the
list of options that are specified for the interfaces. Some hints:</p>
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
<ul>
<li>
@ -335,14 +336,14 @@ IP address of your external interface and if it is one of the above
<p align="left">You will want to assign your local addresses from one <i>
sub-network </i>or <i>subnet</i> and your DMZ addresses from another
subnet. For our purposes, we can consider a subnet to consists of
a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have
a <i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved
a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a
<i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved
as the <i>Subnet Address</i> and x.y.z.255 is reserved as the <i>Subnet
Broadcast</i> <i>Address</i>. In Shorewall, a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR)</a> notation with consists of the subnet address followed
by "/24". The "24" refers to the number of consecutive "1" bits
from the left of the subnet mask. </p>
by "/24". The "24" refers to the number of consecutive "1" bits from
the left of the subnet mask. </p>
</div>
<div align="left">
@ -418,34 +419,34 @@ Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP  might assign
your external interface an RFC 1918 address. If that address is in the
10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918
subnet for your local network and if it is in the 10.10.11.0/24 subnet then
you will need to select a different RFC 1918 subnet for your DMZ.</b><br>
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP  might
assign your external interface an RFC 1918 address. If that address is
in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
1918 subnet for your local network and if it is in the 10.10.11.0/24 subnet
then you will need to select a different RFC 1918 subnet for your DMZ.</b><br>
</p>
<p align="left">IP Masquerading (SNAT)</p>
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When
one of your local systems (let's assume local computer 1) sends a
connection request to an internet host, the firewall must perform
<i>Network Address Translation </i>(NAT). The firewall rewrites the
source address in the packet to be the address of the firewall's external
interface; in other words, the firewall makes it look as if the firewall
itself is initiating the connection.  This is necessary so that the
destination host will be able to route return packets back to the firewall
(remember that packets whose destination address is reserved by RFC
1918 can't be routed accross the internet). When the firewall receives
a return packet, it rewrites the destination address back to 10.10.10.1
and forwards the packet on to local computer 1. </p>
forward packets which have an RFC-1918 destination address. When one
of your local systems (let's assume local computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network
Address Translation </i>(NAT). The firewall rewrites the source address
in the packet to be the address of the firewall's external interface;
in other words, the firewall makes it look as if the firewall itself
is initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed accross the internet). When the firewall receives a return
packet, it rewrites the destination address back to 10.10.10.1 and forwards
the packet on to local computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> and you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> and you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<ul>
<li>
@ -466,15 +467,15 @@ with Netfilter:</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If your external firewall interface is <b>eth0</b>, your
local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b>
    If your external firewall interface is <b>eth0</b>,
your local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b>
then you do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change it to match your configuration.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If your external IP is static, you can enter it in the
third column in the /etc/shorewall/masq entry if you like although
    If your external IP is static, you can enter it in
the third column in the /etc/shorewall/masq entry if you like although
your firewall will work fine if you leave that column empty. Entering
your static IP in column 3 makes <br>
processing outgoing packets a little more efficient.<br>
@ -501,9 +502,9 @@ change them appropriately:<br>
is not possible for clients on the internet to connect directly to
them. It is rather necessary for those clients to address their connection
requests to your firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to
rewrite the source address in the response.</p>
address of your server and forwards the packet to that server. When your
server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -540,8 +541,8 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
</table>
</blockquote>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to
be the same as <i>&lt;port&gt;</i>.</p>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to be
the same as <i>&lt;port&gt;</i>.</p>
<p>Example - you run a Web Server on DMZ 2 and you want to forward incoming
TCP port 80 to that system:</p>
@ -585,13 +586,13 @@ be the same as <i>&lt;port&gt;</i>.</p>
<p>A couple of important points to keep in mind:</p>
<ul>
<li>When you are connecting to your server from your local
systems, you must use the server's internal IP address (10.10.11.2).</li>
<li>When you are connecting to your server from your
local systems, you must use the server's internal IP address (10.10.11.2).</li>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000 (e.g., connect to <a
href="http://w.x.y.z:5000"> http://w.x.y.z:5000</a> where w.x.y.z is your
external IP).</li>
following rule and try connecting to port 5000 (e.g., connect to
<a href="http://w.x.y.z:5000"> http://w.x.y.z:5000</a> where w.x.y.z
is your external IP).</li>
</ul>
@ -727,15 +728,15 @@ as your primary and secondary name servers. It is <u>your</u> responsibili
width="13" height="13">
    You can configure a<i> Caching Name Server </i>on your
firewall or in your DMZ.<i> </i>Red Hat has an RPM for a caching
name server (which also requires the 'bind' RPM) and for Bering
users, there is dnscache.lrp. If you take this approach, you configure
your internal systems to use the caching name server as their primary
(and only) name server. You use the internal IP address of the firewall
(10.10.10.254 in the example above) for the name server address if
you choose to run the name server on your firewall. To allow your local
systems to talk to your caching name server, you must open port 53
(both UDP and TCP) from the local network to the server; you do that
by adding the rules in /etc/shorewall/rules. </p>
name server (which also requires the 'bind' RPM) and for Bering users,
there is dnscache.lrp. If you take this approach, you configure your
internal systems to use the caching name server as their primary (and
only) name server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address if you choose to
run the name server on your firewall. To allow your local systems to
talk to your caching name server, you must open port 53 (both UDP
and TCP) from the local network to the server; you do that by adding
the rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -1020,7 +1021,8 @@ allowing all connections from the firewall to the internet.</p>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>udp<br>
</td>
<td>53</td>
<td>#Allow DNS access</td>
<td>from the internet</td>
@ -1043,8 +1045,8 @@ uses, look <a href="ports.htm">here</a>.</p>
<div align="left">
<p align="left"><b>Important: </b>I don't recommend enabling telnet to/from
the internet because it uses clear text (even for login!). If
you want shell access to your firewall from the internet, use SSH:</p>
the internet because it uses clear text (even for login!). If you
want shell access to your firewall from the internet, use SSH:</p>
</div>
<div align="left">
@ -1130,8 +1132,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Now modify /etc/shorewall/rules to add or remove other
connections as required.</p>
    Now modify /etc/shorewall/rules to add or remove
other connections as required.</p>
</div>
<div align="left">
@ -1144,8 +1146,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
    The <a href="Install.htm">installation procedure </a>
configures your system to start Shorewall at system boot  but beginning
with Shorewall version 1.3.9 startup is disabled so that your system
won't try to start Shorewall before configuration is complete. Once you
have completed configuration of your firewall, you can enable Shorewall
won't try to start Shorewall before configuration is complete. Once
you have completed configuration of your firewall, you can enable Shorewall
startup by removing the file /etc/shorewall/startup_disabled.<br>
</p>
@ -1168,11 +1170,11 @@ startup by removing the file /etc/shorewall/startup_disabled.<br>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    The three-interface sample assumes that you want to enable
routing to/from <b>eth1 (</b>your local network) and<b> eth2 </b>(DMZ)
when Shorewall is stopped. If these two interfaces don't connect
to your local network and DMZ or if you want to enable a different
set of hosts, modify /etc/shorewall/routestopped accordingly.</p>
    The three-interface sample assumes that you want to
enable routing to/from <b>eth1 (</b>your local network) and<b> eth2
</b>(DMZ) when Shorewall is stopped. If these two interfaces don't
connect to your local network and DMZ or if you want to enable a
different set of hosts, modify /etc/shorewall/routestopped accordingly.</p>
</div>
<div align="left">
@ -1180,33 +1182,17 @@ startup by removing the file /etc/shorewall/startup_disabled.<br>
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to
create an <i><a href="configuration_file_basics.htm#Configs">alternate
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/21/2003 - <a
<p align="left"><font size="2">Last updated 5/19/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Thomas M. Eastep</font></a><br>
</p>
</body>
</html>

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

@ -32,14 +32,14 @@
<p align="left"><small><i><u>Notes du traducteur</u> :<br>
Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une
traduction exacte du texte, mais plutôt à en faire une version française intelligible
par tous (et par moi). Les termes techniques sont la plupart du temps conservés
sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver
dans le reste des documentations ainsi que dans les fichiers de configuration.
N?hésitez pas à me contacter afin d?améliorer ce document <a
href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice</a> (merci à JMM
pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour
son formidable outil et sa disponibilité).</i></small></p>
traduction exacte du texte, mais plutôt à en faire une version française
intelligible par tous (et par moi). Les termes techniques sont la plupart
du temps conservés sous leur forme originale et mis entre parenthèses car
vous pouvez les retrouver dans le reste des documentations ainsi que dans
les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer
ce document <a href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice</a>
(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à
Tom EASTEP pour son formidable outil et sa disponibilité).</i></small></p>
<p align="left"><br>
Mettre en place un système linux en tant que firewall pour un petit réseau
@ -66,27 +66,27 @@ son formidable outil et sa disponibilit
height="635">
</p>
<p>Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé.
Vous pouvez voir si le paquet est installé en vérifiant la présence du programme
<p>Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous
pouvez voir si le paquet est installé en vérifiant la présence du programme
ip sur votre système de firewall. Sous root, utilisez la commande 'which'
pour rechercher le programme :</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>Je vous recommande dans un premier temps de parcourir tout le guide pour
vous familiariser avec ce qu'il va se passer, et de revenir au début en
effectuant le changements dans votre configuration. Les points où, les changements
dans la configuration sont recommandées, sont signalés par une <img
vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant
le changements dans votre configuration. Les points où, les changements dans
la configuration sont recommandées, sont signalés par une <img
border="0" src="images/BD21298_.gif" width="13" height="13">
</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
Si vous éditez vos fichiers de configuration sur un système Windows, vous
devez les sauver comme des fichiers Unix si votre éditeur offre cette option
sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser.
De la même manière, si vous copiez un fichier de configuration depuis votre
disque dur Windows vers une disquette, vous devez lancer dos2unix sur la
copie avant de l'utiliser avec Shorewall.</p>
Si vous éditez vos fichiers de configuration sur un système Windows,
vous devez les sauver comme des fichiers Unix si votre éditeur offre cette
option sinon vous devez les faire passer par dos2unix avant d'essayer de
les utiliser. De la même manière, si vous copiez un fichier de configuration
depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix
sur la copie avant de l'utiliser avec Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
@ -144,8 +144,8 @@ Shorewall)</b>.</p>
<p>Les noms de zone sont définis dans <a href="Documentation.htm#Zones">/etc/shorewall/zones</a>.</p>
<p>Shorewall reconnaît aussi le système de firewall comme sa propre zone
- par défaut, le firewall lui même est connu en tant que <b>fw</b>.</p>
<p>Shorewall reconnaît aussi le système de firewall comme sa propre zone -
par défaut, le firewall lui même est connu en tant que <b>fw</b>.</p>
<p>Les règles concernant le trafic à autoriser ou à interdire sont exprimées
en utilisant les termes de zones.</p>
@ -243,7 +243,8 @@ ce fichier).</p>
<p>Les politiques précédentes vont :</p>
<ol>
<li>permettre toutes demandes de connexion depuis le firewall vers l'Internet</li>
<li>permettre toutes demandes de connexion depuis le firewall vers
l'Internet</li>
<li>drop (ignorer) toutes les demandes de connexion depuis l'Internet
vers votre firewall ou vers votre réseau local</li>
<li>Facultativement accepter toutes les demandes de connexion depuis
@ -269,8 +270,8 @@ votre firewall et vers Internet (si vous decommentez la politique pr
connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling
Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de
type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC),
votre interface extérieure sera aussi ppp0. Si votre connexion passe par
Numéris (ISDN), votre interface extérieure sera ippp0<b>.</b></p>
votre interface extérieure sera aussi ppp0. Si votre connexion passe par Numéris
(ISDN), votre interface extérieure sera ippp0<b>.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
@ -285,24 +286,24 @@ Num
<p align="left">Votre <i>interface DMZ</i> sera aussi un adaptateur Ethernet
(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs
appartenant à la DMZ seront connectés à ce même switch (note : si vous
n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement
au firewall par un <i>câble croisé</i>).</p>
appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez
qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au
firewall par un <i>câble croisé</i>).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u> Ne connectez pas l'interface interne et externe sur le même hub
ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas
que ce soit shorewall qui ne marche pas.</p>
ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que
ce soit shorewall qui ne marche pas.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
L'exemple de configuration de Shorewall pour trois interfaces suppose
que l'interface externe est <b>eth0, </b>l'interface locale est <b>eth1
</b> et que la DMZ est sur l'interface <b>eth2</b>. Si votre configuration
diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces
en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des
options qui sont spécifiées pour les interfaces. Quelques trucs :</p>
que l'interface externe est <b>eth0, </b>l'interface locale est <b>eth1 </b>
et que la DMZ est sur l'interface <b>eth2</b>. Si votre configuration diffère,
vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence.
Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont
spécifiées pour les interfaces. Quelques trucs :</p>
<ul>
<li>
@ -310,9 +311,9 @@ options qui sont sp
remplacer le "detect" dans la seconde colonne par un "-". </p>
</li>
<li>
<p align="left">Si votre interface externe est ppp0 ou ippp0 ou bien
si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la
liste d'option. </p>
<p align="left">Si votre interface externe est ppp0 ou ippp0 ou bien si
vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la liste
d'option. </p>
</li>
</ul>
@ -324,15 +325,14 @@ liste d'option. </p>
Internet (ISP) vous assignera une seule adresse IP (single Public IP address).
Cette adresse peut être assignée par le Dynamic Host Configuration Protocol
(DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez
(modem standard) ou établissez votre connexion PPP. Dans de rares cas ,
votre provider peu vous assigner une adresse statique (staticIP address);
cela signifie que vous configurez votre interface externe sur votre firewall
afin d'utiliser cette adresse de manière permanente. Une fois votre adresse
externe assignée, elle va être partagée par tout vos systèmes lors de l'accès
à Internet. Vous devrez assigner vos propres adresses à votre réseau local
(votre interface interne sur le firewall ainsi que les autres ordinateurs).
La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à
cette fin :</p>
(modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre
provider peu vous assigner une adresse statique (staticIP address); cela
signifie que vous configurez votre interface externe sur votre firewall afin
d'utiliser cette adresse de manière permanente. Une fois votre adresse externe
assignée, elle va être partagée par tout vos systèmes lors de l'accès à Internet.
Vous devrez assigner vos propres adresses à votre réseau local (votre interface
interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918
réserve plusieurs plages d'IP (Private IP address ranges) à cette fin :</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -353,12 +353,12 @@ cette fin :</p>
en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera
une masque (<i>Subnet Mask)</i> de 255.255.255.0. L'adresse x.y.z.0 est
réservée comme l'adresse du sous-réseau (<i>Subnet Address)</i> et x.y.z.255
est réservée en tant qu'adresse de broadcast du sous-réseau (<i>Subnet
Broadcast</i> <i>Address)</i>. Sous Shorewall, un sous-réseau est décrit/désigné
en utilisant la notation <a href="shorewall_setup_guide.htm#Subnets"><i>Classless
InterDomain Routing</i>(CIDR)</a> qui consiste en l'adresse du sous-réseau
suivie par "/24". Le "24" se réfère au nombre de bits "1" consécutifs dans
la partie gauche du masque de sous-réseau. </p>
est réservée en tant qu'adresse de broadcast du sous-réseau (<i>Subnet Broadcast</i>
<i>Address)</i>. Sous Shorewall, un sous-réseau est décrit/désigné en utilisant
la notation <a href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain
Routing</i>(CIDR)</a> qui consiste en l'adresse du sous-réseau suivie par
"/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie
gauche du masque de sous-réseau. </p>
</div>
<div align="left">
@ -393,17 +393,17 @@ la partie gauche du masque de sous-r
</div>
<div align="left">
<p align="left">Il est de convention d'assigner à l'interface interne la
première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple
précédent) ou la dernière utilisable (10.10.10.254).</p>
<p align="left">Il est de convention d'assigner à l'interface interne la première
adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple précédent)
ou la dernière utilisable (10.10.10.254).</p>
</div>
<div align="left">
<p align="left">L'un des buts d'un sous-réseau est de permettre à tous les
ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs
ils peuvent communiquer directement. Pour communiquer avec des systèmes
en dehors du sous-réseau, les ordinateurs envoient des paquets à travers
le gateway (routeur).</p>
ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils
peuvent communiquer directement. Pour communiquer avec des systèmes en dehors
du sous-réseau, les ordinateurs envoient des paquets à travers le gateway
(routeur).</p>
</div>
<div align="left">
@ -417,8 +417,8 @@ pointant sur l'adresse IP de l'interface DMZ du firewall. </p>
</div>
<p align="left">Cette courte description ne fait que survoler les concepts
de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur
l'adressage IP et le routage, je vous recommande chaudement <i>"IP Fundamentals:
de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage
IP et le routage, je vous recommande chaudement <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i> Thomas
A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
@ -451,10 +451,9 @@ rout
l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur
1. </p>
<p align="left">Sur les systèmes Linux, ce procédé est souvent appelé de
l'IP Masquerading mais vous verrez aussi le terme de Source Network Address
Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter
:</p>
<p align="left">Sur les systèmes Linux, ce procédé est souvent appelé de l'IP
Masquerading mais vous verrez aussi le terme de Source Network Address Translation
(SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter :</p>
<ul>
<li>
@ -483,8 +482,8 @@ Translation (SNAT) utilis
Si votre IP externe est statique, vous pouvez la mettre dans la troisième
colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre
firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de
mettre votre IP statique dans la troisième colonne permet un traitement
des paquets sortant un peu plus efficace.<br>
mettre votre IP statique dans la troisième colonne permet un traitement des
paquets sortant un peu plus efficace.<br>
</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
@ -507,10 +506,10 @@ des paquets sortant un peu plus efficace.<br>
serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse
RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter
directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes
de connexion au firewall qui ré écrit l'adresse de destination de votre
serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond,
le firewall applique automatiquement un SNAT pour ré écrire l'adresse source
dans la réponse.</p>
de connexion au firewall qui ré écrit l'adresse de destination de votre serveur,
et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall
applique automatiquement un SNAT pour ré écrire l'adresse source dans la
réponse.</p>
<p align="left">Ce procédé est appelé Port Forwarding ou Destination Network
Address Translation(DNAT). Vous configurez le port forwarding en utilisant
@ -635,10 +634,10 @@ IP externe).</li>
</table>
</blockquote>
<p>Si vous voulez avoir la possibilité de vous connecter à votre serveur
depuis le réseau local en utilisant votre adresse externe, et si vous avez
une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc-&gt;dmz
précédente par :</p>
<p>Si vous voulez avoir la possibilité de vous connecter à votre serveur depuis
le réseau local en utilisant votre adresse externe, et si vous avez une adresse
IP externe statique (fixe), vous pouvez remplacer la règle loc-&gt;dmz précédente
par :</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -709,8 +708,8 @@ pr
</table>
</blockquote>
<p>Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre
adresse IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p>Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre adresse
IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p><img border="0" src="images/BD21298_2.gif" width="13" height="13">
A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..</p>
@ -719,21 +718,21 @@ adresse IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p align="left">Normalement, quand vous vous connectez à votre fournisseur
(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le
firewall (Domain Name Service) est configuré automatiquement (c.a.d., le
fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous
donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez
manuellement votre serveur de nom primaire et secondaire. La manière dont
le DNS est configuré sur votre firewall est de votre responsabilité. Vous
pouvez procéder d'une de ses deux façons :</p>
firewall (Domain Name Service) est configuré automatiquement (c.a.d., le fichier
/etc/resolv.conf a été écrit). Il arrive que votre provider vous donne une
paire d'adresse IP pour les DNS (name servers) afin que vous configuriez manuellement
votre serveur de nom primaire et secondaire. La manière dont le DNS est configuré
sur votre firewall est de votre responsabilité. Vous pouvez procéder d'une
de ses deux façons :</p>
<ul>
<li>
<p align="left">Vous pouvez configurer votre système interne pour utiliser
les noms de serveurs de votre provider. Si votre fournisseur vous donne
les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur
site web, vous pouvez configurer votre système interne afin de les utiliser.
Si cette information n'est pas disponible, regardez dans /etc/resolv.conf
sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement
les noms de serveurs de votre provider. Si votre fournisseur vous donne les
adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site
web, vous pouvez configurer votre système interne afin de les utiliser. Si
cette information n'est pas disponible, regardez dans /etc/resolv.conf sur
votre firewall -- les noms des serveurs sont donnés dans l'enregistrement
"nameserver" dans ce fichier. </p>
</li>
<li>
@ -743,13 +742,13 @@ sur votre firewall -- les noms des serveurs sont donn
votre firewall ou dans la DMZ.<i> </i>Red Hat a un RPM pour mettre en cache
un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs
de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez
votre système interne pour utiliser le firewall lui même comme étant le
seul serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne
du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom
si vous décidez de faire tourner le serveur de nom sur votre firewall. Pour
permettre à vos systèmes locaux de discuter avec votre serveur cache de
nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le
réseau local; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.
votre système interne pour utiliser le firewall lui même comme étant le seul
serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall
(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez
de faire tourner le serveur de nom sur votre firewall. Pour permettre à
vos systèmes locaux de discuter avec votre serveur cache de nom, vous devez
ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous
ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.
</p>
</li>
@ -1063,7 +1062,8 @@ r
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>udp<br>
</td>
<td>53</td>
<td>#permet les accès DNS</td>
<td>depuis Internet</td>
@ -1138,11 +1138,11 @@ firewall depuis Internet, utilisez SSH :</p>
<p align="left"> <img border="0" src="images/BD21298_2.gif" width="13"
height="13" alt="Arrow">
La <a href="Install.htm">procédure d'installation</a> configure votre
système pour lancer Shorewall au boot du système, mais au début avec la
version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de
lancer Shorewall avec que la configuration soit finie. Une fois que vous
en avez fini avec la configuration du firewall, vous pouvez permettre le
lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.<br>
système pour lancer Shorewall au boot du système, mais au début avec la version
1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall
avec que la configuration soit finie. Une fois que vous en avez fini avec
la configuration du firewall, vous pouvez permettre le lancement de Shorewall
en supprimant le fichier /etc/shorewall/startup_disabled.<br>
</p>
<p align="left">IMPORTANT: Les utilisateurs des paquets .deb doivent éditer
@ -1152,8 +1152,8 @@ lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled
<div align="left">
<p align="left">Le firewall est activé en utilisant la commande "shorewall
start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé,
le routage est autorisé sur les hôtes qui possèdent une entrée dans <a
start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le
routage est autorisé sur les hôtes qui possèdent une entrée dans <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. Un
firewall qui tourne peut être relancé en utilisant la commande "shorewall
restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration
@ -1163,18 +1163,19 @@ le routage est autoris
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
L'exemple pour trois interfaces suppose que vous voulez permettre le routage
depuis/vers <b>eth1 </b>(votre réseau local) et<b> eth2</b>(DMZ) lorsque
Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées
à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble
d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.</p>
L'exemple pour trois interfaces suppose que vous voulez permettre le
routage depuis/vers <b>eth1 </b>(votre réseau local) et<b> eth2</b>(DMZ)
lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas
connectées à votre réseau local et votre DMZ, ou si vous voulez permettre
un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en
conséquence.</p>
</div>
<div align="left">
<p align="left">ATTENTION: Si vous êtes connecté à votre firewall depuis
Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez
pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous
êtes connectée) dans <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
<p align="left">ATTENTION: Si vous êtes connecté à votre firewall depuis Internet,
n'essayez pas une commande "shorewall stop" tant que vous n'avez pas ajouté
une entrée pour votre adresse IP (celle à partir de laquelle vous êtes connectée)
dans <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
De la même manière, je ne vous recommande pas d'utiliser "shorewall restart";
il est plus intéressant de créer une <i><a
href="configuration_file_basics.htm#Configs">configuration </a></i><i><a
@ -1183,31 +1184,11 @@ pas ajout
href="starting_and_stopping_shorewall.htm">"shorewall try"</a>.</p>
</div>
<p align="left"><font size="2">Last updated 12/20/2002 - <a
<p align="left"><font size="2">Last updated 05/19/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002 Thomas
M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a><br>
</p>
</body>
</html>

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

@ -30,8 +30,8 @@
</table>
<p align="left">Setting up a Linux system as a firewall for a small network
is a fairly straight-forward task if you understand the basics
and follow the documentation.</p>
is a fairly straight-forward task if you understand the basics and
follow the documentation.</p>
<p>This guide doesn't attempt to acquaint you with all of the features of
Shorewall. It rather focuses on what is required to configure Shorewall
@ -59,8 +59,8 @@ and follow the documentation.</p>
</b></p>
<p><b>Note however, that the Shorewall configuration produced by Mandrake
Internet Connection Sharing is strange and is apt to confuse you if you
use the rest of this documentation (it has two local zones; "loc" and "masq"
Internet Connection Sharing is strange and is apt to confuse you if you use
the rest of this documentation (it has two local zones; "loc" and "masq"
where "loc" is empty; this conflicts with this documentation which assumes
a single local zone "loc"). We therefore recommend that once you have set
up this sharing that you uninstall the Mandrake Shorewall RPM and install
@ -71,16 +71,16 @@ instructions in this Guide.</b><br>
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b>
program on your firewall system. As root, you can use the 'which'
command to check for this program:</p>
program on your firewall system. As root, you can use the 'which' command
to check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>I recommend that you first read through the guide to familiarize yourself
with what's involved then go back through it again making your
configuration changes. Points at which configuration changes are
recommended are flagged with <img border="0"
src="images/BD21298_.gif" width="13" height="13">
with what's involved then go back through it again making your configuration
changes. Points at which configuration changes are recommended
are flagged with <img border="0" src="images/BD21298_.gif"
width="13" height="13">
. Configuration notes that are unique to LEAF/Bering are
marked with <img src="images/leaflogo.gif" alt="(LEAF Logo)"
width="49" height="36">
@ -91,16 +91,16 @@ configuration changes. Points at which configuration changes are
system, you must save them as Unix files if your editor supports
that option or you must run them through dos2unix before trying to
use them. Similarly, if you copy a configuration file from your Windows
hard drive to a floppy disk, you must run dos2unix against the copy
before using it with Shorewall.</p>
hard drive to a floppy disk, you must run dos2unix against the copy before
using it with Shorewall.</p>
<ul>
<li><a
href="http://www.simtel.net/pub/pd/51438.html">Windows Version of
dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version of
dos2unix</a></li>
</ul>
@ -110,8 +110,8 @@ of dos2unix</a></li>
alt="">
    The configuration files for Shorewall are contained in the
directory /etc/shorewall -- for simple setups, you will only need to
deal with a few of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
deal with a few of these as described in this guide. After you have
<a href="Install.htm">installed Shorewall</a>, <b>download the <a
href="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface sample</a>,
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to
/etc/shorewall (these files will replace files with the same name).</b></p>
@ -164,12 +164,12 @@ in the <a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT
or DROP  the request is first checked against the rules in /etc/shorewall/common
that matches the request is applied. If that policy is REJECT or
DROP  the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the two-interface sample
has the following policies:</p>
<p>The /etc/shorewall/policy file included with the two-interface sample has
the following policies:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -240,10 +240,10 @@ has the following policies:</p>
<ol>
<li>allow all connection requests from your local network
to the internet</li>
<li>drop (ignore) all connection requests from the internet
to your firewall or local network</li>
<li>optionally accept all connection requests from the
firewall to the internet (if you uncomment the additional policy)</li>
<li>drop (ignore) all connection requests from the
internet to your firewall or local network</li>
<li>optionally accept all connection requests from
the firewall to the internet (if you uncomment the additional policy)</li>
<li>reject all other connection requests.</li>
</ol>
@ -258,9 +258,9 @@ make any changes that you wish.</p>
height="635">
</p>
<p align="left">The firewall has two network interfaces. Where Internet connectivity
is through a cable or DSL "Modem", the <i>External Interface</i> will be
the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<p align="left">The firewall has two network interfaces. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint <u>P</u>rotocol
over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
@ -277,8 +277,8 @@ the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>)
<p align="left">Your <i>Internal Interface</i> will be an ethernet adapter
(eth1 or eth0) and will be connected to a hub or switch. Your other
computers will be connected to the same hub/switch (note: If you
have only a single internal system, you can connect the firewall
directly to the computer using a <i>cross-over </i> cable).</p>
have only a single internal system, you can connect the firewall directly
to the computer using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
@ -313,18 +313,17 @@ list of options that are specified for the interfaces. Some hints:</p>
<h2 align="left">IP Addresses</h2>
<p align="left">Before going further, we should say a few words about Internet
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign
you a single <i> Public</i> IP address. This address may be assigned
via the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part
of establishing your connection when you dial in (standard modem) or
establish your PPP connection. In rare cases, your ISP may assign you
a<i> static</i> IP address; that means that you configure your firewall's
external interface to use that address permanently.<i> </i>However
your external address is assigned, it will be shared by all of your systems
when you access the Internet. You will have to assign your own addresses
in your internal network (the Internal Interface on your firewall plus
your other computers). RFC 1918 reserves several <i>Private </i>IP address
ranges for this purpose:</p>
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign you
a single <i> Public</i> IP address. This address may be assigned via
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of
establishing your connection when you dial in (standard modem) or establish
your PPP connection. In rare cases, your ISP may assign you a<i> static</i>
IP address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>However your external address
is assigned, it will be shared by all of your systems when you access
the Internet. You will have to assign your own addresses in your internal
network (the Internal Interface on your firewall plus your other computers).
RFC 1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -334,9 +333,9 @@ ranges for this purpose:</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    Before starting Shorewall, you should look at the
IP address of your external interface and if it is one of the
above ranges, you should remove the 'norfc1918' option from the
external interface's entry in /etc/shorewall/interfaces.</p>
IP address of your external interface and if it is one of the above
ranges, you should remove the 'norfc1918' option from the external
interface's entry in /etc/shorewall/interfaces.</p>
</div>
<div align="left">
@ -344,8 +343,8 @@ external interface's entry in /etc/shorewall/interfaces.</p>
sub-network </i>(<i>subnet)</i>.  For our purposes, we can consider a subnet
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such
a subnet will have a <i>Subnet Mask </i>of 255.255.255.0. The address
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255
is reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255 is
reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR) notation</a> with consists of the subnet address followed
@ -408,9 +407,9 @@ gateway</i> to be the IP address of the firewall's internal interface.
<p align="left">The foregoing short discussion barely scratches the surface
regarding subnetting and routing. If you are interested in learning
more about IP addressing and routing, I highly recommend <i>"IP
Fundamentals: What Everyone Needs to Know about Addressing &amp;
Routing",</i> Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
more about IP addressing and routing, I highly recommend <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i>
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left">The remainder of this quide will assume that you have configured
your network as shown here:</p>
@ -433,9 +432,9 @@ in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
<h2 align="left">IP Masquerading (SNAT)</h2>
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers
don't forward packets which have an RFC-1918 destination address.
When one of your local systems (let's assume computer 1) sends a connection
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When
one of your local systems (let's assume computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network
Address Translation </i>(NAT). The firewall rewrites the source address
in the packet to be the address of the firewall's external interface;
@ -448,10 +447,10 @@ is initiating the connection.
the destination address back to 10.10.10.1 and forwards the packet on
to computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> but you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> but you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<ul>
<li>
@ -468,9 +467,8 @@ with Netfilter:</p>
</ul>
<p align="left">In Shorewall, both Masquerading and SNAT are configured with
entries in the /etc/shorewall/masq file. You will normally use
Masquerading if your external IP is dynamic and SNAT if the IP
is static.</p>
entries in the /etc/shorewall/masq file. You will normally use Masquerading
if your external IP is dynamic and SNAT if the IP is static.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
@ -507,11 +505,11 @@ the third column in the /etc/shorewall/masq entry if you like although
<p align="left">One of your goals may be to run one or more servers on your
local computers. Because these computers have RFC-1918 addresses,
it is not possible for clients on the internet to connect directly
to them. It is rather necessary for those clients to address their
connection requests to the firewall who rewrites the destination address
to the address of your server and forwards the packet to that server.
When your server responds, the firewall automatically performs SNAT
to rewrite the source address in the response.</p>
to them. It is rather necessary for those clients to address their connection
requests to the firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -582,9 +580,9 @@ to rewrite the source address in the response.</p>
<ul>
<li>You must test the above rule from a client outside
of your local network (i.e., don't test from a browser running
on computers 1 or 2 or on the firewall). If you want to be able
to access your web server using the IP address of your external interface,
of your local network (i.e., don't test from a browser running on
computers 1 or 2 or on the firewall). If you want to be able to
access your web server using the IP address of your external interface,
see <a href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
<li>Many ISPs block incoming connection requests to
port 80. If you have problems connecting to your web server, try
@ -626,38 +624,38 @@ any DNAT rules that you require.</p>
<h2 align="left">Domain Name Server (DNS)</h2>
<p align="left">Normally, when you connect to your ISP, as part of getting
an IP address your firewall's <i>Domain Name Service </i>(DNS)
resolver will be automatically configured (e.g., the /etc/resolv.conf
file will be written). Alternatively, your ISP may have given you
the IP address of a pair of DNS <i> name servers</i> for you to manually
configure as your primary and secondary name servers. Regardless of
how DNS gets configured on your firewall, it is <u>your</u> responsibility
to configure the resolver in your internal systems. You can take one
of two approaches:</p>
an IP address your firewall's <i>Domain Name Service </i>(DNS) resolver
will be automatically configured (e.g., the /etc/resolv.conf file
will be written). Alternatively, your ISP may have given you the IP
address of a pair of DNS <i> name servers</i> for you to manually configure
as your primary and secondary name servers. Regardless of how DNS
gets configured on your firewall, it is <u>your</u> responsibility to
configure the resolver in your internal systems. You can take one of
two approaches:</p>
<ul>
<li>
<p align="left">You can configure your internal systems to use your ISP's
name servers. If you ISP gave you the addresses of their servers
or if those addresses are available on their web site, you can
configure your internal systems to use those addresses. If that
information isn't available, look in /etc/resolv.conf on your firewall
system -- the name servers are given in "nameserver" records in that
file. </p>
or if those addresses are available on their web site, you can configure
your internal systems to use those addresses. If that information
isn't available, look in /etc/resolv.conf on your firewall system
-- the name servers are given in "nameserver" records in that file.
</p>
</li>
<li>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    You can configure a<i> Caching Name Server </i>on your
firewall.<i> </i>Red Hat has an RPM for a caching name server
(the RPM also requires the 'bind' RPM) and for Bering users, there
is dnscache.lrp. If you take this approach, you configure your internal
systems to use the firewall itself as their primary (and only) name
server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your local
systems to talk to your caching name server, you must open port 53
(both UDP and TCP) from the local network to the firewall; you do
that by adding the following rules in /etc/shorewall/rules. </p>
    You can configure a<i> Caching Name Server </i>on
your firewall.<i> </i>Red Hat has an RPM for a caching name
server (the RPM also requires the 'bind' RPM) and for Bering users,
there is dnscache.lrp. If you take this approach, you configure your
internal systems to use the firewall itself as their primary (and only)
name server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your
local systems to talk to your caching name server, you must open port
53 (both UDP and TCP) from the local network to the firewall; you
do that by adding the following rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -746,8 +744,8 @@ that by adding the following rules in /etc/shorewall/rules. </p>
<div align="left">
<p align="left">Those rules allow DNS access from your firewall and may be
removed if you uncommented the line in /etc/shorewall/policy
allowing all connections from the firewall to the internet.</p>
removed if you uncommented the line in /etc/shorewall/policy allowing
all connections from the firewall to the internet.</p>
</div>
<div align="left">
@ -823,7 +821,8 @@ allowing all connections from the firewall to the internet.</p>
</div>
<div align="left">
<p align="left">Example - You want to run a Web Server on your firewall system:</p>
<p align="left">Example - You want to run a Web Server on your firewall
system:</p>
</div>
<div align="left">
@ -961,8 +960,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
<p align="left"><br>
<img border="0" src="images/BD21298_.gif" width="13" height="13">
    Now edit your /etc/shorewall/rules file to add or
delete other connections as required.</p>
    Now edit your /etc/shorewall/rules file to add
or delete other connections as required.</p>
</div>
<div align="left">
@ -992,15 +991,15 @@ you have completed configuration of your firewall, you can enable Shorewall
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall
from your Netfilter configuration, use "shorewall clear".</p>
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
</div>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    The two-interface sample assumes that you want to enable
routing to/from <b>eth1 </b>(the local network) when Shorewall
    The two-interface sample assumes that you want to
enable routing to/from <b>eth1 </b>(the local network) when Shorewall
is stopped. If your local network isn't connected to <b>eth1</b> or
if you wish to enable access to/from other hosts, change /etc/shorewall/routestopped
accordingly.</p>
@ -1008,9 +1007,9 @@ if you wish to enable access to/from other hosts, change /etc/shorewall/
<div align="left">
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
the internet, do not issue a "shorewall stop" command unless
you have added an entry for the IP address that you are connected
from to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to
create an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
@ -1023,9 +1022,5 @@ create an <i><a href="configuration_file_basics.htm#Configs">alternate
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a><br>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

220
STABLE/documentation/upgrade_issues.htm
View File

@ -20,6 +20,7 @@
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
@ -32,13 +33,13 @@
</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>
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>
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>
@ -47,12 +48,25 @@ a host address) accessed through a particular interface.<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.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,
@ -64,21 +78,21 @@ there are two cases covered in this documentation where it can occur:<br>
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>
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>
<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>
@ -89,37 +103,42 @@ 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>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>
<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
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>
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
@ -130,11 +149,11 @@ subnetworks on the same interface then I recommend that you upgrade to Version
</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>
<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>
<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>
@ -156,20 +175,22 @@ subnetworks on the same interface then I recommend that you upgrade to Version
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>
<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>
@ -188,25 +209,25 @@ to avoid logging these packets.</li>
<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>
 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>
<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>
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>
@ -214,35 +235,35 @@ to or from the destination zone including rules that use the 'all' reserved
<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>
     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>
<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>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>
 <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>
@ -250,8 +271,8 @@ follows:<br>
<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>
<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>
@ -264,16 +285,16 @@ follows:<br>
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>
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>
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>
@ -298,8 +319,8 @@ documentation</a> for details.<br>
<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>
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>
@ -316,21 +337,22 @@ 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>
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>
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>
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>
@ -340,8 +362,8 @@ to add the following two Bering-specific rules to /etc/shorewall/rules:<
<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>
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
@ -349,8 +371,8 @@ to add the following two Bering-specific rules to /etc/shorewall/rules:<
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can be
rebuilt<br>
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
@ -360,8 +382,8 @@ non-SYN packets after takeover.<br>
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>
-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>
@ -409,13 +431,11 @@ non-SYN packets after takeover.<br>
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 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>
<br>
<br>
</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
{

230
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,20 +2062,10 @@ 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
log_rule $loglevel $chain $logtarget \
`fix_bang $proto $sports $multiport $state $cli $serv $dports`
fi
fi
run_iptables2 -A $chain $proto $multiport $state $cli $sports \
$serv $dports -j $target
@ -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
run_iptables -A badpkt -p tcp $logoptions --log-tcp-options
run_iptables -A badpkt -p ! tcp $logoptions
LOGPARMS="$LOGPARMS --log-ip-options"
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=
@ -4471,8 +4481,26 @@ do_initialize() {
CLEAR_TC=
fi
[ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:"
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
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
#

18
Shorewall-docs/6to4.htm
View File

@ -27,6 +27,7 @@
<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
measures.</h3>
@ -35,8 +36,8 @@ measures.</h3>
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">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>
@ -55,11 +56,11 @@ 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>
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>
@ -134,7 +135,8 @@ other using IPv6.</p>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003Thomas M. Eastep.</font></a></p>
size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.</font></a></p>
<br>
<br>
<br>
</body>

1421
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

303
Shorewall-docs/FAQ.htm
View File

@ -49,9 +49,9 @@
<p align="left"><b>1b. </b><a href="#faq1b">I'm still having problems with
port forwarding</a></p>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to
<b>connect to port 1022</b> on my firewall and have the <b>firewall forward
the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to <b>connect
to port 1022</b> on my firewall and have the <b>firewall forward the connection
to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
</p>
<h1><b>DNS and PORT FORWARDING/NAT<br>
@ -64,10 +64,11 @@ the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a>
clients can't</b>.</a></p>
<p align="left"><b>2a. </b><a href="#faq3">I have a zone "Z" with an RFC1918
subnet and I use <b>static NAT</b> to assign non-RFC1918
addresses to hosts in Z. Hosts in Z cannot communicate
with each other using their external (non-RFC1918 addresses)
so they <b>can't access each other using their DNS names.</b></a></p>
subnet and I use <b>static NAT</b> to assign
non-RFC1918 addresses to hosts in Z. Hosts in Z
cannot communicate with each other using their external
(non-RFC1918 addresses) so they <b>can't access each other
using their DNS names.</b></a></p>
<h1><b>NETMEETING/MSN<br>
</b></h1>
@ -87,15 +88,15 @@ the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a>
of my firewall and it showed 100s of ports as
open!!!!<br>
</a></p>
<b>4b</b>. <a href="#faq4b">I have a port that I can't close no matter how
I change my rules. </a>
<b>4b</b>. <a href="#faq4b">I have a port that I can't close no matter
how I change my rules. </a>
<h1>CONNECTION PROBLEMS</h1>
<p align="left"><b>5. </b><a href="#faq5">I've installed Shorewall and now
I <b> can't ping</b> through the firewall</a><br>
<b><br>
15. </b><a href="#faq15"><b>My local systems can't see out
to the net</b></a></p>
15. </b><a href="#faq15"><b>My local systems can't see
out to the net</b></a></p>
<h1>LOGGING<br>
</h1>
@ -135,8 +136,8 @@ I change my rules.
<h1>STARTING AND STOPPING<br>
</h1>
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using 'shorewall
stop', I can't connect to anything</b>. Why doesn't that command
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using
'shorewall stop', I can't connect to anything</b>. Why doesn't that command
work?</a></p>
<p align="left"><b>8. </b><a href="#faq8">When I try to <b>start Shorewall
@ -160,13 +161,14 @@ stop', I can't connect to anything</b>. Why doesn't that command
<p align="left"><b>10. </b><a href="#faq10">What <b>distributions</b> does
it work with?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it support?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Is there a <b>GUI?</b></a></p>
<p align="left"><b>13. </b><a href="#faq13">Why do you call it <b>"Shorewall"?</b></a></p>
<b>23. </b><a href="#faq23">Why do you use
such <b>ugly fonts</b> on your <b>web site</b>?</a><br>
<b>23. </b><a href="#faq23">Why do you
use such <b>ugly fonts</b> on your <b>web site</b>?</a><br>
<b><br>
25. </b><a href="#faq25">How to I tell <b>which version of Shorewall</b>
I am <b>running</b>?</a><br>
@ -182,8 +184,8 @@ me to configure/monitor it but as expected if I enable
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC
1918 address. If I enable RFC 1918 filtering on my external
interface, <b>my DHCP client cannot renew its lease</b>.</a></p>
1918 address. If I enable RFC 1918 filtering on my
external interface, <b>my DHCP client cannot renew its lease</b>.</a></p>
<h1>ALIAS IP ADDRESSES/VIRTUAL INTERFACES<br>
</h1>
@ -334,10 +336,10 @@ the PORT column specify the range as <i>low-port</i>:<i>high-port</i>.<b
<li>You are trying
to test from inside your firewall (no, that won't
work -- see <a href="#faq2">FAQ #2</a>).</li>
<li>You have a
more basic problem with your local system such as an
incorrect default gateway configured (it should be set to
the IP address of your firewall's internal interface).</li>
<li>You have
a more basic problem with your local system such as
an incorrect default gateway configured (it should be
set to the IP address of your firewall's internal interface).</li>
<li>Your ISP is blocking that particular port inbound.<br>
</li>
@ -361,8 +363,8 @@ diagnose this problem:<br>
zone&gt;</i>_dnat ('net_dnat' in the above examples).</li>
<li>Is the packet count
in the first column non-zero? If so, the connection
request is reaching the firewall and is being redirected
to the server. In this case, the problem is usually a missing
request is reaching the firewall and is being redirected to
the server. In this case, the problem is usually a missing
or incorrect default gateway setting on the server (the server's
default gateway should be the IP address of the firewall's
interface to the server).</li>
@ -379,8 +381,8 @@ your rule is only redirecting the primary IP address (You need
to specify the secondary IP address in the "ORIG. DEST." column
in your DNAT rule); or</li>
<li>your DNAT rule doesn't
match the connection request in some other way. In that
case, you may have to use a packet sniffer such as tcpdump
match the connection request in some other way. In
that case, you may have to use a packet sniffer such as tcpdump
or ethereal to further diagnose the problem.<br>
</li>
@ -389,8 +391,8 @@ or ethereal to further diagnose the problem.<br>
</ul>
<h4 align="left"><a name="faq1c"></a><b>1c. </b>From the internet, I want
to connect to port 1022 on my firewall and have the firewall forward the
connection to port 22 on local system 192.168.1.3. How do I do that?</h4>
to connect to port 1022 on my firewall and have the firewall forward
the connection to port 22 on local system 192.168.1.3. How do I do that?</h4>
<div align="left">
<blockquote>
@ -428,8 +430,8 @@ or ethereal to further diagnose the problem.<br>
</div>
<h4 align="left"><a name="faq2"></a>2. I port forward www requests to www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in my
local network. External clients can browse http://www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in
my local network. External clients can browse http://www.mydomain.com
but internal clients can't.</h4>
<p align="left"><b>Answer: </b>I have two objections to this setup.</p>
@ -438,19 +440,19 @@ or ethereal to further diagnose the problem.<br>
<li>Having an
internet-accessible server in your local network
is like raising foxes in the corner of your hen house. If
the server is compromised, there's nothing between
that server and your other internal systems. For the cost
of another NIC and a cross-over cable, you can put your
server in a DMZ such that it is isolated from your local systems
- assuming that the Server can be located near the Firewall,
of course :-)</li>
the server is compromised, there's nothing between that
server and your other internal systems. For the cost of
another NIC and a cross-over cable, you can put your server
in a DMZ such that it is isolated from your local systems -
assuming that the Server can be located near the Firewall, of course
:-)</li>
<li>The accessibility
problem is best solved using <a
href="shorewall_setup_guide.htm#DNS">Bind Version 9 "views"</a>
(or using a separate DNS server for local clients) such that www.mydomain.com
resolves to 130.141.100.69 externally and 192.168.1.5 internally.
That's what I do here at shorewall.net for my local systems
that use static NAT.</li>
resolves to 130.141.100.69 externally and 192.168.1.5
internally. That's what I do here at shorewall.net for my
local systems that use static NAT.</li>
</ul>
@ -462,8 +464,8 @@ of another NIC and a cross-over cable, you can put your
</p>
<p align="left">If you are running Shorewall 1.4.0 or earlier see <a
href="file:///Z:/Shorewall-docs/1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions
suitable for those releases.<br>
href="1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions suitable for
those releases.<br>
</p>
<p align="left">If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
@ -615,17 +617,17 @@ this in /etc/shorewall/init:</p>
so they can't access each other using their DNS names.</h4>
<p align="left"><b>Answer: </b>This is another problem that is best solved
using Bind Version 9 "views". It allows both external
and internal clients to access a NATed host using
the host's DNS name.</p>
using Bind Version 9 "views". It allows both
external and internal clients to access a NATed
host using the host's DNS name.</p>
<p align="left">Another good way to approach this problem is to switch from
static NAT to Proxy ARP. That way, the hosts in
Z have non-RFC1918 addresses and can be accessed externally
and internally using the same address. </p>
static NAT to Proxy ARP. That way, the hosts
in Z have non-RFC1918 addresses and can be accessed
externally and internally using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">a) Set the Z-&gt;Z policy to ACCEPT.<br>
b) Masquerade Z
@ -720,10 +722,11 @@ to itself.<br>
<p align="left"><b>Answer: </b>There is an <a
href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection
tracking/NAT module</a> that may help with Netmeeting.
Look <a href="http://linux-igd.sourceforge.net">here</a> for a
solution for MSN IM but be aware that there are significant security
risks involved with this solution. Also check the Netfilter mailing
list archives at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
Look <a href="http://linux-igd.sourceforge.net">here</a> for
a solution for MSN IM but be aware that there are significant security
risks involved with this solution. Also check the Netfilter
mailing list archives at <a
href="http://www.netfilter.org">http://www.netfilter.org</a>.
</p>
<h4 align="left"><a name="faq4"></a>4. I just used an online port scanner
@ -731,20 +734,20 @@ risks involved with this solution. Also check the Netfilter mailing
as 'closed' rather than 'blocked'. Why?</h4>
<p align="left"><b>Answer: </b>The common.def included with version 1.3.x
always rejects connection requests on TCP port
113 rather than dropping them. This is necessary
to prevent outgoing connection problems to services
that use the 'Auth' mechanism for identifying requesting
users. Shorewall also rejects TCP ports 135, 137 and 139
as well as UDP ports 137-139. These are ports that are used
by Windows (Windows <u>can</u> be configured to use the DCE cell
locator on port 135). Rejecting these connection requests rather
than dropping them cuts down slightly on the amount of Windows chatter
always rejects connection requests on TCP
port 113 rather than dropping them. This is necessary
to prevent outgoing connection problems to services that
use the 'Auth' mechanism for identifying requesting users.
Shorewall also rejects TCP ports 135, 137 and 139 as well
as UDP ports 137-139. These are ports that are used by Windows
(Windows <u>can</u> be configured to use the DCE cell locator
on port 135). Rejecting these connection requests rather than
dropping them cuts down slightly on the amount of Windows chatter
on LAN segments connected to the Firewall. </p>
<p align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web server
in violation of your Service Agreement.</p>
your ISP preventing you from running a web
server in violation of your Service Agreement.</p>
<h4 align="left"><a name="faq4a"></a>4a. I just ran an nmap UDP scan of my
firewall and it showed 100s of ports as open!!!!</h4>
@ -752,20 +755,22 @@ on LAN segments connected to the Firewall. </p>
<p align="left"><b>Answer: </b>Take a deep breath and read the nmap man page
section about UDP scans. If nmap gets <b>nothing</b>
back from your firewall then it reports the port
as open. If you want to see which UDP ports are really
open, temporarily change your net-&gt;all policy to REJECT,
as open. If you want to see which UDP ports are really open,
temporarily change your net-&gt;all policy to REJECT,
restart Shorewall and do the nmap UDP scan again.<br>
</p>
<h4><a name="faq4b"></a>4b. I have a port that I can't close no matter how
I change my rules. </h4>
I had a rule that allowed telnet from my local network to my firewall; I
removed that rule and restarted Shorewall but my telnet session still works!!!<br>
I had a rule that allowed telnet from my local network to my firewall;
I removed that rule and restarted Shorewall but my telnet session still
works!!!<br>
<br>
<b>Answer: </b> Rules only govern the establishment of new connections.
Once a connection is established through the firewall it will be usable until
disconnected (tcp) or until it times out (other protocols).  If you stop telnet
and try to establish a new session your firerwall will block that attempt.<br>
disconnected (tcp) or until it times out (other protocols).  If you stop
telnet and try to establish a new session your firerwall will block that
attempt.<br>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
can't ping through the firewall</h4>
@ -791,11 +796,11 @@ the first command in the file is ". /etc/shorewall/common.def"<br>
<h4 align="left"><a name="faq6"></a>6. Where are the log messages written
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure
to restart syslogd (on a RedHat system, "service syslog
@ -803,8 +808,8 @@ restart"). </p>
<p align="left">By default, older versions of Shorewall ratelimited log messages
through <a href="Documentation.htm#Conf">settings</a>
in /etc/shorewall/shorewall.conf -- If you want to
log all messages, set: </p>
in /etc/shorewall/shorewall.conf -- If you want
to log all messages, set: </p>
<div align="left">
<pre align="left"> LOGLIMIT=""<br> LOGBURST=""<br></pre>
@ -859,8 +864,8 @@ i exclude these error messages for this port temporarily from logging
<b>logunclean</b> option (<a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
on your external interface (eth0 in the above example). If they get
logged twice, they are corrupted. I solve this problem by using
an /etc/shorewall/common file like this:<br>
logged twice, they are corrupted. I solve this problem by using an
/etc/shorewall/common file like this:<br>
<blockquote>
<pre>#<br># Include the standard common.def file<br>#<br>. /etc/shorewall/common.def<br>#<br># The following rule is non-standard and compensates for tardy<br># DNS replies<br>#<br>run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</pre>
@ -898,10 +903,10 @@ an /etc/shorewall/common file like this:<br>
that command work?</h4>
<p align="left">The 'stop' command is intended to place your firewall into
a safe state whereby only those hosts listed in
/etc/shorewall/routestopped' are activated. If
you want to totally open up your firewall, you must use the
'shorewall clear' command. </p>
a safe state whereby only those hosts listed
in /etc/shorewall/routestopped' are activated.
If you want to totally open up your firewall, you must use
the 'shorewall clear' command. </p>
<h4 align="left"><a name="faq8"></a>8. When I try to start Shorewall on RedHat,
I get messages about insmod failing -- what's wrong?</h4>
@ -945,9 +950,9 @@ you want to totally open up your firewall, you must use the
</div>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The
Net zone is defined as all hosts that are connected through eth0 and the
local zone is defined as all hosts connected through eth1</p>
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
zone is defined as all hosts connected through eth1</p>
</div>
<h4 align="left"><a name="faq10"></a>10. What Distributions does it work
@ -978,18 +983,17 @@ local zone is defined as all hosts connected through eth1</p>
<h4 align="left"> <a name="faq14"></a>14. I'm connected via a cable modem
and it has an internal web server that allows
me to configure/monitor it but as expected if I enable
rfc1918 blocking for my eth0 interface (the internet one),
it also blocks the cable modems web server.</h4>
me to configure/monitor it but as expected if I
enable rfc1918 blocking for my eth0 interface (the internet
one), it also blocks the cable modems web server.</h4>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1
address of the modem in/out but still block all other
rfc1918 addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -1026,9 +1030,9 @@ following:</p>
</p>
<p align="left">Note: If you add a second IP address to your external firewall
interface to correspond to the modem address, you
must also make an entry in /etc/shorewall/rfc1918 for
that address. For example, if you configure the address
interface to correspond to the modem address,
you must also make an entry in /etc/shorewall/rfc1918
for that address. For example, if you configure the address
192.168.100.2 on your firewall, then you would add two entries
to /etc/shorewall/rfc1918: <br>
</p>
@ -1067,10 +1071,10 @@ following:</p>
</div>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable
RFC 1918 filtering on my external interface, my DHCP client cannot renew
its lease.</h4>
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.</h4>
</div>
<div align="left">
@ -1113,16 +1117,16 @@ firewall to the internet.</p>
<p align="left"><b>Answer: </b>"man dmesg" -- add a suitable 'dmesg' command
to your startup scripts or place it in /etc/shorewall/start.
Under RedHat, the max log level that is sent to
the console is specified in /etc/sysconfig/init in the
LOGLEVEL variable.<br>
Under RedHat, the max log level that is sent
to the console is specified in /etc/sysconfig/init in
the LOGLEVEL variable.<br>
</p>
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
logged?</h4>
<b>Answer: </b>Logging
occurs out of a number of chains (as indicated in
the log message) in Shorewall:<br>
occurs out of a number of chains (as indicated in the
log message) in Shorewall:<br>
<ol>
<li><b>man1918 - </b>The
@ -1134,25 +1138,26 @@ the log message) in Shorewall:<br>
with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>all2&lt;zone&gt;</b>,
<b>&lt;zone&gt;2all</b> or <b>all2all </b>-
You have a<a href="Documentation.htm#Policy"> policy</a> that specifies
a log level and this packet is being logged under that policy.
If you intend to ACCEPT this traffic then you need a <a
href="Documentation.htm#Rules">rule</a> to that effect.<br>
<b>&lt;zone&gt;2all</b> or <b>all2all
</b>- You have a<a href="Documentation.htm#Policy"> policy</a>
that specifies a log level and this packet is being
logged under that policy. If you intend to ACCEPT this
traffic then you need a <a href="Documentation.htm#Rules">rule</a> to
that effect.<br>
</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt;
</b>- Either you have a<a
href="Documentation.htm#Policy"> policy</a> for <b>&lt;zone1&gt;
</b>to <b>&lt;zone2&gt;</b> that specifies a log level and
this packet is being logged under that policy or this packet
matches a <a href="Documentation.htm#Rules">rule</a> that includes
a log level.</li>
matches a <a href="Documentation.htm#Rules">rule</a> that
includes a log level.</li>
<li><b>&lt;interface&gt;_mac</b>
- The packet is being logged under the <b>maclist</b>
<a href="Documentation.htm#Interfaces">interface option</a>.<br>
</li>
<li><b>logpkt</b> -
The packet is being logged under the <b>logunclean</b>
<li><b>logpkt</b>
- The packet is being logged under the <b>logunclean</b>
<a href="Documentation.htm#Interfaces">interface option</a>.</li>
<li><b>badpkt </b>-
The packet is being logged under the <b>dropunclean</b>
@ -1185,23 +1190,23 @@ syn packet. Options affecting the logging of such packets include
<h4><a name="faq18"></a>18. Is there any way to use <b>aliased ip addresses</b>
with Shorewall, and maintain separate rulesets for
different IPs?</h4>
<b>Answer: </b>Yes. See <a
href="Shorewall_and_Aliased_Interfaces.html">Shorewall and Aliased Interfaces</a>.
<b>Answer: </b>Yes. See
<a href="Shorewall_and_Aliased_Interfaces.html">Shorewall and Aliased Interfaces</a>.
<h4><b><a name="faq19"></a>19. </b>I have added entries to /etc/shorewall/tcrules
but they don't seem to do anything. Why?</h4>
You probably haven't set TC_ENABLED=Yes
in /etc/shorewall/shorewall.conf so the contents of the
tcrules file are simply being ignored.<br>
in /etc/shorewall/shorewall.conf so the contents of
the tcrules file are simply being ignored.<br>
<h4><a name="faq20"></a><b>20. </b>I have just set up a server. <b>Do I have
to change Shorewall to allow access to my server from
the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1216,34 +1221,34 @@ rules for your server.<br>
<b>Answer: </b>While most people
associate the Internet Control Message Protocol (ICMP)
with 'ping', ICMP is a key piece of the internet. ICMP is
used to report problems back to the sender of a packet; this is
what is happening here. Unfortunately, where NAT is involved (including
SNAT, DNAT and Masquerade), there are a lot of broken implementations.
That is what you are seeing with these messages.<br>
used to report problems back to the sender of a packet; this
is what is happening here. Unfortunately, where NAT is involved
(including SNAT, DNAT and Masquerade), there are a lot of broken
implementations. That is what you are seeing with these messages.<br>
<br>
Here is my interpretation of what
is happening -- to confirm this analysis, one would have to
have packet sniffers placed a both ends of the connection.<br>
is happening -- to confirm this analysis, one would have
to have packet sniffers placed a both ends of the connection.<br>
<br>
Host 172.16.1.10 behind NAT gateway
206.124.146.179 sent a UDP DNS query to 192.0.2.3 and your
DNS server tried to send a response (the response information
is in the brackets -- note source port 53 which marks this as a
DNS reply). When the response was returned to to 206.124.146.179,
it rewrote the destination IP TO 172.16.1.10 and forwarded the packet
to 172.16.1.10 who no longer had a connection on UDP port 2857.
This causes a port unreachable (type 3, code 3) to be generated back
to 192.0.2.3. As this packet is sent back through 206.124.146.179,
206.124.146.179 sent a UDP DNS query to 192.0.2.3 and
your DNS server tried to send a response (the response information
is in the brackets -- note source port 53 which marks this as
a DNS reply). When the response was returned to to 206.124.146.179,
it rewrote the destination IP TO 172.16.1.10 and forwarded the
packet to 172.16.1.10 who no longer had a connection on UDP port
2857. This causes a port unreachable (type 3, code 3) to be generated
back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has
no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
appear to be related to anything that was sent. The final result
is that the packet gets logged and dropped in the all2all chain. I have
also seen cases where the source IP in the ICMP itself isn't set back
to the external IP of the remote NAT gateway; that causes your firewall
to log and drop the packet out of the rfc1918 chain because the source
IP is reserved by RFC 1918.<br>
is that the packet gets logged and dropped in the all2all chain. I
have also seen cases where the source IP in the ICMP itself isn't set
back to the external IP of the remote NAT gateway; that causes your
firewall to log and drop the packet out of the rfc1918 chain because
the source IP is reserved by RFC 1918.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do
@ -1253,21 +1258,22 @@ one of the <a href="shorewall_extension_scripts.htm">Shorewall Extension
Scripts</a>. Be sure that you look at the contents of the chain(s) that
you will be modifying with your commands to be sure that the
commands will do what they are intended. Many iptables commands
published in HOWTOs and other instructional material use the -A
command which adds the rules to the end of the chain. Most chains
that Shorewall constructs end with an unconditional DROP, ACCEPT or
REJECT rule and any rules that you add after that will be ignored.
Check "man iptables" and look at the -I (--insert) command.<br>
published in HOWTOs and other instructional material use the -A command
which adds the rules to the end of the chain. Most chains that Shorewall
constructs end with an unconditional DROP, ACCEPT or REJECT rule and
any rules that you add after that will be ignored. Check "man iptables"
and look at the -I (--insert) command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
The Shorewall web site is almost font neutral
(it doesn't explicitly specify fonts except on a few pages)
so the fonts you see are largely the default fonts configured in
your browser. If you don't like them then reconfigure your browser.<br>
(it doesn't explicitly specify fonts except on a few pages) so
the fonts you see are largely the default fonts configured in your
browser. If you don't like them then reconfigure your browser.<br>
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
the ssh port only<b> from specific IP Addresses</b> on the internet?</h4>
the ssh port only<b> from specific IP Addresses</b> on the
internet?</h4>
In the SOURCE column of the rule, follow "net"
by a colon and a list of the host/subnet addresses as a comma-separated
list.<br>
@ -1294,5 +1300,6 @@ your browser. If you don't like them then reconfigure your browser.<br>
<br>
<br>
<br>
<br>
</body>
</html>

75
Shorewall-docs/Install.htm
View File

@ -30,8 +30,8 @@
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
<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>
@ -48,26 +48,26 @@ to read and print a copy of the <a
<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
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>
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
<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>
(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
     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 -ivh
@ -78,8 +78,8 @@ diagnostic:<br>
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
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>
@ -90,8 +90,8 @@ clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.</b></font></li>
<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>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
@ -117,14 +117,14 @@ be started automatically at boot, see <a
<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>
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
<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
@ -134,15 +134,15 @@ your /etc/shorewall/interfaces file to be sure that it contains an entry
<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").
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
<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>
@ -153,27 +153,27 @@ your /etc/shorewall/interfaces file to be sure that it contains an entry
--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>
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall (shorewall restart).</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><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>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>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
@ -189,8 +189,8 @@ for details. </p>
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>
and the new Shorewall version (type "shorewall check") and correct
as necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
</ul>
@ -201,8 +201,8 @@ distribution installs init scripts and type "./install.sh
<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
<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>
@ -215,5 +215,6 @@ distribution installs init scripts and type "./install.sh
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
</body>
</html>

1609
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

52
Shorewall-docs/errata.htm
View File

@ -80,8 +80,8 @@ Issues</a></b></li>
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="#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>
@ -93,6 +93,29 @@ iptables</a></b></li>
<h3></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>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.2</h3>
<ul>
@ -125,7 +148,8 @@ This problem is corrected in <a
<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>
     /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"
@ -172,11 +196,11 @@ have also built an <a
<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
@ -232,8 +256,8 @@ option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i3
<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>
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
@ -259,16 +283,16 @@ running Shorewall 1.3.6 you may
<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>
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>
<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>
</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.

226
Shorewall-docs/seattlefirewall_index.htm
View File

@ -7,27 +7,31 @@
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">
<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></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>
@ -62,44 +66,50 @@
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<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
<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
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>
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>
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>
@ -111,12 +121,13 @@ 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>
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
@ -128,16 +139,66 @@ if you uninstall what you have and install a setup that matches the documentati
<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>
</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><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>(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>
<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>
</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>
@ -150,30 +211,31 @@ convention:<br>
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"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
<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>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
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>
<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>
@ -181,11 +243,14 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
@ -197,36 +262,43 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
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>
<ol>
</ol>
</blockquote>
<p><a href="News.htm">More News</a></p>
@ -234,25 +306,26 @@ well to view the presentation.<br>
<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>
<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 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">
@ -264,14 +337,15 @@ well to view the presentation.<br>
<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>
@ -286,6 +360,7 @@ well to view the presentation.<br>
</tbody>
</table>
</center>
</div>
@ -293,9 +368,11 @@ well to view the presentation.<br>
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td
width="100%" style="margin-top: 1px;">
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
@ -306,20 +383,25 @@ well to view the presentation.<br>
<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
<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>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

421
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">
<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">
<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>
<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
<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>
<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><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>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>
<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
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 (&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
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>
<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
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>
<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
<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
<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>
<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>
<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>

181
Shorewall-docs/sourceforge_index.htm
View File

@ -7,7 +7,8 @@
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<base target="_self">
<base
target="_self">
</head>
<body>
@ -16,18 +17,21 @@
bgcolor="#4b017c">
<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><font color="#ffffff">Shorewall 1.4 -
<font size="4">"<i>iptables made easy"</i></font></font><br>
</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>
@ -47,28 +51,32 @@
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<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>
(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
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>
@ -82,11 +90,12 @@ This program is distributed in the hope
<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>
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>
@ -96,32 +105,83 @@ You should have received a copy of the GNU
<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>
<h2><b>News</b></h2>
<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>
</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><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>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>
<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>
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>
<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>
@ -134,19 +194,19 @@ convention:<br>
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"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
<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>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
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>
@ -155,10 +215,10 @@ is enforced.<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 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>
@ -166,11 +226,14 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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>
@ -190,6 +253,7 @@ Note: You may not use ULOG with fireparse unless you modify fireparse. </li>
</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
@ -198,13 +262,16 @@ 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>
<ol>
</ol>
</blockquote>
@ -214,14 +281,17 @@ to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
<b> </b>
<p><b><a href="News.htm">More News</a></b></p>
<b> </b>
<h2><b> </b></h2>
<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)">
@ -229,13 +299,13 @@ to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape
</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>
<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"
@ -245,15 +315,18 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<b> </b>
<h4><b> </b></h4>
<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>
<h2><b><a name="Donations"></a>Donations</b></h2>
<b> </b></td>
@ -263,6 +336,7 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<form method="post"
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
@ -277,9 +351,11 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
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
@ -295,13 +371,17 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
</tbody>
</table>
</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;">
@ -316,21 +396,26 @@ at: <a href="http://leaf.sourceforge.net/devel/jnilo">
<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
<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>
<p><font size="2">Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

103
Shorewall-docs/support.htm
View File

@ -29,9 +29,9 @@
<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.
There
are a number of sources of Shorewall information. Please try these
before you post.
<ul>
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
@ -42,8 +42,8 @@ list have answers directly accessible from the <a
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>
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
@ -69,11 +69,13 @@ list have answers directly accessible from the <a
<option value="boolean">Boolean </option>
</select>
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -102,21 +104,21 @@ list have answers directly accessible from the <a
<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>
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>
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>
@ -145,10 +147,11 @@ you are running.<br>
</ul>
<ul>
<li>the exact kernel version you are
running<br>
<li>the exact kernel version you
are running<br>
<br>
<font color="#009900"><b>uname -a<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
@ -209,8 +212,8 @@ the exact output from<br>
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>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
@ -226,16 +229,17 @@ the SMTP headers of your post).<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>
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>
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
@ -245,8 +249,8 @@ you have modified that file) that you think are relevant
<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>
post GIFs of your network layout, etc.
to the Mailing List -- your post will be rejected.</b></li>
</ul>
@ -258,39 +262,33 @@ the Mailing List -- your post will be rejected.</b></li>
<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>
<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>
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
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>
@ -309,11 +307,10 @@ output, use the appropriate mailing list below.</b><br>
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 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>

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

@ -42,8 +42,8 @@
local network.</li>
<li>Single public IP address.</li>
<li>DMZ connected to a separate ethernet interface.</li>
<li>Connection through DSL, Cable Modem, ISDN, Frame Relay,
dial-up, ...</li>
<li>Connection through DSL, Cable Modem, ISDN, Frame
Relay, dial-up, ...</li>
</ul>
@ -55,9 +55,9 @@ local network.</li>
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b>
program on your firewall system. As root, you can use the 'which'
command to check for this program:</p>
tell if this package is installed by the presence of an <b>ip</b> program
on your firewall system. As root, you can use the 'which' command
to check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -79,11 +79,12 @@ floppy disk, you must run dos2unix against the copy before using it with
Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
href="http://www.simtel.net/pub/pd/51438.html">Windows Version of
dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version of
dos2unix</a></li>
</ul>
@ -246,9 +247,9 @@ and make any changes that you wish.</p>
</p>
<p align="left">The firewall has three network interfaces. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External
Interface</i> will be the ethernet adapter that is connected to
that "Modem" (e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter that is connected to that "Modem" (e.g.,
<b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
@ -270,15 +271,15 @@ the computer using a <i>cross-over </i> cable).</p>
<p align="left">Your <i>DMZ Interface</i> will also be an ethernet adapter
(eth0, eth1 or eth2) and will be connected to a hub or switch. Your
DMZ computers will be connected to the same switch (note: If you have
only a single DMZ system, you can connect the firewall directly to
the computer using a <i>cross-over </i> cable).</p>
only a single DMZ system, you can connect the firewall directly to the
computer using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect more than one interface to the same
hub or switch (even for testing). It won't work the way that you
expect it to and you will end up confused and believing that Shorewall
doesn't work at all.</p>
hub or switch (even for testing). It won't work the way that you expect
it to and you will end up confused and believing that Shorewall doesn't
work at all.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
@ -286,8 +287,8 @@ doesn't work at all.</p>
that the external interface is <b>eth0, </b>the local interface is
<b>eth1 </b>and the DMZ interface is <b> eth2</b>. If your configuration
is different, you will have to modify the sample /etc/shorewall/interfaces
file accordingly. While you are there, you may wish to review the
list of options that are specified for the interfaces. Some hints:</p>
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
<ul>
<li>
@ -335,14 +336,14 @@ IP address of your external interface and if it is one of the above
<p align="left">You will want to assign your local addresses from one <i>
sub-network </i>or <i>subnet</i> and your DMZ addresses from another
subnet. For our purposes, we can consider a subnet to consists of
a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have
a <i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved
a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a
<i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved
as the <i>Subnet Address</i> and x.y.z.255 is reserved as the <i>Subnet
Broadcast</i> <i>Address</i>. In Shorewall, a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR)</a> notation with consists of the subnet address followed
by "/24". The "24" refers to the number of consecutive "1" bits
from the left of the subnet mask. </p>
by "/24". The "24" refers to the number of consecutive "1" bits from
the left of the subnet mask. </p>
</div>
<div align="left">
@ -418,34 +419,34 @@ Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP  might assign
your external interface an RFC 1918 address. If that address is in the
10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918
subnet for your local network and if it is in the 10.10.11.0/24 subnet then
you will need to select a different RFC 1918 subnet for your DMZ.</b><br>
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP  might
assign your external interface an RFC 1918 address. If that address is
in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
1918 subnet for your local network and if it is in the 10.10.11.0/24 subnet
then you will need to select a different RFC 1918 subnet for your DMZ.</b><br>
</p>
<p align="left">IP Masquerading (SNAT)</p>
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When
one of your local systems (let's assume local computer 1) sends a
connection request to an internet host, the firewall must perform
<i>Network Address Translation </i>(NAT). The firewall rewrites the
source address in the packet to be the address of the firewall's external
interface; in other words, the firewall makes it look as if the firewall
itself is initiating the connection.  This is necessary so that the
destination host will be able to route return packets back to the firewall
(remember that packets whose destination address is reserved by RFC
1918 can't be routed accross the internet). When the firewall receives
a return packet, it rewrites the destination address back to 10.10.10.1
and forwards the packet on to local computer 1. </p>
forward packets which have an RFC-1918 destination address. When one
of your local systems (let's assume local computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network
Address Translation </i>(NAT). The firewall rewrites the source address
in the packet to be the address of the firewall's external interface;
in other words, the firewall makes it look as if the firewall itself
is initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed accross the internet). When the firewall receives a return
packet, it rewrites the destination address back to 10.10.10.1 and forwards
the packet on to local computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> and you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> and you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<ul>
<li>
@ -466,15 +467,15 @@ with Netfilter:</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If your external firewall interface is <b>eth0</b>, your
local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b>
    If your external firewall interface is <b>eth0</b>,
your local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b>
then you do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change it to match your configuration.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If your external IP is static, you can enter it in the
third column in the /etc/shorewall/masq entry if you like although
    If your external IP is static, you can enter it in
the third column in the /etc/shorewall/masq entry if you like although
your firewall will work fine if you leave that column empty. Entering
your static IP in column 3 makes <br>
processing outgoing packets a little more efficient.<br>
@ -501,9 +502,9 @@ change them appropriately:<br>
is not possible for clients on the internet to connect directly to
them. It is rather necessary for those clients to address their connection
requests to your firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to
rewrite the source address in the response.</p>
address of your server and forwards the packet to that server. When your
server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -540,8 +541,8 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
</table>
</blockquote>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to
be the same as <i>&lt;port&gt;</i>.</p>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to be
the same as <i>&lt;port&gt;</i>.</p>
<p>Example - you run a Web Server on DMZ 2 and you want to forward incoming
TCP port 80 to that system:</p>
@ -585,13 +586,13 @@ be the same as <i>&lt;port&gt;</i>.</p>
<p>A couple of important points to keep in mind:</p>
<ul>
<li>When you are connecting to your server from your local
systems, you must use the server's internal IP address (10.10.11.2).</li>
<li>When you are connecting to your server from your
local systems, you must use the server's internal IP address (10.10.11.2).</li>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000 (e.g., connect to <a
href="http://w.x.y.z:5000"> http://w.x.y.z:5000</a> where w.x.y.z is your
external IP).</li>
following rule and try connecting to port 5000 (e.g., connect to
<a href="http://w.x.y.z:5000"> http://w.x.y.z:5000</a> where w.x.y.z
is your external IP).</li>
</ul>
@ -727,15 +728,15 @@ as your primary and secondary name servers. It is <u>your</u> responsibili
width="13" height="13">
    You can configure a<i> Caching Name Server </i>on your
firewall or in your DMZ.<i> </i>Red Hat has an RPM for a caching
name server (which also requires the 'bind' RPM) and for Bering
users, there is dnscache.lrp. If you take this approach, you configure
your internal systems to use the caching name server as their primary
(and only) name server. You use the internal IP address of the firewall
(10.10.10.254 in the example above) for the name server address if
you choose to run the name server on your firewall. To allow your local
systems to talk to your caching name server, you must open port 53
(both UDP and TCP) from the local network to the server; you do that
by adding the rules in /etc/shorewall/rules. </p>
name server (which also requires the 'bind' RPM) and for Bering users,
there is dnscache.lrp. If you take this approach, you configure your
internal systems to use the caching name server as their primary (and
only) name server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address if you choose to
run the name server on your firewall. To allow your local systems to
talk to your caching name server, you must open port 53 (both UDP
and TCP) from the local network to the server; you do that by adding
the rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -1020,7 +1021,8 @@ allowing all connections from the firewall to the internet.</p>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>udp<br>
</td>
<td>53</td>
<td>#Allow DNS access</td>
<td>from the internet</td>
@ -1043,8 +1045,8 @@ uses, look <a href="ports.htm">here</a>.</p>
<div align="left">
<p align="left"><b>Important: </b>I don't recommend enabling telnet to/from
the internet because it uses clear text (even for login!). If
you want shell access to your firewall from the internet, use SSH:</p>
the internet because it uses clear text (even for login!). If you
want shell access to your firewall from the internet, use SSH:</p>
</div>
<div align="left">
@ -1130,8 +1132,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Now modify /etc/shorewall/rules to add or remove other
connections as required.</p>
    Now modify /etc/shorewall/rules to add or remove
other connections as required.</p>
</div>
<div align="left">
@ -1144,8 +1146,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
    The <a href="Install.htm">installation procedure </a>
configures your system to start Shorewall at system boot  but beginning
with Shorewall version 1.3.9 startup is disabled so that your system
won't try to start Shorewall before configuration is complete. Once you
have completed configuration of your firewall, you can enable Shorewall
won't try to start Shorewall before configuration is complete. Once
you have completed configuration of your firewall, you can enable Shorewall
startup by removing the file /etc/shorewall/startup_disabled.<br>
</p>
@ -1168,11 +1170,11 @@ startup by removing the file /etc/shorewall/startup_disabled.<br>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    The three-interface sample assumes that you want to enable
routing to/from <b>eth1 (</b>your local network) and<b> eth2 </b>(DMZ)
when Shorewall is stopped. If these two interfaces don't connect
to your local network and DMZ or if you want to enable a different
set of hosts, modify /etc/shorewall/routestopped accordingly.</p>
    The three-interface sample assumes that you want to
enable routing to/from <b>eth1 (</b>your local network) and<b> eth2
</b>(DMZ) when Shorewall is stopped. If these two interfaces don't
connect to your local network and DMZ or if you want to enable a
different set of hosts, modify /etc/shorewall/routestopped accordingly.</p>
</div>
<div align="left">
@ -1180,33 +1182,17 @@ startup by removing the file /etc/shorewall/startup_disabled.<br>
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to
create an <i><a href="configuration_file_basics.htm#Configs">alternate
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/21/2003 - <a
<p align="left"><font size="2">Last updated 5/19/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Thomas M. Eastep</font></a><br>
</p>
</body>
</html>

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

@ -32,14 +32,14 @@
<p align="left"><small><i><u>Notes du traducteur</u> :<br>
Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une
traduction exacte du texte, mais plutôt à en faire une version française intelligible
par tous (et par moi). Les termes techniques sont la plupart du temps conservés
sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver
dans le reste des documentations ainsi que dans les fichiers de configuration.
N?hésitez pas à me contacter afin d?améliorer ce document <a
href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice</a> (merci à JMM
pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour
son formidable outil et sa disponibilité).</i></small></p>
traduction exacte du texte, mais plutôt à en faire une version française
intelligible par tous (et par moi). Les termes techniques sont la plupart
du temps conservés sous leur forme originale et mis entre parenthèses car
vous pouvez les retrouver dans le reste des documentations ainsi que dans
les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer
ce document <a href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice</a>
(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à
Tom EASTEP pour son formidable outil et sa disponibilité).</i></small></p>
<p align="left"><br>
Mettre en place un système linux en tant que firewall pour un petit réseau
@ -66,27 +66,27 @@ son formidable outil et sa disponibilit
height="635">
</p>
<p>Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé.
Vous pouvez voir si le paquet est installé en vérifiant la présence du programme
<p>Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous
pouvez voir si le paquet est installé en vérifiant la présence du programme
ip sur votre système de firewall. Sous root, utilisez la commande 'which'
pour rechercher le programme :</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>Je vous recommande dans un premier temps de parcourir tout le guide pour
vous familiariser avec ce qu'il va se passer, et de revenir au début en
effectuant le changements dans votre configuration. Les points où, les changements
dans la configuration sont recommandées, sont signalés par une <img
vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant
le changements dans votre configuration. Les points où, les changements dans
la configuration sont recommandées, sont signalés par une <img
border="0" src="images/BD21298_.gif" width="13" height="13">
</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
Si vous éditez vos fichiers de configuration sur un système Windows, vous
devez les sauver comme des fichiers Unix si votre éditeur offre cette option
sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser.
De la même manière, si vous copiez un fichier de configuration depuis votre
disque dur Windows vers une disquette, vous devez lancer dos2unix sur la
copie avant de l'utiliser avec Shorewall.</p>
Si vous éditez vos fichiers de configuration sur un système Windows,
vous devez les sauver comme des fichiers Unix si votre éditeur offre cette
option sinon vous devez les faire passer par dos2unix avant d'essayer de
les utiliser. De la même manière, si vous copiez un fichier de configuration
depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix
sur la copie avant de l'utiliser avec Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
@ -144,8 +144,8 @@ Shorewall)</b>.</p>
<p>Les noms de zone sont définis dans <a href="Documentation.htm#Zones">/etc/shorewall/zones</a>.</p>
<p>Shorewall reconnaît aussi le système de firewall comme sa propre zone
- par défaut, le firewall lui même est connu en tant que <b>fw</b>.</p>
<p>Shorewall reconnaît aussi le système de firewall comme sa propre zone -
par défaut, le firewall lui même est connu en tant que <b>fw</b>.</p>
<p>Les règles concernant le trafic à autoriser ou à interdire sont exprimées
en utilisant les termes de zones.</p>
@ -243,7 +243,8 @@ ce fichier).</p>
<p>Les politiques précédentes vont :</p>
<ol>
<li>permettre toutes demandes de connexion depuis le firewall vers l'Internet</li>
<li>permettre toutes demandes de connexion depuis le firewall vers
l'Internet</li>
<li>drop (ignorer) toutes les demandes de connexion depuis l'Internet
vers votre firewall ou vers votre réseau local</li>
<li>Facultativement accepter toutes les demandes de connexion depuis
@ -269,8 +270,8 @@ votre firewall et vers Internet (si vous decommentez la politique pr
connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling
Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de
type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC),
votre interface extérieure sera aussi ppp0. Si votre connexion passe par
Numéris (ISDN), votre interface extérieure sera ippp0<b>.</b></p>
votre interface extérieure sera aussi ppp0. Si votre connexion passe par Numéris
(ISDN), votre interface extérieure sera ippp0<b>.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
@ -285,24 +286,24 @@ Num
<p align="left">Votre <i>interface DMZ</i> sera aussi un adaptateur Ethernet
(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs
appartenant à la DMZ seront connectés à ce même switch (note : si vous
n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement
au firewall par un <i>câble croisé</i>).</p>
appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez
qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au
firewall par un <i>câble croisé</i>).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u> Ne connectez pas l'interface interne et externe sur le même hub
ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas
que ce soit shorewall qui ne marche pas.</p>
ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que
ce soit shorewall qui ne marche pas.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
L'exemple de configuration de Shorewall pour trois interfaces suppose
que l'interface externe est <b>eth0, </b>l'interface locale est <b>eth1
</b> et que la DMZ est sur l'interface <b>eth2</b>. Si votre configuration
diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces
en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des
options qui sont spécifiées pour les interfaces. Quelques trucs :</p>
que l'interface externe est <b>eth0, </b>l'interface locale est <b>eth1 </b>
et que la DMZ est sur l'interface <b>eth2</b>. Si votre configuration diffère,
vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence.
Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont
spécifiées pour les interfaces. Quelques trucs :</p>
<ul>
<li>
@ -310,9 +311,9 @@ options qui sont sp
remplacer le "detect" dans la seconde colonne par un "-". </p>
</li>
<li>
<p align="left">Si votre interface externe est ppp0 ou ippp0 ou bien
si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la
liste d'option. </p>
<p align="left">Si votre interface externe est ppp0 ou ippp0 ou bien si
vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la liste
d'option. </p>
</li>
</ul>
@ -324,15 +325,14 @@ liste d'option. </p>
Internet (ISP) vous assignera une seule adresse IP (single Public IP address).
Cette adresse peut être assignée par le Dynamic Host Configuration Protocol
(DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez
(modem standard) ou établissez votre connexion PPP. Dans de rares cas ,
votre provider peu vous assigner une adresse statique (staticIP address);
cela signifie que vous configurez votre interface externe sur votre firewall
afin d'utiliser cette adresse de manière permanente. Une fois votre adresse
externe assignée, elle va être partagée par tout vos systèmes lors de l'accès
à Internet. Vous devrez assigner vos propres adresses à votre réseau local
(votre interface interne sur le firewall ainsi que les autres ordinateurs).
La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à
cette fin :</p>
(modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre
provider peu vous assigner une adresse statique (staticIP address); cela
signifie que vous configurez votre interface externe sur votre firewall afin
d'utiliser cette adresse de manière permanente. Une fois votre adresse externe
assignée, elle va être partagée par tout vos systèmes lors de l'accès à Internet.
Vous devrez assigner vos propres adresses à votre réseau local (votre interface
interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918
réserve plusieurs plages d'IP (Private IP address ranges) à cette fin :</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -353,12 +353,12 @@ cette fin :</p>
en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera
une masque (<i>Subnet Mask)</i> de 255.255.255.0. L'adresse x.y.z.0 est
réservée comme l'adresse du sous-réseau (<i>Subnet Address)</i> et x.y.z.255
est réservée en tant qu'adresse de broadcast du sous-réseau (<i>Subnet
Broadcast</i> <i>Address)</i>. Sous Shorewall, un sous-réseau est décrit/désigné
en utilisant la notation <a href="shorewall_setup_guide.htm#Subnets"><i>Classless
InterDomain Routing</i>(CIDR)</a> qui consiste en l'adresse du sous-réseau
suivie par "/24". Le "24" se réfère au nombre de bits "1" consécutifs dans
la partie gauche du masque de sous-réseau. </p>
est réservée en tant qu'adresse de broadcast du sous-réseau (<i>Subnet Broadcast</i>
<i>Address)</i>. Sous Shorewall, un sous-réseau est décrit/désigné en utilisant
la notation <a href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain
Routing</i>(CIDR)</a> qui consiste en l'adresse du sous-réseau suivie par
"/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie
gauche du masque de sous-réseau. </p>
</div>
<div align="left">
@ -393,17 +393,17 @@ la partie gauche du masque de sous-r
</div>
<div align="left">
<p align="left">Il est de convention d'assigner à l'interface interne la
première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple
précédent) ou la dernière utilisable (10.10.10.254).</p>
<p align="left">Il est de convention d'assigner à l'interface interne la première
adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple précédent)
ou la dernière utilisable (10.10.10.254).</p>
</div>
<div align="left">
<p align="left">L'un des buts d'un sous-réseau est de permettre à tous les
ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs
ils peuvent communiquer directement. Pour communiquer avec des systèmes
en dehors du sous-réseau, les ordinateurs envoient des paquets à travers
le gateway (routeur).</p>
ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils
peuvent communiquer directement. Pour communiquer avec des systèmes en dehors
du sous-réseau, les ordinateurs envoient des paquets à travers le gateway
(routeur).</p>
</div>
<div align="left">
@ -417,8 +417,8 @@ pointant sur l'adresse IP de l'interface DMZ du firewall. </p>
</div>
<p align="left">Cette courte description ne fait que survoler les concepts
de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur
l'adressage IP et le routage, je vous recommande chaudement <i>"IP Fundamentals:
de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage
IP et le routage, je vous recommande chaudement <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i> Thomas
A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
@ -451,10 +451,9 @@ rout
l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur
1. </p>
<p align="left">Sur les systèmes Linux, ce procédé est souvent appelé de
l'IP Masquerading mais vous verrez aussi le terme de Source Network Address
Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter
:</p>
<p align="left">Sur les systèmes Linux, ce procédé est souvent appelé de l'IP
Masquerading mais vous verrez aussi le terme de Source Network Address Translation
(SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter :</p>
<ul>
<li>
@ -483,8 +482,8 @@ Translation (SNAT) utilis
Si votre IP externe est statique, vous pouvez la mettre dans la troisième
colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre
firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de
mettre votre IP statique dans la troisième colonne permet un traitement
des paquets sortant un peu plus efficace.<br>
mettre votre IP statique dans la troisième colonne permet un traitement des
paquets sortant un peu plus efficace.<br>
</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
@ -507,10 +506,10 @@ des paquets sortant un peu plus efficace.<br>
serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse
RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter
directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes
de connexion au firewall qui ré écrit l'adresse de destination de votre
serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond,
le firewall applique automatiquement un SNAT pour ré écrire l'adresse source
dans la réponse.</p>
de connexion au firewall qui ré écrit l'adresse de destination de votre serveur,
et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall
applique automatiquement un SNAT pour ré écrire l'adresse source dans la
réponse.</p>
<p align="left">Ce procédé est appelé Port Forwarding ou Destination Network
Address Translation(DNAT). Vous configurez le port forwarding en utilisant
@ -635,10 +634,10 @@ IP externe).</li>
</table>
</blockquote>
<p>Si vous voulez avoir la possibilité de vous connecter à votre serveur
depuis le réseau local en utilisant votre adresse externe, et si vous avez
une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc-&gt;dmz
précédente par :</p>
<p>Si vous voulez avoir la possibilité de vous connecter à votre serveur depuis
le réseau local en utilisant votre adresse externe, et si vous avez une adresse
IP externe statique (fixe), vous pouvez remplacer la règle loc-&gt;dmz précédente
par :</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -709,8 +708,8 @@ pr
</table>
</blockquote>
<p>Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre
adresse IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p>Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre adresse
IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p><img border="0" src="images/BD21298_2.gif" width="13" height="13">
A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..</p>
@ -719,21 +718,21 @@ adresse IP externe, regardez <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p align="left">Normalement, quand vous vous connectez à votre fournisseur
(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le
firewall (Domain Name Service) est configuré automatiquement (c.a.d., le
fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous
donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez
manuellement votre serveur de nom primaire et secondaire. La manière dont
le DNS est configuré sur votre firewall est de votre responsabilité. Vous
pouvez procéder d'une de ses deux façons :</p>
firewall (Domain Name Service) est configuré automatiquement (c.a.d., le fichier
/etc/resolv.conf a été écrit). Il arrive que votre provider vous donne une
paire d'adresse IP pour les DNS (name servers) afin que vous configuriez manuellement
votre serveur de nom primaire et secondaire. La manière dont le DNS est configuré
sur votre firewall est de votre responsabilité. Vous pouvez procéder d'une
de ses deux façons :</p>
<ul>
<li>
<p align="left">Vous pouvez configurer votre système interne pour utiliser
les noms de serveurs de votre provider. Si votre fournisseur vous donne
les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur
site web, vous pouvez configurer votre système interne afin de les utiliser.
Si cette information n'est pas disponible, regardez dans /etc/resolv.conf
sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement
les noms de serveurs de votre provider. Si votre fournisseur vous donne les
adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site
web, vous pouvez configurer votre système interne afin de les utiliser. Si
cette information n'est pas disponible, regardez dans /etc/resolv.conf sur
votre firewall -- les noms des serveurs sont donnés dans l'enregistrement
"nameserver" dans ce fichier. </p>
</li>
<li>
@ -743,13 +742,13 @@ sur votre firewall -- les noms des serveurs sont donn
votre firewall ou dans la DMZ.<i> </i>Red Hat a un RPM pour mettre en cache
un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs
de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez
votre système interne pour utiliser le firewall lui même comme étant le
seul serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne
du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom
si vous décidez de faire tourner le serveur de nom sur votre firewall. Pour
permettre à vos systèmes locaux de discuter avec votre serveur cache de
nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le
réseau local; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.
votre système interne pour utiliser le firewall lui même comme étant le seul
serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall
(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez
de faire tourner le serveur de nom sur votre firewall. Pour permettre à
vos systèmes locaux de discuter avec votre serveur cache de nom, vous devez
ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous
ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.
</p>
</li>
@ -1063,7 +1062,8 @@ r
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>udp<br>
</td>
<td>53</td>
<td>#permet les accès DNS</td>
<td>depuis Internet</td>
@ -1138,11 +1138,11 @@ firewall depuis Internet, utilisez SSH :</p>
<p align="left"> <img border="0" src="images/BD21298_2.gif" width="13"
height="13" alt="Arrow">
La <a href="Install.htm">procédure d'installation</a> configure votre
système pour lancer Shorewall au boot du système, mais au début avec la
version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de
lancer Shorewall avec que la configuration soit finie. Une fois que vous
en avez fini avec la configuration du firewall, vous pouvez permettre le
lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.<br>
système pour lancer Shorewall au boot du système, mais au début avec la version
1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall
avec que la configuration soit finie. Une fois que vous en avez fini avec
la configuration du firewall, vous pouvez permettre le lancement de Shorewall
en supprimant le fichier /etc/shorewall/startup_disabled.<br>
</p>
<p align="left">IMPORTANT: Les utilisateurs des paquets .deb doivent éditer
@ -1152,8 +1152,8 @@ lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled
<div align="left">
<p align="left">Le firewall est activé en utilisant la commande "shorewall
start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé,
le routage est autorisé sur les hôtes qui possèdent une entrée dans <a
start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le
routage est autorisé sur les hôtes qui possèdent une entrée dans <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. Un
firewall qui tourne peut être relancé en utilisant la commande "shorewall
restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration
@ -1163,18 +1163,19 @@ le routage est autoris
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
L'exemple pour trois interfaces suppose que vous voulez permettre le routage
depuis/vers <b>eth1 </b>(votre réseau local) et<b> eth2</b>(DMZ) lorsque
Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées
à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble
d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.</p>
L'exemple pour trois interfaces suppose que vous voulez permettre le
routage depuis/vers <b>eth1 </b>(votre réseau local) et<b> eth2</b>(DMZ)
lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas
connectées à votre réseau local et votre DMZ, ou si vous voulez permettre
un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en
conséquence.</p>
</div>
<div align="left">
<p align="left">ATTENTION: Si vous êtes connecté à votre firewall depuis
Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez
pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous
êtes connectée) dans <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
<p align="left">ATTENTION: Si vous êtes connecté à votre firewall depuis Internet,
n'essayez pas une commande "shorewall stop" tant que vous n'avez pas ajouté
une entrée pour votre adresse IP (celle à partir de laquelle vous êtes connectée)
dans <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
De la même manière, je ne vous recommande pas d'utiliser "shorewall restart";
il est plus intéressant de créer une <i><a
href="configuration_file_basics.htm#Configs">configuration </a></i><i><a
@ -1183,31 +1184,11 @@ pas ajout
href="starting_and_stopping_shorewall.htm">"shorewall try"</a>.</p>
</div>
<p align="left"><font size="2">Last updated 12/20/2002 - <a
<p align="left"><font size="2">Last updated 05/19/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002 Thomas
M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a><br>
</p>
</body>
</html>

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

@ -30,8 +30,8 @@
</table>
<p align="left">Setting up a Linux system as a firewall for a small network
is a fairly straight-forward task if you understand the basics
and follow the documentation.</p>
is a fairly straight-forward task if you understand the basics and
follow the documentation.</p>
<p>This guide doesn't attempt to acquaint you with all of the features of
Shorewall. It rather focuses on what is required to configure Shorewall
@ -59,8 +59,8 @@ and follow the documentation.</p>
</b></p>
<p><b>Note however, that the Shorewall configuration produced by Mandrake
Internet Connection Sharing is strange and is apt to confuse you if you
use the rest of this documentation (it has two local zones; "loc" and "masq"
Internet Connection Sharing is strange and is apt to confuse you if you use
the rest of this documentation (it has two local zones; "loc" and "masq"
where "loc" is empty; this conflicts with this documentation which assumes
a single local zone "loc"). We therefore recommend that once you have set
up this sharing that you uninstall the Mandrake Shorewall RPM and install
@ -71,16 +71,16 @@ instructions in this Guide.</b><br>
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b>
program on your firewall system. As root, you can use the 'which'
command to check for this program:</p>
program on your firewall system. As root, you can use the 'which' command
to check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>I recommend that you first read through the guide to familiarize yourself
with what's involved then go back through it again making your
configuration changes. Points at which configuration changes are
recommended are flagged with <img border="0"
src="images/BD21298_.gif" width="13" height="13">
with what's involved then go back through it again making your configuration
changes. Points at which configuration changes are recommended
are flagged with <img border="0" src="images/BD21298_.gif"
width="13" height="13">
. Configuration notes that are unique to LEAF/Bering are
marked with <img src="images/leaflogo.gif" alt="(LEAF Logo)"
width="49" height="36">
@ -91,16 +91,16 @@ configuration changes. Points at which configuration changes are
system, you must save them as Unix files if your editor supports
that option or you must run them through dos2unix before trying to
use them. Similarly, if you copy a configuration file from your Windows
hard drive to a floppy disk, you must run dos2unix against the copy
before using it with Shorewall.</p>
hard drive to a floppy disk, you must run dos2unix against the copy before
using it with Shorewall.</p>
<ul>
<li><a
href="http://www.simtel.net/pub/pd/51438.html">Windows Version of
dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version of
dos2unix</a></li>
</ul>
@ -110,8 +110,8 @@ of dos2unix</a></li>
alt="">
    The configuration files for Shorewall are contained in the
directory /etc/shorewall -- for simple setups, you will only need to
deal with a few of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
deal with a few of these as described in this guide. After you have
<a href="Install.htm">installed Shorewall</a>, <b>download the <a
href="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface sample</a>,
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to
/etc/shorewall (these files will replace files with the same name).</b></p>
@ -164,12 +164,12 @@ in the <a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT
or DROP  the request is first checked against the rules in /etc/shorewall/common
that matches the request is applied. If that policy is REJECT or
DROP  the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the two-interface sample
has the following policies:</p>
<p>The /etc/shorewall/policy file included with the two-interface sample has
the following policies:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -240,10 +240,10 @@ has the following policies:</p>
<ol>
<li>allow all connection requests from your local network
to the internet</li>
<li>drop (ignore) all connection requests from the internet
to your firewall or local network</li>
<li>optionally accept all connection requests from the
firewall to the internet (if you uncomment the additional policy)</li>
<li>drop (ignore) all connection requests from the
internet to your firewall or local network</li>
<li>optionally accept all connection requests from
the firewall to the internet (if you uncomment the additional policy)</li>
<li>reject all other connection requests.</li>
</ol>
@ -258,9 +258,9 @@ make any changes that you wish.</p>
height="635">
</p>
<p align="left">The firewall has two network interfaces. Where Internet connectivity
is through a cable or DSL "Modem", the <i>External Interface</i> will be
the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<p align="left">The firewall has two network interfaces. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint <u>P</u>rotocol
over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
@ -277,8 +277,8 @@ the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>)
<p align="left">Your <i>Internal Interface</i> will be an ethernet adapter
(eth1 or eth0) and will be connected to a hub or switch. Your other
computers will be connected to the same hub/switch (note: If you
have only a single internal system, you can connect the firewall
directly to the computer using a <i>cross-over </i> cable).</p>
have only a single internal system, you can connect the firewall directly
to the computer using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
@ -313,18 +313,17 @@ list of options that are specified for the interfaces. Some hints:</p>
<h2 align="left">IP Addresses</h2>
<p align="left">Before going further, we should say a few words about Internet
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign
you a single <i> Public</i> IP address. This address may be assigned
via the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part
of establishing your connection when you dial in (standard modem) or
establish your PPP connection. In rare cases, your ISP may assign you
a<i> static</i> IP address; that means that you configure your firewall's
external interface to use that address permanently.<i> </i>However
your external address is assigned, it will be shared by all of your systems
when you access the Internet. You will have to assign your own addresses
in your internal network (the Internal Interface on your firewall plus
your other computers). RFC 1918 reserves several <i>Private </i>IP address
ranges for this purpose:</p>
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign you
a single <i> Public</i> IP address. This address may be assigned via
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of
establishing your connection when you dial in (standard modem) or establish
your PPP connection. In rare cases, your ISP may assign you a<i> static</i>
IP address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>However your external address
is assigned, it will be shared by all of your systems when you access
the Internet. You will have to assign your own addresses in your internal
network (the Internal Interface on your firewall plus your other computers).
RFC 1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -334,9 +333,9 @@ ranges for this purpose:</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    Before starting Shorewall, you should look at the
IP address of your external interface and if it is one of the
above ranges, you should remove the 'norfc1918' option from the
external interface's entry in /etc/shorewall/interfaces.</p>
IP address of your external interface and if it is one of the above
ranges, you should remove the 'norfc1918' option from the external
interface's entry in /etc/shorewall/interfaces.</p>
</div>
<div align="left">
@ -344,8 +343,8 @@ external interface's entry in /etc/shorewall/interfaces.</p>
sub-network </i>(<i>subnet)</i>.  For our purposes, we can consider a subnet
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such
a subnet will have a <i>Subnet Mask </i>of 255.255.255.0. The address
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255
is reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255 is
reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR) notation</a> with consists of the subnet address followed
@ -408,9 +407,9 @@ gateway</i> to be the IP address of the firewall's internal interface.
<p align="left">The foregoing short discussion barely scratches the surface
regarding subnetting and routing. If you are interested in learning
more about IP addressing and routing, I highly recommend <i>"IP
Fundamentals: What Everyone Needs to Know about Addressing &amp;
Routing",</i> Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
more about IP addressing and routing, I highly recommend <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i>
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left">The remainder of this quide will assume that you have configured
your network as shown here:</p>
@ -433,9 +432,9 @@ in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
<h2 align="left">IP Masquerading (SNAT)</h2>
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers
don't forward packets which have an RFC-1918 destination address.
When one of your local systems (let's assume computer 1) sends a connection
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When
one of your local systems (let's assume computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network
Address Translation </i>(NAT). The firewall rewrites the source address
in the packet to be the address of the firewall's external interface;
@ -448,10 +447,10 @@ is initiating the connection.
the destination address back to 10.10.10.1 and forwards the packet on
to computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> but you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> but you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<ul>
<li>
@ -468,9 +467,8 @@ with Netfilter:</p>
</ul>
<p align="left">In Shorewall, both Masquerading and SNAT are configured with
entries in the /etc/shorewall/masq file. You will normally use
Masquerading if your external IP is dynamic and SNAT if the IP
is static.</p>
entries in the /etc/shorewall/masq file. You will normally use Masquerading
if your external IP is dynamic and SNAT if the IP is static.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
@ -507,11 +505,11 @@ the third column in the /etc/shorewall/masq entry if you like although
<p align="left">One of your goals may be to run one or more servers on your
local computers. Because these computers have RFC-1918 addresses,
it is not possible for clients on the internet to connect directly
to them. It is rather necessary for those clients to address their
connection requests to the firewall who rewrites the destination address
to the address of your server and forwards the packet to that server.
When your server responds, the firewall automatically performs SNAT
to rewrite the source address in the response.</p>
to them. It is rather necessary for those clients to address their connection
requests to the firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -582,9 +580,9 @@ to rewrite the source address in the response.</p>
<ul>
<li>You must test the above rule from a client outside
of your local network (i.e., don't test from a browser running
on computers 1 or 2 or on the firewall). If you want to be able
to access your web server using the IP address of your external interface,
of your local network (i.e., don't test from a browser running on
computers 1 or 2 or on the firewall). If you want to be able to
access your web server using the IP address of your external interface,
see <a href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
<li>Many ISPs block incoming connection requests to
port 80. If you have problems connecting to your web server, try
@ -626,38 +624,38 @@ any DNAT rules that you require.</p>
<h2 align="left">Domain Name Server (DNS)</h2>
<p align="left">Normally, when you connect to your ISP, as part of getting
an IP address your firewall's <i>Domain Name Service </i>(DNS)
resolver will be automatically configured (e.g., the /etc/resolv.conf
file will be written). Alternatively, your ISP may have given you
the IP address of a pair of DNS <i> name servers</i> for you to manually
configure as your primary and secondary name servers. Regardless of
how DNS gets configured on your firewall, it is <u>your</u> responsibility
to configure the resolver in your internal systems. You can take one
of two approaches:</p>
an IP address your firewall's <i>Domain Name Service </i>(DNS) resolver
will be automatically configured (e.g., the /etc/resolv.conf file
will be written). Alternatively, your ISP may have given you the IP
address of a pair of DNS <i> name servers</i> for you to manually configure
as your primary and secondary name servers. Regardless of how DNS
gets configured on your firewall, it is <u>your</u> responsibility to
configure the resolver in your internal systems. You can take one of
two approaches:</p>
<ul>
<li>
<p align="left">You can configure your internal systems to use your ISP's
name servers. If you ISP gave you the addresses of their servers
or if those addresses are available on their web site, you can
configure your internal systems to use those addresses. If that
information isn't available, look in /etc/resolv.conf on your firewall
system -- the name servers are given in "nameserver" records in that
file. </p>
or if those addresses are available on their web site, you can configure
your internal systems to use those addresses. If that information
isn't available, look in /etc/resolv.conf on your firewall system
-- the name servers are given in "nameserver" records in that file.
</p>
</li>
<li>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    You can configure a<i> Caching Name Server </i>on your
firewall.<i> </i>Red Hat has an RPM for a caching name server
(the RPM also requires the 'bind' RPM) and for Bering users, there
is dnscache.lrp. If you take this approach, you configure your internal
systems to use the firewall itself as their primary (and only) name
server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your local
systems to talk to your caching name server, you must open port 53
(both UDP and TCP) from the local network to the firewall; you do
that by adding the following rules in /etc/shorewall/rules. </p>
    You can configure a<i> Caching Name Server </i>on
your firewall.<i> </i>Red Hat has an RPM for a caching name
server (the RPM also requires the 'bind' RPM) and for Bering users,
there is dnscache.lrp. If you take this approach, you configure your
internal systems to use the firewall itself as their primary (and only)
name server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your
local systems to talk to your caching name server, you must open port
53 (both UDP and TCP) from the local network to the firewall; you
do that by adding the following rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -746,8 +744,8 @@ that by adding the following rules in /etc/shorewall/rules. </p>
<div align="left">
<p align="left">Those rules allow DNS access from your firewall and may be
removed if you uncommented the line in /etc/shorewall/policy
allowing all connections from the firewall to the internet.</p>
removed if you uncommented the line in /etc/shorewall/policy allowing
all connections from the firewall to the internet.</p>
</div>
<div align="left">
@ -823,7 +821,8 @@ allowing all connections from the firewall to the internet.</p>
</div>
<div align="left">
<p align="left">Example - You want to run a Web Server on your firewall system:</p>
<p align="left">Example - You want to run a Web Server on your firewall
system:</p>
</div>
<div align="left">
@ -961,8 +960,8 @@ you want shell access to your firewall from the internet, use SSH:</p>
<p align="left"><br>
<img border="0" src="images/BD21298_.gif" width="13" height="13">
    Now edit your /etc/shorewall/rules file to add or
delete other connections as required.</p>
    Now edit your /etc/shorewall/rules file to add
or delete other connections as required.</p>
</div>
<div align="left">
@ -992,15 +991,15 @@ you have completed configuration of your firewall, you can enable Shorewall
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall
from your Netfilter configuration, use "shorewall clear".</p>
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
</div>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    The two-interface sample assumes that you want to enable
routing to/from <b>eth1 </b>(the local network) when Shorewall
    The two-interface sample assumes that you want to
enable routing to/from <b>eth1 </b>(the local network) when Shorewall
is stopped. If your local network isn't connected to <b>eth1</b> or
if you wish to enable access to/from other hosts, change /etc/shorewall/routestopped
accordingly.</p>
@ -1008,9 +1007,9 @@ if you wish to enable access to/from other hosts, change /etc/shorewall/
<div align="left">
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
the internet, do not issue a "shorewall stop" command unless
you have added an entry for the IP address that you are connected
from to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to
create an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
@ -1023,9 +1022,5 @@ create an <i><a href="configuration_file_basics.htm#Configs">alternate
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a><br>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

220
Shorewall-docs/upgrade_issues.htm
View File

@ -20,6 +20,7 @@
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
@ -32,13 +33,13 @@
</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>
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>
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>
@ -47,12 +48,25 @@ a host address) accessed through a particular interface.<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.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,
@ -64,21 +78,21 @@ there are two cases covered in this documentation where it can occur:<br>
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>
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>
<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>
@ -89,37 +103,42 @@ 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>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>
<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
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>
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
@ -130,11 +149,11 @@ subnetworks on the same interface then I recommend that you upgrade to Version
</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>
<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>
<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>
@ -156,20 +175,22 @@ subnetworks on the same interface then I recommend that you upgrade to Version
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>
<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>
@ -188,25 +209,25 @@ to avoid logging these packets.</li>
<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>
 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>
<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>
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>
@ -214,35 +235,35 @@ to or from the destination zone including rules that use the 'all' reserved
<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>
     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>
<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>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>
 <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>
@ -250,8 +271,8 @@ follows:<br>
<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>
<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>
@ -264,16 +285,16 @@ follows:<br>
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>
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>
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>
@ -298,8 +319,8 @@ documentation</a> for details.<br>
<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>
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>
@ -316,21 +337,22 @@ 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>
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>
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>
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>
@ -340,8 +362,8 @@ to add the following two Bering-specific rules to /etc/shorewall/rules:<
<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>
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
@ -349,8 +371,8 @@ to add the following two Bering-specific rules to /etc/shorewall/rules:<
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can be
rebuilt<br>
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    # from
non-SYN packets after takeover.<br>
 </font> </p>
@ -360,8 +382,8 @@ non-SYN packets after takeover.<br>
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>
-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>
@ -409,13 +431,11 @@ non-SYN packets after takeover.<br>
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 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>
<br>
<br>
</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
{