holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Changes for 1.3.13

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@402 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-01-14 20:32:45 +00:00
parent 5b9b519183
commit f04d58006f
57 changed files with 12980 additions and 11199 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
Lrp/etc/init.d/shorewall
View File

@ -70,7 +70,7 @@ list_count() {
#
# Mutual exclusion -- These functions are jackets for the mutual exclusion
# routines in /usr/lib/shorewall/functions. They invoke
# routines in $FUNCTIONS. They invoke
# the corresponding function in that file if the user did
# not specify "nolock" on the runline.
#
@ -833,6 +833,11 @@ validate_rule() {
target=ACCEPT
address=${address:=detect}
;;
DNAT-)
target=ACCEPT
address=${address:=detect}
logtarget=DNAT
;;
REDIRECT)
target=ACCEPT
address=${address:=all}
@ -983,6 +988,17 @@ validate_policy()
local zone1
local pc
local chain
local policy
local loglevel
local synparams
print_policy() # $1 = source zone, $2 = destination zone
{
[ $command != check ] || \
[ $1 = all ] || \
[ $2 = all ] || \
echo " Policy for $1 to $2 is $policy"
}
all_policy_chains=
@ -1048,27 +1064,34 @@ validate_policy()
for zone1 in $zones $FW all; do
eval pc=\$${zone}2${zone1}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${zone}2${zone1}_policychain=$chain
print_policy $zone $zone1
fi
done
done
else
for zone in $zones $FW all; do
eval pc=\$${zone}2${server}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${zone}2${server}_policychain=$chain
print_policy $zone $server
fi
done
fi
elif [ -n "$serverwild" ]; then
for zone in $zones $FW all; do
eval pc=\$${client}2${zone}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${client}2${zone}_policychain=$chain
print_policy $client $zone
fi
done
else
eval ${chain}_policychain=${chain}
print_policy $client $server
fi
done < $TMP_DIR/policy
@ -1234,7 +1257,7 @@ stop_firewall() {
[ -n "$NAT_ENABLED" ] && delete_nat
delete_proxy_arp
[ -n "$TC_ENABLED" ] && delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
setpolicy INPUT DROP
setpolicy OUTPUT DROP
@ -1344,12 +1367,18 @@ setup_tunnels() # $1 = name of tunnels file
run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options
else
run_iptables -A $inchain -p udp -s $1 --dport 500 $options
run_iptables -A $inchain -p udp -s $1 --dport 4500 $options
fi
for z in `separate_list $3`; do
if validate_zone $z; then
addrule ${FW}2${z} -p udp --sport 500 --dport 500 $options
if [ $2 = ipsec ]; then
addrule ${z}2${FW} -p udp --sport 500 --dport 500 $options
else
addrule ${z}2${FW} -p udp --dport 500 $options
addrule ${z}2${FW} -p udp --dport 4500 $options
fi
else
error_message "Warning: Invalid gateway zone ($z)" \
" -- Tunnel \"$tunnel\" may encounter keying problems"
@ -1820,6 +1849,7 @@ setup_tc() {
#
delete_tc()
{
clear_one_tc() {
tc qdisc del dev $1 root 2> /dev/null
tc qdisc del dev $1 ingress 2> /dev/null
@ -1846,7 +1876,7 @@ refresh_tc() {
echo "Refreshing Traffic Control Rules..."
delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
[ -n "$MARK_IN_FORWARD_CHAIN" ] && chain=tcfor || chain=tcpre
@ -2152,7 +2182,7 @@ add_a_rule()
add_nat_rule
fi
if [ $chain != ${FW}2${FW} ]; then
if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then
serv="${serv:+-d $serv}"
if [ -n "$loglevel" ]; then
@ -2229,14 +2259,23 @@ process_rule() # $1 = target
fi
logtarget="$target"
dnat_only=
# Convert 1.3 Rule formats to 1.2 format
[ "x$address" = "x-" ] && address=
case $target in
DNAT)
target=ACCEPT
address=${address:=detect}
;;
DNAT-)
target=ACCEPT
address=${address:=detect}
dnat_only=Yes
logtarget=DNAT
;;
REDIRECT)
target=ACCEPT
address=${address:=all}
@ -2379,7 +2418,7 @@ process_rules() # $1 = name of rules file
while read xtarget xclients xservers xprotocol xports xcports xaddress; do
case "$xtarget" in
ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT:*|REDIRECT|REDIRECT:*)
ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT-|DNAT:*|DNAT-:*|REDIRECT|REDIRECT:*)
expandv xclients xservers xprotocol xports xcports xaddress
if [ "x$xclients" = xall ]; then
@ -3233,7 +3272,7 @@ initialize_netfilter () {
run_iptables -t mangle -F && \
run_iptables -t mangle -X
[ -n "$TC_ENABLED" ] && delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
run_user_exit init
@ -3267,7 +3306,7 @@ initialize_netfilter () {
run_user_exit newnotsyn
if [ -n "$LOGNEWNOTSYN" ]; then
if [ "$LOGNEWNOTSYN" = ULOG ]; then
run_iptables -A newnotsyn -j ULOG \
run_iptables -A newnotsyn -j ULOG
--ulog-prefix "Shorewall:newnotsyn:DROP:"
else
run_iptables -A newnotsyn -j LOG \
@ -3352,7 +3391,7 @@ add_common_rules() {
if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then
echo "ULOG --ulog-prefix Shorewall:${1}:DROP:"
else
echo "LOG --log-prefix Shorewall:${1}:DROP: --log-level info"
echo "LOG --log-prefix Shorewall:${1}:DROP: --log-level $RFC1918_LOG_LEVEL"
fi
}
#
@ -4432,6 +4471,10 @@ do_initialize() {
TCP_FLAGS_LOG_LEVEL=
RFC1918_LOG_LEVEL=
MARK_IN_FORWARD_CHAIN=
SHARED_DIR=/usr/lib/shorewall
FUNCTIONS=
VERSION_FILE=
stopping=
have_mutex=
masq_seq=1
@ -4445,31 +4488,35 @@ do_initialize() {
trap "rm -rf $TMP_DIR; my_mutex_off; exit 2" 1 2 3 4 5 6 9
functions=/usr/lib/shorewall/functions
if [ -f $functions ]; then
. $functions
if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then
config=$SHOREWALL_DIR/shorewall.conf
else
startup_error "$functions does not exist!"
config=/etc/shorewall/shorewall.conf
fi
version_file=/usr/lib/shorewall/version
if [ -f $config ]; then
. $config
else
echo "$config does not exist!" >&2
exit 2
fi
[ -f $version_file ] && version=`cat $version_file`
#
# Strip the files that we use often
#
strip_file interfaces
strip_file hosts
FUNCTIONS=$SHARED_DIR/functions
run_user_exit shorewall.conf
run_user_exit params
if [ -f $FUNCTIONS ]; then
. $FUNCTIONS
else
startup_error "$FUNCTIONS does not exist!"
fi
VERSION_FILE=$SHARED_DIR/version
[ -f $VERSION_FILE ] && version=`cat $VERSION_FILE`
[ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall
[ -d $STATEDIR ] || mkdir -p $STATEDIR
[ -z "$FW" ] && FW=fw
ALLOWRELATED="`added_param_value_yes ALLOWRELATED $ALLOWRELATED`"
@ -4544,7 +4591,20 @@ do_initialize() {
[ -z "$RFC1918_LOG_LEVEL" ] && RFC1918_LOG_LEVEL=info
MARK_IN_FORWARD_CHAIN=`added_param_value_no MARK_IN_FORWARD_CHAIN $MARK_IN_FORWARD_CHAIN`
[ -n "$MARK_IN_FORWARD_CHAIN" ] && marking_chain=tcfor || marking_chain=tcpre
if [ -n "$TC_ENABLED" ]; then
CLEAR_TC=`added_param_value_yes CLEAR_TC $CLEAR_TC`
else
CLEAR_TC=
fi
run_user_exit params
#
# Strip the files that we use often
#
strip_file interfaces
strip_file hosts
}
#

4
Lrp/etc/shorewall/rules
View File

@ -24,6 +24,10 @@
# DNAT -- Forward the request to another
# system (and optionally another
# port).
# DNAT- -- Advanced users only.
# Like DNAT but only generates the
# DNAT iptables rule and not
# the companion ACCEPT rule.
# REDIRECT -- Redirect the request to a local
# port on the firewall.
#

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

@ -9,6 +9,13 @@
# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net)
##############################################################################
#
# You should not have to change the variables in this section -- they are set
# by the packager of your Shorewall distribution
#
SHARED_DIR=/usr/lib/shorewall
#
##############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
@ -51,7 +58,6 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
FW=fw
#
# SUBSYSTEM LOCK FILE
#

56
Lrp/sbin/shorewall
View File

@ -569,51 +569,65 @@ fi
[ -n "$SHOREWALL_DIR" ] && export SHOREWALL_DIR
functions=/usr/lib/shorewall/functions
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHARED_DIR=/usr/lib/shorewall
MUTEX_TIMEOUT=
if [ -f $functions ]; then
. $functions
if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then
config=$SHOREWALL_DIR/shorewall.conf
else
echo "$functions does not exist!" >&2
config=/etc/shorewall/shorewall.conf
fi
if [ -f $config ]; then
. $config
else
echo "$config does not exist!" >&2
exit 2
fi
firewall=/usr/lib/shorewall/firewall
[ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall
if [ ! -f $firewall ]; then
FIREWALL=$SHARED_DIR/firewall
FUNCTIONS=$SHARED_DIR/functions
VERSION_FILE=$SHARED_DIR/version
if [ -f $FUNCTIONS ]; then
. $FUNCTIONS
else
echo "$FUNCTIONS does not exist!" >&2
exit 2
fi
if [ ! -f $FIREWALL ]; then
echo "ERROR: Shorewall is not properly installed"
if [ -L $firewall ]; then
echo " $firewall is a symbolic link to a"
if [ -L $FIREWALL ]; then
echo " $FIREWALL is a symbolic link to a"
echo " non-existant file"
else
echo " The file /usr/lib/shorewall/firewall does not exist"
echo " The file $FIREWALL does not exist"
fi
exit 2
fi
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
version_file=/usr/lib/shorewall/version
if [ -f $version_file ]; then
version=`cat $version_file`
if [ -f $VERSION_FILE ]; then
version=`cat $VERSION_FILE`
else
echo "ERROR: Shorewall is not properly installed"
echo " The file /usr/lib/shorewall/version does not exist"
echo " The file $VERSION_FILE does not exist"
exit 1
fi
banner="Shorewall-$version Status at $HOSTNAME -"
get_statedir
case `echo -e` in
-e*)
RING_BELL="echo \'\a\'"
RING_BELL="echo \a"
;;
*)
RING_BELL="echo -e \'\a\'"
RING_BELL="echo -e \a"
;;
esac
@ -629,11 +643,11 @@ esac
case "$1" in
start|stop|restart|reset|clear|refresh|check)
[ $# -ne 1 ] && usage 1
exec $firewall $debugging $nolock $1
exec $FIREWALL $debugging $nolock $1
;;
add|delete)
[ $# -ne 3 ] && usage 1
exec $firewall $debugging $nolock $1 $2 $3
exec $FIREWALL $debugging $nolock $1 $2 $3
;;
show)
[ $# -gt 2 ] && usage 1

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

@ -1 +1 @@
1.3.12
1.3.13

43
STABLE/changelog.txt
View File

@ -1,43 +1,10 @@
Changes since 1.3.11
Changes since 1.3.12
1. Fixed DNAT/REDIRECT bug with excluded sub-zones.
1. Added 'DNAT-' target.
2. "shorewall refresh" now refreshes the traffic shaping rules
2. Print policies in 'check' command.
3. Turned off debugging after error.
3. Added CLEAR_TC option.
4. Removed drop of INVALID state output ICMP packets.
4. Added SHARED_DIR option.
5. Replaced 'sed' invocation in separate_list() by shell code (speedup).
6. Replaced 'wc' invocation in list_count() by shell code (speedup)
7. Replaced 'sed' invocation in run_iptables() by shell code and
optomized (speedup)
8. Only read the interfaces file once (speedup)
9. Only read the policy file once (speedup)
10. Removed redundant function input_chains() (duplicate of first_chains())
11. Generated an error if 'lo' is defined in the interfaces file.
12. Clarified error message where ORIGINAL DEST is specified on an
ACCEPT, DROP or REJECT rule.
13. Added "shorewall show classifiers" command and added packet
classification filter display to "shorewall monitor"
14. Added an error message when the destination in a rule contained a
MAC address.
15. Added ULOG target support.
16. Add MARK_IN_FORWARD option.
17. General Cleanup for Release
18. Release changes and add init, start, stop and stopped files.
19. Add headings to NAT and Mangle tables in "shorewall status" output

2024
STABLE/documentation/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

41
STABLE/documentation/Documentation_Index.htm
View File

@ -1,28 +1,31 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>The Documentation Index</title>
</head>
<body>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>The Documentation Index</title>
</head>
<body>
<h1 align="center">The Shorewall Documentation Index</h1>
<h1 align="center">has Moved
<a href="shorewall_quickstart_guide.htm#Documentation">Here</a></h1>
<p><font size="2">
Last updated 8/9/2002
-
<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 Thomas M. Eastep.</font></a></font></p>
<h1 align="center">has Moved <a
href="shorewall_quickstart_guide.htm#Documentation">Here</a></h1>
<p><font size="2"> Last updated 8/9/2002 -
<a href="support.htm">Tom Eastep</a></font> </p>
<p> <a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
<br>
</body>
</html>

539
STABLE/documentation/FAQ.htm
View File

@ -30,6 +30,7 @@
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall FAQs</font></h1>
</td>
</tr>
@ -51,21 +52,22 @@
<p align="left"><b>2.</b> <a href="#faq2">I <b>port forward</b> www requests
to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5
in my local network. <b>External clients can browse</b> http://www.mydomain.com
in my local network. <b>External clients can browse</b> http://www.mydomain.com
but <b>internal 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>
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>
<p align="left"><b>3. </b><a href="#faq3">I want to use <b>Netmeeting/MSN
Messenger </b>with Shorewall. What do I do?</a></p>
<p align="left"><b>3. </b><a href="#faq3">I want to use <b>Netmeeting</b>
or <b>MSN Instant Messenger </b>with Shorewall. What do I
do?</a></p>
<p align="left"><b>4. </b><a href="#faq4">I just used an online port scanner
to check my firewall and it shows <b>some ports as 'closed'
rather than 'blocked'.</b> Why?</a></p>
rather than 'blocked'.</b> Why?</a></p>
<p align="left"><b>4a. </b><a href="#faq4a">I just ran an <b>nmap UDP scan</b>
of my firewall and it showed 100s of ports as open!!!!</a></p>
@ -76,16 +78,25 @@ rather than 'blocked'.</b> Why?</a></p>
<p align="left"><b>6. </b><a href="#faq6">Where are the <b>log messages</b>
written and how do I <b>change the destination</b>?</a></p>
<p align="left"><b>6a. </b><a href="#faq6a">Are there any <b>log parsers</b>
that work with Shorewall?</a></p>
<p align="left"><b>6b. <a href="#faq6b">DROP messages</a></b><a
href="#faq6b"> on port 10619 are <b>flooding the logs</b> with their connect
requests. Can i exclude these error messages for this port temporarily from
logging in Shorewall?</a><br>
</p>
<p align="left"><b>6c. </b><a href="#faq6c">All day long I get a steady flow
of these <b>DROP messages from port 53</b> <b>to some high numbered port</b>. 
They get dropped, but what the heck are they?</a><br>
</p>
<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
'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
on RedHat</b> I get messages about insmod failing -- what's
wrong?</a></p>
wrong?</a></p>
<p align="left"><b>9. </b><a href="FAQ.htm#faq9">Why can't Shorewall <b>detect
my interfaces </b>properly?</a></p>
@ -94,7 +105,7 @@ wrong?</a></p>
it work with?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Why isn't there a <b>GUI</b></a></p>
@ -102,13 +113,13 @@ wrong?</a></p>
<p align="left"><b>14. </b><a href="#faq14">I'm connected via a cable modem
and it has an internel web server that allows me to configure/monitor
it but as expected if I enable <b> rfc1918 blocking</b> for my
eth0 interface, it also blocks the <b>cable modems web server</b></a>.</p>
it but as expected if I enable <b> rfc1918 blocking</b> for
my eth0 interface, it also blocks the <b>cable modems web server</b></a>.</p>
<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>
If I enable RFC 1918 filtering on my external interface, <b>my
DHCP client cannot renew its lease</b>.</a></p>
<p align="left"><b>15. </b><a href="#faq15"><b>My local systems can't see
out to the net</b></a></p>
@ -116,29 +127,37 @@ DHCP client cannot renew its lease</b>.</a></p>
<p align="left"><b>16. </b><a href="#faq16">Shorewall is writing <b>log messages
all over my console</b> making it unusable!<br>
</a></p>
<b>17</b>. <a href="#faq17">How do I find
out <b>why this traffic is</b> getting <b>logged?</b></a><br>
<b>17</b>. <a href="#faq17">How do
I find out <b>why this traffic is</b> getting <b>logged?</b></a><br>
<br>
<b>18.</b> <a href="#faq18">Is there any way to use <b>aliased
ip addresses</b> with Shorewall, and maintain separate rulesets for
different IPs?</a><br>
<b>18.</b> <a href="#faq18">Is there any way to use
<b>aliased ip addresses</b> with Shorewall, and maintain separate
rulesets for different IPs?</a><br>
<br>
<b>19. </b><a href="#faq19">I have added <b>entries to /etc/shorewall/tcrules</b>
but they <b>don't </b>seem to <b>do anything</b>. Why?</a><br>
<b>19. </b><a href="#faq19">I have added <b>entries to
/etc/shorewall/tcrules</b> but they <b>don't </b>seem to <b>do anything</b>.
Why?</a><br>
<br>
<b>20. </b><a href="#faq20">I have just set up a server. <b>Do
I have to change Shorewall to allow access to my server from the internet?<br>
<b>20. </b><a href="#faq20">I have just set up a server.
<b>Do I have to change Shorewall to allow access to my server from
the internet?<br>
<br>
</b></a><b>21. </b><a href="#faq21">I see these <b>strange log entries
</b>occasionally; what are they?<br>
</b>occasionally; what are they?<br>
</a><br>
<b>22. </b><a href="#faq22">I have some <b>iptables commands </b>that I
want to <b>run when Shorewall starts.</b> Which file do I put them in?</a><br>
<b>22. </b><a href="#faq22">I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do I put them in?</a><br>
<br>
<b>23. </b><a href="#faq23">Why do you use such <b>ugly fonts</b> on
your <b>web site</b>?</a><br>
<br>
<b>24: </b><a href="#faq24">How can I <b>allow conections</b> to let's
say the ssh port only<b> from specific IP Addresses</b> on the internet?</a><br>
<hr>
<h4 align="left"><a name="faq1"></a>1. I want to forward UDP port 7777 to
my my personal PC with IP address 192.168.1.5. I've looked everywhere
and can't find how to do it.</h4>
my my personal PC with IP address 192.168.1.5. I've looked
everywhere and can't find how to do it.</h4>
<p align="left"><b>Answer: </b>The <a
href="Documentation.htm#PortForward"> first example</a> in the <a
@ -258,11 +277,13 @@ want to <b>run when Shorewall starts.</b> Which file do I put them in?</a><br>
<p align="left"><b>Answer: </b>That is usually the result of one of two things:</p>
<ul>
<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 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>
</ul>
@ -271,33 +292,36 @@ want to <b>run when Shorewall starts.</b> Which file do I put them in?</a><br>
<b>Answer: </b>To further diagnose this problem:<br>
<ul>
<li>As root, type "iptables -t nat -Z". This clears the
NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port from an external
host.</li>
<li>As root, type "iptables -t nat -Z". This clears
the NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port from an
external host.</li>
<li>As root type "shorewall show nat"</li>
<li>Locate the appropriate DNAT rule. It will be in a chain
called <i>zone</i>_dnat where <i>zone</i> is the zone that includes
the  ('net' 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 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>
<li>Locate the appropriate DNAT rule. It will be
in a chain called <i>zone</i>_dnat where <i>zone</i> is the
zone that includes the ('net' 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 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>
<li>If the packet count is zero:</li>
<ul>
<li>the connection request is not reaching your server
(possibly it is being blocked by your ISP); or</li>
<li>you are trying to connect to a secondary IP address
on your firewall and 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 or ethereal to further diagnose the problem.<br>
<li>the connection request is not reaching your
server (possibly it is being blocked by your ISP); or</li>
<li>you are trying to connect to a secondary IP
address on your firewall and 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 or ethereal to further diagnose the problem.<br>
</li>
</ul>
</ul>
@ -310,27 +334,28 @@ should be the IP address of the firewall's interface to the server).</li>
<p align="left"><b>Answer: </b>I have two objections to this setup.</p>
<ul>
<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>
<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>
<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>
<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>
</ul>
<p align="left">If you insist on an IP solution to the accessibility problem
rather than a DNS solution, then assuming that your external
interface is eth0 and your internal interface is eth1 and that
eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, do
the following:</p>
interface is eth0 and your internal interface is eth1 and that
eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, do
the following:</p>
<p align="left">a) In /etc/shorewall/interfaces, specify "multi" as an option
for eth1 (No longer required as of Shorewall version 1.3.9).</p>
@ -423,14 +448,14 @@ the following:</p>
<div align="left">
<p align="left">Using this technique, you will want to configure your DHCP/PPPoE
client to automatically restart Shorewall each time that you
get a new IP address.</p>
get a new IP address.</p>
</div>
<h4 align="left"><a name="faq2a"></a>2a. I have a zone "Z" with an RFC1918
subnet and I use static NAT 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 can't access each
other using their DNS names.</h4>
subnet and I use static NAT 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 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
@ -438,11 +463,11 @@ other using their DNS names.</h4>
<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>
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) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
(If you are running a Shorewall version earlier than 1.3.9).<br>
@ -540,29 +565,32 @@ Z-&gt;Z traffic through your firewall then:</p>
</table>
</blockquote>
<h4 align="left"><a name="faq3"></a>3. I want to use Netmeeting/MSN Messenger
with Shorewall. What do I do?</h4>
<h4 align="left"><a name="faq3"></a>3. I want to use Netmeeting or MSN Instant
Messenger with Shorewall. What do I do?</h4>
<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. Also check the Netfilter
mailing list archives at <a href="http://netfilter.samba.org">http://netfilter.samba.org</a>.
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>.
</p>
<h4 align="left"><a name="faq4"></a>4. I just used an online port scanner
to check my firewall and it shows some ports as 'closed' rather
than 'blocked'. Why?</h4>
to check my firewall and it shows some ports 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 on LAN segments
connected to the Firewall. </p>
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
@ -573,10 +601,10 @@ by Windows (Windows <u>can</u> be configured to use the DCE cell locator
<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, restart Shorewall and do the
nmap UDP scan again.</p>
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, restart Shorewall and do the
nmap UDP scan again.</p>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
can't ping through the firewall</h4>
@ -587,7 +615,7 @@ nmap UDP scan again.</p>
<p align="left">a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.<br>
b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef<br>
c) Add the following to /etc/shorewall/icmpdef:
</p>
</p>
<blockquote>
@ -601,12 +629,12 @@ nmap UDP scan again.</p>
<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
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
<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 restart"). </p>
@ -616,7 +644,7 @@ see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
<div align="left">
<pre align="left"> LOGLIMIT=""<br> LOGBURST=""<br><br>Beginning with Shorewall version 1.3.12, you can <a
href="configuration_file_basics.htm#Levels">set up Shorewall to log all of its messages to a separate file</a>.<br></pre>
href="shorewall_logging.html">set up Shorewall to log all of its messages to a separate file</a>.<br></pre>
</div>
<h4 align="left"><a name="faq6a"></a>6a. Are there any log parsers that work
@ -636,19 +664,45 @@ see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
http://www.logwatch.org</a><br>
</p>
</blockquote>
I personnaly use Logwatch. It emails me a report each day from my various
systems with each report summarizing the logged activity on the corresponding
system. 
I personnaly use Logwatch. It emails me a report each day from
my various systems with each report summarizing the logged activity on
the corresponding system.
<h4 align="left"><b><a name="faq6b"></a>6b. DROP messages</b> on port 10619
are <b>flooding the logs</b> with their connect requests. Can i exclude these
error messages for this port temporarily from logging in Shorewall?</h4>
Temporarily add the following rule:<br>
<pre> DROP    net    fw    udp    10619</pre>
<h4 align="left"><a name="faq6c"></a>6c. All day long I get a steady flow
of these DROP messages from port 53 to some high numbered port.  They get
dropped, but what the heck are they?</h4>
<pre>Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00<br> SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00<br> TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33 </pre>
<b>Answer: </b>There are two possibilities:<br>
<ol>
<li>They are late-arriving replies to DNS queries.</li>
<li>They are corrupted reply packets.</li>
</ol>
You can distinguish the difference by setting the <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>
<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>
</blockquote>
The above file is also include in all of my sample configurations available
in the <a href="shorewall_quickstart_guide.htm">Quick Start Guides</a>.<br>
<h4 align="left"><a name="faq7"></a>7. When I stop Shorewall using 'shorewall
stop', I can't connect to anything. Why doesn't that command work?</h4>
stop', I can't connect to anything. Why doesn't 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>
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>
I get messages about insmod failing -- what's wrong?</h4>
<p align="left"><b>Answer: </b>The output you will see looks something like
this:</p>
@ -685,9 +739,9 @@ I get messages about insmod failing -- what's wrong?</h4>
</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
@ -703,31 +757,32 @@ local zone is defined as all hosts connected through eth1</p>
<h4 align="left"><a name="faq12"></a>12. Why isn't there a GUI?</h4>
<p align="left"><b>Answer: </b>Every time I've started to work on one, I
find myself doing other things. I guess I just don't care enough if
Shorewall has a GUI to invest the effort to create one myself. There
are several Shorewall GUI projects underway however and I will publish
links to them when the authors feel that they are ready. </p>
<p align="left"><b>Answer: </b>Every time I've started to work on one, I find
myself doing other things. I guess I just don't care enough if Shorewall
has a GUI to invest the effort to create one myself. There are several
Shorewall GUI projects underway however and I will publish links to
them when the authors feel that they are ready. </p>
<h4 align="left"> <a name="faq13"></a>13. Why do you call it "Shorewall"?</h4>
<p align="left"><b>Answer: </b>Shorewall is a concatenation of "<u>Shore</u>line"
(<a href="http://www.cityofshoreline.com">the city where
I live</a>) and "Fire<u>wall</u>". The full name of the product
is actually "Shoreline Firewall" but "Shorewall" is must more commonly used.</p>
I live</a>) and "Fire<u>wall</u>". The full name of the product
is actually "Shoreline Firewall" but "Shorewall" is must more commonly
used.</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>
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>
@ -766,10 +821,10 @@ 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,
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>
you would add two entries to /etc/shorewall/rfc1918: <br>
</p>
<blockquote>
@ -796,6 +851,7 @@ you would add two entries to /etc/shorewall/rfc1918: <br>
</tr>
</tbody>
</table>
@ -803,10 +859,10 @@ you would add two entries to /etc/shorewall/rfc1918: <br>
</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">
@ -818,9 +874,9 @@ its lease.</h4>
the net</h4>
<p align="left"><b>Answer: </b>Every time I read "systems can't see out to
the net", I wonder where the poster bought computers with eyes
and what those computers will "see" when things are working properly.
That aside, the most common causes of this problem are:</p>
the net", I wonder where the poster bought computers with
eyes and what those computers will "see" when things are working
properly. That aside, the most common causes of this problem are:</p>
<ol>
<li>
@ -839,8 +895,8 @@ its lease.</h4>
<p align="left">The DNS settings on the local systems are wrong or the
user is running a DNS server on the firewall and hasn't enabled
UDP and TCP port 53 from the firewall to the internet.</p>
user is running a DNS server on the firewall and hasn't
enabled UDP and TCP port 53 from the firewall to the internet.</p>
</li>
</ol>
@ -851,59 +907,60 @@ its lease.</h4>
<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>
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>
logged?</h4>
<b>Answer: </b>Logging occurs out of a number
of chains (as indicated in the log message) in Shorewall:<br>
<ol>
<li><b>man1918 - </b>The destination address is listed
in /etc/shorewall/rfc1918 with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b> - The source address is listed in
/etc/shorewall/rfc1918 with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>man1918 - </b>The destination address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b> - The source address is listed
in /etc/shorewall/rfc1918 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
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>
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>
<li><b>&lt;interface&gt;_mac</b> - The packet is being logged
under the <b>maclist</b> <a
<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>
<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> <a
<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> <a
<li><b>badpkt </b>- The packet is being logged
under the <b>dropunclean</b> <a
href="Documentation.htm#Interfaces">interface option</a> as specified
in the <b>LOGUNCLEAN </b>setting in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is being logged because
the source IP is blacklisted in the<a
in the <b>LOGUNCLEAN </b>setting in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is being logged
because the source IP is blacklisted in the<a
href="Documentation.htm#Blacklist"> /etc/shorewall/blacklist </a>file.</li>
<li><b>newnotsyn </b>- The packet is being logged because
it is a TCP packet that is not part of any current connection yet
it is not a syn packet. Options affecting the logging of such packets
include <b>NEWNOTSYN </b>and <b>LOGNEWNOTSYN </b>in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> - The packet has
a source IP address that isn't in any of your defined zones ("shorewall
check" and look at the printed zone definitions) or the chain is FORWARD
and the destination IP isn't in any of your defined zones.</li>
<li><b>logflags </b>- The packet is being logged because it failed
the checks implemented by the <b>tcpflags </b><a
<li><b>newnotsyn </b>- The packet is being logged
because it is a TCP packet that is not part of any current connection
yet it is not a syn packet. Options affecting the logging of such
packets include <b>NEWNOTSYN </b>and <b>LOGNEWNOTSYN
</b>in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> - The packet
has a source IP address that isn't in any of your defined zones
("shorewall check" and look at the printed zone definitions) or
the chain is FORWARD and the destination IP isn't in any of your defined
zones.</li>
<li><b>logflags </b>- The packet is being logged because
it failed the checks implemented by the <b>tcpflags </b><a
href="Documentation.htm#Interfaces">interface option</a>.<br>
</li>
@ -911,11 +968,11 @@ a source IP address that isn't in any of your defined zones ("shorewall
<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. You simply use the IP address in your
rules (or if you use NAT, use the local IP address in your rules).
<b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated and will
disappear eventually. Neither iproute (ip and tc) nor iptables supports
that notation so neither does Shorewall. <br>
<b>Answer: </b>Yes. You simply use the IP address
in your rules (or if you use NAT, use the local IP address in your
rules). <b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated
and will disappear eventually. Neither iproute (ip and tc) nor iptables
supports that notation so neither does Shorewall. <br>
<br>
<b>Example 1:</b><br>
<br>
@ -923,7 +980,8 @@ that notation so neither does Shorewall. <br>
<pre wrap=""><span class="moz-txt-citetags"></span> # Accept AUTH but only on address 192.0.2.125<br><span
class="moz-txt-citetags"></span><br><span class="moz-txt-citetags"></span> ACCEPT net fw:192.0.2.125 tcp auth<br><span
class="moz-txt-citetags"></span></pre>
<span class="moz-txt-citetags"></span><b>Example 2 (NAT):</b><br>
<span class="moz-txt-citetags"></span><b>Example 2
(NAT):</b><br>
<br>
<span class="moz-txt-citetags"></span>/etc/shorewall/nat<br>
@ -945,9 +1003,10 @@ that notation so neither does Shorewall. <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>
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>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -956,64 +1015,76 @@ that notation so neither does Shorewall. <br>
<blockquote>
<pre>Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00<br> SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 <br> [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]<br></pre>
</blockquote>
192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal
LAN<br>
192.0.2.3 is external on my firewall... 172.16.0.0/24 is
my internal LAN<br>
<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>
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>
<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>
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>
<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, 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>
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, 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>
<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 I put them in?</h4>
I want to <b>run when Shorewall starts.</b> Which file do I put them
in?</h4>
You can place these commands in 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>
<br>
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>
<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>
<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>
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>
<pre>    net:&lt;ip1&gt;,&lt;ip2&gt;,...<br></pre>
Example:<br>
<pre> ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22<br></pre>
<div align="left"> </div>
<font size="2">Last updated 12/13/2002 - <a
<font size="2">Last updated 1/8/2003 - <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><br>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

4
STABLE/documentation/IPIP.htm
View File

@ -188,8 +188,8 @@ system. The systems in the two masqueraded subnetworks can now talk to each
other</p>
<p><font size="2">Updated 8/22/2002 - <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 Thomas M. Eastep.</font></a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
</body>

4
STABLE/documentation/IPSEC.htm
View File

@ -359,8 +359,8 @@ script will issue the command":<br>
<p><font size="2">Last updated 10/23/2002 - </font><font size="2">
<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 Thomas M. Eastep.</font></a></font></p>
<p><a href="copyright.htm"><font size="2">
Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
<br>
<br>
</body>

4
STABLE/documentation/Install.htm
View File

@ -199,8 +199,8 @@ by traffic control/shaping.</li>
<p><font size="2">Updated 10/28/2002 - <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 Thomas M. Eastep.</font></a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
<br>
<br>
</body>

61
STABLE/documentation/MAC_Validation.html
View File

@ -28,23 +28,26 @@
<br>
Beginning with Shorewall version 1.3.10, all traffic from an interface
or from a subnet on an interface can be verified to originate from a defined
set of MAC addresses. Furthermore, each MAC address may be optionally associated
with one or more IP addresses. <br>
<br>
<b>You must have the iproute package (ip utility) installed to use MAC Verification.</b><br>
<br>
There are four components to this facility.<br>
set of MAC addresses. Furthermore, each MAC address may be optionally
associated with one or more IP addresses. <br>
<br>
<b>You must have the iproute package (ip utility) installed to use MAC
Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- module name ipt_mac.o).</b><br>
<br>
There are four components to this facility.<br>
<ol>
<li>The <b>maclist</b> interface option in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. When
this option is specified, all traffic arriving on the interface is subjet
to MAC verification.</li>
<li>The <b>maclist </b>option in <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>.
When this option is specified for a subnet, all traffic from that subnet
is subject to MAC verification.</li>
<li>The <b>maclist </b>option in <a
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>. When this option
is specified for a subnet, all traffic from that subnet is subject to MAC
verification.</li>
<li>The /etc/shorewall/maclist file. This file is used to associate
MAC addresses with interfaces and to optionally associate IP addresses with
MAC addresses with interfaces and to optionally associate IP addresses with
MAC addresses.</li>
<li>The <b>MACLIST_DISPOSITION </b>and <b>MACLIST_LOG_LEVEL </b>variables
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
@ -60,12 +63,12 @@ requests that fail verification are to be logged. If set the the empty value
<ul>
<li>INTERFACE - The name of an ethernet interface on the Shorewall
system.</li>
system.</li>
<li>MAC - The MAC address of a device on the ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in this
column although you may use that format if you so choose.</li>
<li>IP Address - An optional comma-separated list of IP addresses for
the device whose MAC is listed in the MAC column.</li>
<li>IP Address - An optional comma-separated list of IP addresses
for the device whose MAC is listed in the MAC column.</li>
</ul>
@ -78,35 +81,31 @@ system.</li>
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,filterping,maclist<br> dmz eth1 192.168.2.255 filterping<br> net eth3 206.124.146.255 filterping,blacklist<br> - texas 192.168.9.255 filterping<br> loc ppp+ - filterping<br></pre>
<b>/etc/shorewall/maclist:</b><br>
<pre> #INTERFACE MAC IP ADDRESSES (Optional)<br> eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie<br> eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry<br> eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa<br> eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)<br> eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap<br></pre>
As shown above, I use MAC Verification on <a href="myfiles.htm">my local
zone</a>.<br>
<pre> #INTERFACE MAC IP ADDRESSES (Optional)<br> eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie<br> eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry<br> eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa<br> eth2 00:A0:CC:DB:31:C4 192.168.1.128/26 #PPTP Clients to server on Ursa<br> eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)<br> eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap<br></pre>
As shown above, I use MAC Verification on <a href="myfiles.htm">my
local zone</a>.<br>
<h3>Example 2: Router in Local Zone</h3>
Suppose now that I add a second ethernet segment to my local zone and
gateway that segment via a router with MAC address 00:06:43:45:C6:15 and
IP address 192.168.1.253. Hosts in the second segment have IP addresses in
the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
gateway that segment via a router with MAC address 00:06:43:45:C6:15 and
IP address 192.168.1.253. Hosts in the second segment have IP addresses
in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
file:<br>
<pre> eth2 00:06:43:45:C6:15 192.168.1.253,192.168.2.0/24<br></pre>
This entry accomodates traffic from the router itself (192.168.1.253)
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.
<p><font size="2"> Updated 12/22/2002 - <a href="support.htm">Tom Eastep</a>
by the router so that traffic's MAC address will be that of the router
(00:06:43:45:C6:15) and not that of the host sending the traffic.
<p><font size="2"> Updated 1/7/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
&copy; <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>
<br>
<br>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</body>
</html>

120
STABLE/documentation/NAT.htm
View File

@ -1,43 +1,59 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Shorewall NAT</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall NAT</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<blockquote>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Static NAT</font></h1>
<h1 align="center"><font color="#ffffff">Static NAT</font></h1>
</td>
</tr>
</tbody>
</table>
<p><font color="#FF0000"><b>IMPORTANT: If all you want to do is forward
ports to servers behind your firewall, you do NOT want to use static NAT.
Port forwarding can be accomplished with simple entries in the
<p><font color="#ff0000"><b>IMPORTANT: If all you want to do is forward
ports to servers behind your firewall, you do NOT want to use static
NAT. Port forwarding can be accomplished with simple entries in the
<a href="Documentation.htm#Rules">rules file</a>.</b></font></p>
<p>Static NAT is a way to make systems behind a
firewall and configured with private IP addresses (those
reserved for private use in RFC1918) appear to have public IP
addresses.</p>
<p>The following figure represents a static NAT
environment.</p>
<p align="center"><strong>
<img src="images/staticnat.png" width="435" height="397"></strong></p>
<blockquote>
</blockquote>
<p>Static NAT is a way to make systems behind a firewall and configured
with private IP addresses (those reserved for private use in RFC1918)
appear to have public IP addresses. Before you try to use this technique,
I strongly recommend that you read the <a
href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
<p>The following figure represents a static NAT environment.</p>
<p align="center"><strong> <img src="images/staticnat.png"
width="435" height="397">
</strong></p>
<blockquote> </blockquote>
<p align="left">Static NAT can be used to make the systems with the
10.1.1.* addresses appear to be on the upper (130.252.100.*) subnet. If we
assume that the interface to the upper subnet is eth0, then the following
/etc/shorewall/NAT file would make the lower left-hand system appear to have
IP address 130.252.100.18 and the right-hand one to have IP address
10.1.1.* addresses appear to be on the upper (130.252.100.*) subnet. If
we assume that the interface to the upper subnet is eth0, then the following
/etc/shorewall/NAT file would make the lower left-hand system appear
to have IP address 130.252.100.18 and the right-hand one to have IP address
130.252.100.19.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>EXTERNAL</b></td>
<td><b>INTERFACE</b></td>
@ -59,34 +75,40 @@
<td>yes</td>
<td>yes</td>
</tr>
</tbody>
</table>
<p>Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above
example) is (are) not included in any specification in /etc/shorewall/masq
or /etc/shorewall/proxyarp.</p>
<p><a name="AllInterFaces"></a>Note 1: The &quot;ALL INTERFACES&quot; column
is used to specify whether access to the external IP from all firewall
<p><a name="AllInterFaces"></a>Note 1: The "ALL INTERFACES" column
is used to specify whether access to the external IP from all firewall
interfaces should undergo NAT (Yes or yes) or if only access from the
interface in the INTERFACE column should undergo NAT. If you leave this
column empty, &quot;Yes&quot; is assumed.&nbsp;The ALL INTERFACES column was
added in version 1.1.6.</p>
column empty, "Yes" is assumed. The ALL INTERFACES column was added
in version 1.1.6.</p>
<p>Note 2: Shorewall will automatically add the external address to the
specified interface unless you specify <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>=&quot;no&quot;
(or &quot;No&quot;) in /etc/shorewall/shorewall.conf; If you do not set
ADD_IP_ALIASES or if you set it to &quot;Yes&quot; or &quot;yes&quot; then you must NOT configure your own alias(es).</p>
<p><a name="LocalPackets"></a>Note 3: The contents of the &quot;LOCAL&quot;
column determine whether packets originating on the firewall itself and
destined for the EXTERNAL address are redirected to the internal ADDRESS. If
this column contains &quot;yes&quot; or &quot;Yes&quot; (and the ALL
INTERFACES COLUMN also contains &quot;Yes&quot; or &quot;yes&quot;) then
such packets are redirected; otherwise, such packets are not redirected. The
LOCAL column was added in version 1.1.8.</p>
</blockquote>
specified interface unless you specify <a
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>="no" (or "No") in
/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if
you set it to "Yes" or "yes" then you must NOT configure your own alias(es).</p>
<blockquote>
</blockquote>
<p><a name="LocalPackets"></a>Note 3: The contents of the "LOCAL" column
determine whether packets originating on the firewall itself and destined
for the EXTERNAL address are redirected to the internal ADDRESS. If this
column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also contains
"Yes" or "yes") then such packets are redirected; otherwise, such packets
are not redirected. The LOCAL column was added in version 1.1.8.</p>
</blockquote>
<p><font size="2">Last updated 3/27/2002 - </font><font size="2">
<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>
<blockquote> </blockquote>
<p><font size="2">Last updated 1/11/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</body>
</html>

1122
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

4
STABLE/documentation/PPTP.htm
View File

@ -891,8 +891,8 @@ yet and reject the initial TCP connection request if I enable ECN :-( </p>
<p><font size="2">Last modified 10/23/2002 - <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 Thomas M. Eastep.</font></a></font></p>
<p><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
<br>
<br>
</body>

190
STABLE/documentation/ProxyARP.htm
View File

@ -1,42 +1,56 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Shorewall Proxy ARP</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Proxy ARP</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Proxy ARP</font></h1>
<h1 align="center"><font color="#ffffff">Proxy ARP</font></h1>
</td>
</tr>
</table>
<p>Proxy ARP allows you to insert a firewall in front of a set of servers
without changing their IP addresses and without having to re-subnet.</p>
<p>The following figure represents a Proxy ARP
environment.</p>
</tbody>
</table>
<p>Proxy ARP allows you to insert a firewall in front of a set of servers
without changing their IP addresses and without having to re-subnet.
Before you try to use this technique, I strongly recommend that you read
the <a href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
<p>The following figure represents a Proxy ARP environment.</p>
<blockquote>
<p align="center"><strong>
<img src="images/proxyarp.png" width="519" height="397"></strong></p>
<blockquote>
<p align="center"><strong> <img src="images/proxyarp.png"
width="519" height="397">
</strong></p>
<blockquote> </blockquote>
</blockquote>
</blockquote>
<p align="left">Proxy ARP can be used to make the systems with addresses
<p align="left">Proxy ARP can be used to make the systems with addresses
130.252.100.18 and 130.252.100.19 appear to be on the upper (130.252.100.*)
subnet.&nbsp; Assuming that the upper firewall interface is eth0 and the
lower interface is eth1, this is accomplished using the following entries in
/etc/shorewall/proxyarp:</p>
subnet.  Assuming that the upper firewall interface is eth0 and the
lower interface is eth1, this is accomplished using the following entries
in /etc/shorewall/proxyarp:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ADDRESS</b></td>
<td><b>INTERFACE</b></td>
@ -55,52 +69,96 @@
<td>eth0</td>
<td>no</td>
</tr>
</table>
</blockquote>
<p>Be sure that the internal systems (130.242.100.18 and 130.252.100.19&nbsp;
</tbody>
</table>
</blockquote>
<p>Be sure that the internal systems (130.242.100.18 and 130.252.100.19 
in the above example) are not included in any specification in
/etc/shorewall/masq or /etc/shorewall/nat.</p>
<p>Note that I've used an RFC1918 IP address for eth1 - that IP address is
/etc/shorewall/masq or /etc/shorewall/nat.</p>
<p>Note that I've used an RFC1918 IP address for eth1 - that IP address is
irrelevant. </p>
<p>The lower systems (130.252.100.18 and 130.252.100.19) should have their
subnet mask and default gateway configured exactly the same way that the
Firewall system's eth0 is configured.</p>
<p>The lower systems (130.252.100.18 and 130.252.100.19) should have their
subnet mask and default gateway configured exactly the same way that
the Firewall system's eth0 is configured.</p>
<div align="left">
<p align="left">A word of warning is in order here. ISPs typically configure
<p align="left">A word of warning is in order here. ISPs typically configure
their routers with a long ARP cache timeout. If you move a system from
parallel to your firewall to behind your firewall with Proxy ARP, it will
probably be HOURS before that system can communicate with the internet. You
can call your ISP and ask them to purge the stale ARP cache entry but many
either can't or won't purge individual entries. You can determine if your
ISP's gateway ARP cache is stale using ping and tcpdump. Suppose that we
suspect that the gateway router has a stale ARP cache entry for 130.252.100.19.
On the firewall, run tcpdump as follows:</div>
<div align="left">
<pre> tcpdump -nei eth0 icmp</pre>
</div>
<div align="left">
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we will
assume is 130.252.100.254):</div>
<div align="left">
<pre> ping 130.252.100.254</pre>
</div>
<div align="left">
<p align="left">We can now observe the tcpdump output:</div>
<div align="left">
<pre> 13:35:12.159321 <u>0:4:e2:20:20:33</u> 0:0:77:95:dd:19 ip 98: 130.252.100.19 &gt; 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 <u>0:c0:a8:50:b2:57</u> ip 98: 130.252.100.254 &gt; 130.252.100.177 : icmp: echo reply</pre>
</div>
<div align="left">
<p align="left">Notice that the source MAC address in the echo request is
different from the destination MAC address in the echo reply!! In this case
0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of the system on the lower left. In other words, the gateway's ARP cache still
associates 130.252.100.19 with the NIC in that system rather than with the firewall's
eth0.</div>
probably be HOURS before that system can communicate with the internet.
There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their ARP
cache (section 4.7). A gratuitous ARP is simply a host requesting the MAC
address for its own IP; in addition to ensuring that the IP address isn't
a duplicate...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware address...,
this packet causes any other host...that has an entry in its cache for the
old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host from
being exposed to the Internet to behind Shorewall using proxy ARP (or static
NAT for that matter). Happily enough, recent versions of Redhat's iputils
package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I <i>&lt;net if&gt; &lt;newly proxied
IP&gt;</i></b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to gratuitous
ARPs, but googling for "arping -U" seems to support the idea that it works
most of the time.<br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.</li>
</ol>
You can determine if your ISP's gateway ARP cache is stale using ping
and tcpdump. Suppose that we suspect that the gateway router has a stale
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
<p><font size="2">Last updated 8/17/2002 - </font><font size="2">
<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>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
</div>
<div align="left">
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
will assume is 130.252.100.254):</p>
</div>
<div align="left">
<pre> <b><font color="#009900">ping 130.252.100.254</font></b></pre>
</div>
<div align="left">
<p align="left">We can now observe the tcpdump output:</p>
</div>
<div align="left">
<pre> 13:35:12.159321 <u>0:4:e2:20:20:33</u> 0:0:77:95:dd:19 ip 98: 130.252.100.19 &gt; 130.252.100.254: icmp: echo request (DF)<br> 13:35:12.207615 0:0:77:95:dd:19 <u>0:c0:a8:50:b2:57</u> ip 98: 130.252.100.254 &gt; 130.252.100.177 : icmp: echo reply</pre>
</div>
<div align="left">
<p align="left">Notice that the source MAC address in the echo request is
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of the system on the lower left. In other words, the
gateway's ARP cache still associates 130.252.100.19 with the NIC in that
system rather than with the firewall's eth0.</p>
</div>
<p><font size="2">Last updated 1/11/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</body>
</html>

12
STABLE/documentation/Shorewall_CA_html.html
View File

@ -29,9 +29,9 @@
I can hardly justify paying $200US+ a year to a Certificate Authority such
as Thawte (A Division of VeriSign) for an X.509 certificate to prove that
I am who I am. I have therefore established my own Certificate Authority (CA)
and sign my own X.509 certificates. I use these certificates on my web server
(<a href="http://www.shorewall.net">http://www.shorewall.net</a>) as well
as on my mail server (mail.shorewall.net).<br>
and sign my own X.509 certificates. I use these certificates on my mail server
(<a href="https://mail.shorewall.net">https://mail.shorewall.net</a>)
which hosts parts of this web site.<br>
<br>
X.509 certificates are the basis for the Secure Socket Layer (SSL). As part
of establishing an SSL session (URL https://...), your browser verifies the
@ -57,7 +57,7 @@ to accept the sleezy X.509 certificate being presented by my server. <br>
There are two things that you can do:<br>
<ol>
<li>You can accept the www.shorewall.net certificate when your browser
<li>You can accept the mail.shorewall.net certificate when your browser
asks -- your acceptence of the certificate can be temporary (for that access
only) or perminent.</li>
<li>You can download and install <a href="ca.crt">my (self-signed) CA
@ -75,14 +75,14 @@ intented to go to your bank's server to one of my systems that will present
your browser with a bogus certificate claiming that my server is that of
your bank.</li>
<li>If you only accept my server's certificate when prompted then the
most that you have to loose is that when you connect to https://www.shorewall.net,
most that you have to loose is that when you connect to https://mail.shorewall.net,
the server you are connecting to might not be mine.</li>
</ol>
I have my CA certificate loaded into all of my browsers but I certainly
won't be offended if you decline to load it into yours... :-)<br>
<p align="left"><font size="2">Last Updated 11/14/2002 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 12/29/2002 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> &copy; <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>

15
STABLE/documentation/Shorewall_CVS_Access.html
View File

@ -27,25 +27,26 @@
<br>
Lots of people try to download the entire Shorewall website for off-line
browsing, including the CVS portion. In addition to being an enormous volume
of data (HTML versions of all versions of all Shorewall files), all of the
pages in Shorewall CVS access are cgi-generated which places a tremendous
of data (HTML versions of all versions of all Shorewall files), all of
the pages in Shorewall CVS access are cgi-generated which places a tremendous
load on my little server. I have therefore resorted to making CVS access
password controlled. When you are asked to log in, enter "Shorewall" (NOTE
THE CAPITALIZATION!!!!!) for both the user name and the password.<br>
password controlled. When you are asked to log in, enter "Shorewall" (NOTE
THE CAPITALIZATION!!!!!) for both the user name and the password.<br>
<br>
<div align="center">
<h3><a href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi"
<h3><a href="http://cvs.shorewall.net/cgi-bin/cvs/cvsweb.cgi"
target="_top">CVS Login</a> &nbsp;<br>
</h3>
</div>
<p><font size="2" face="Century Gothic, Arial, Helvetica">Updated 9/23/2002
<p><font size="2" face="Century Gothic, Arial, Helvetica">Updated 1/14/2002
- <a href="support.htm">Tom Eastep</a> </font>
</p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
&copy; <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
&copy; <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>

408
STABLE/documentation/Shorewall_Squid_Usage.html Normal file
View File

@ -0,0 +1,408 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Shorewall Squid Usage</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table cellpadding="0" cellspacing="0" border="0" width="100%"
bgcolor="#400169">
<tbody>
<tr>
<td valign="middle" width="33%" bgcolor="#400169"><a
href="http://www.squid-cache.org/"><img src="images/squidnow.gif"
alt="" width="88" height="31" hspace="4">
</a><br>
</td>
<td valign="middle" height="90" align="center" width="34%"><font
color="#ffffff"><b><big><big><big><big>Using Shorewall with Squid</big></big></big></big></b></font><br>
</td>
<td valign="middle" height="90" width="33%" align="right"><a
href="http://www.squid-cache.org/"><img src="images/cache_now.gif"
alt="" width="100" height="31" hspace="4">
</a><br>
</td>
</tr>
</tbody>
</table>
<br>
This page covers Shorewall configuration to use with <a
href="http://www.squid-cache.org/">Squid </a>running as a <u><b>Transparent
Proxy</b></u>.&nbsp;<br>
<a href="#DMZ"></a><br>
<img border="0" src="images/j0213519.gif" width="60" height="60"
alt="Caution" align="middle">
&nbsp;&nbsp;&nbsp; Please observe the following general requirements:<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>In all cases, Squid should be configured to run
as a transparent proxy as described at <a
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
<b><br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files /etc/shorewall/start
and /etc/shorewall/init -- if you don't have those files, siimply create
them.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or in
the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
file entries. That is because the packets being routed to the Squid server
still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iproute2 (<i>ip </i>utility) installed
on your firewall.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iptables installed on your Squid
server.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have NAT and MANGLE enabled in your /etc/shorewall/conf
file<br>
<br>
&nbsp;&nbsp;&nbsp; <b><font color="#009900">&nbsp;&nbsp;&nbsp; NAT_ENABLED=Yes<br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
<br>
Three different configurations are covered:<br>
<ol>
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on the
Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in the local
network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the DMZ</a></li>
</ol>
<h2><a name="Firewall"></a>Squid Running on the Firewall</h2>
You want to redirect all local www connection requests EXCEPT
those to your own
http server (206.124.146.177)
to a Squid transparent
proxy running on the firewall and listening on port 3128. Squid
will of course require access to remote web servers.<br>
<br>
In /etc/shorewall/rules:<br>
<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td> -<br>
</td>
<td>!206.124.146.177</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<h2><a name="Local"></a>Squid Running in the local network</h2>
You want to redirect all local www connection requests to a Squid
transparent proxy
running in your local zone at 192.168.1.3 and listening on port 3128.
Your local interface is eth1. There may also be a web server running on
192.168.1.3. It is assumed that web access is already enabled from the local
zone to the internet.<br>
<p><font color="#ff0000"><b>WARNING: </b></font>This setup may conflict with
other aspects of your gateway including but not limited to traffic shaping
and route redirection. For that reason, I don't recommend it.<br>
</p>
<ul>
<li>On your firewall system, issue the following command<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</font></b><br></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/init, put:<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.168.1.3 dev eth1 table www.out<br> ip route flush cache<br> echo 0 &gt; /proc/sys/net/ipv4/conf/eth1/send_redirects<br>fi<br></font></b></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/rules:<br>
<br>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>ACCEPT<br>
</td>
<td>loc</td>
<td>loc<br>
</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>Alternativfely, you can have the following policy:<br>
<br>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DESTINATION<br>
</b></td>
<td valign="top"><b>POLICY<br>
</b></td>
<td valign="top"><b>LOG LEVEL<br>
</b></td>
<td valign="top"><b>BURST PARAMETERS<br>
</b></td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">loc<br>
</td>
<td valign="top">ACCEPT<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>In /etc/shorewall/start add:<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</b></font><br></pre>
</blockquote>
<ul>
<li>On 192.168.1.3, arrange for the following command to be executed
after networking has come up<br>
<pre><b><font color="#009900">iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128</font></b><br></pre>
</li>
</ul>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<blockquote> </blockquote>
<pre><font color="#009900"><b>iptables-save &gt; /etc/sysconfig/iptables</b></font><font
color="#009900"><b><br>chkconfig --level 35 iptables start<br></b></font></pre>
</blockquote>
<blockquote> </blockquote>
<h2><a name="DMZ"></a>Squid Running in the DMZ (This is what I do)</h2>
You have a single Linux system in your DMZ with IP address 192.0.2.177.
You want to run both a web server and Squid on that system. Your DMZ interface
is eth1 and your local interface is eth2.<br>
<ul>
<li>On your firewall system, issue the following command<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</b></font><br></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/init, put:<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.0.2.177 dev eth1 table www.out<br> ip route flush cache<br>fi</b></font><br></pre>
</blockquote>
<ul>
<li>&nbsp;In /etc/shorewall/start add:<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</font></b><br></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/rules, you will need:</li>
</ul>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
<tbody>
<tr>
<td valign="top">ACTION<br>
</td>
<td valign="top">SOURCE<br>
</td>
<td valign="top">DEST<br>
</td>
<td valign="top">PROTO<br>
</td>
<td valign="top">DEST<br>
PORT(S)<br>
</td>
<td valign="top">CLIENT<br>
PORT(2)<br>
</td>
<td valign="top">ORIGINAL<br>
DEST<br>
</td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">dmz<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<ul>
<li>On 192.0.2.177 (your Web/Squid server), arrange for the following
command to be executed after networking has come up<br>
<pre><font color="#009900"><b>iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></font><br></pre>
</li>
</ul>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<blockquote> </blockquote>
<pre><font color="#009900"><b>iptables-save &gt; /etc/sysconfig/iptables</b></font><font
color="#009900"><b><br>chkconfig --level 35 iptables start<br></b></font></pre>
</blockquote>
<blockquote> </blockquote>
<p><font size="-1"> Updated 1/10/2003 - <a
href="file:///home/teastep/Shorewall-docs/support.htm">Tom Eastep</a>
</font></p>
<a
href="copyright.htm"><font size="2">Copyright</font> &copy; <font
size="2">2003 Thomas M. Eastep.</font></a><br>
<br>
<br>
<br>
<br>
</body>
</html>

12
STABLE/documentation/Shorewall_index_frame.htm
View File

@ -37,9 +37,11 @@
<td width="100%" bgcolor="#ffffff">
<ul>
<li> <a href="seattlefirewall_index.htm">Home</a></li>
<li> <a href="shorewall_features.htm">Features</a></li>
<li> <a
href="shorewall_features.htm">Features</a></li>
<li> <a href="shorewall_prerequisites.htm">Requirements</a></li>
<li> <a href="download.htm">Download</a><br>
</li>
@ -64,6 +66,7 @@
<ul>
<li><a target="_top"
href="http://slovakia.shorewall.net">Slovak Republic</a></li>
@ -93,7 +96,8 @@
<ul>
<li> <a href="News.htm">News Archive</a></li>
<li> <a href="Shorewall_CVS_Access.html">CVS Repository</a></li>
<li> <a href="Shorewall_CVS_Access.html">CVS
Repository</a></li>
<li> <a href="quotes.htm">Quotes from Users</a></li>
<li> <a href="shoreline.htm">About the Author</a></li>
<li> <a
@ -123,7 +127,7 @@
type="hidden" name="config" value="htdig"> <input type="submit"
value="Search"></font> </p>
<font face="Arial"> <input type="hidden"
name="exclude" value="[http://www.shorewall.net/pipermail/*]"> </font>
name="exclude" value="[http://mail.shorewall.net/pipermail/*]"> </font>
</form>
<p><b><a href="http://www.shorewall.net/htdig/search.html">Extended Search</a></b></p>
@ -140,5 +144,7 @@
<br>
<br>
<br>
<br>
</body>
</html>

11
STABLE/documentation/Shorewall_sfindex_frame.htm
View File

@ -30,6 +30,7 @@
<td width="100%" height="90">
<h3 align="center"><font color="#ffffff">Shorewall</font></h3>
</td>
</tr>
@ -37,6 +38,7 @@
<td width="100%" bgcolor="#ffffff">
<ul>
<li> <a href="seattlefirewall_index.htm">Home</a></li>
<li> <a
@ -52,7 +54,8 @@
</li>
<li> <b><a
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a></b></li>
<li> <a href="Documentation.htm">Reference Manual</a></li>
<li> <a href="Documentation.htm">Reference
Manual</a></li>
<li> <a href="FAQ.htm">FAQs</a></li>
<li><a href="useful_links.html">Useful Links</a><br>
</li>
@ -96,7 +99,7 @@
<ul>
<li> <a href="News.htm">News Archive</a></li>
<li> <a href="Shorewall_CVS_Access.html">CVS
Repository</a></li>
Repository</a></li>
<li> <a href="quotes.htm">Quotes from Users</a></li>
<li> <a href="shoreline.htm">About the Author</a></li>
<li> <a
@ -126,7 +129,7 @@ Repository</a></li>
type="hidden" name="config" value="htdig"> <input type="submit"
value="Search"></font> </p>
<font face="Arial"> <input type="hidden"
name="exclude" value="[http://www.shorewall.net/pipermail/*]"> </font>
name="exclude" value="[http://mail.shorewall.net/pipermail/*]"> </font>
</form>
<p><b><a href="http://www.shorewall.net/htdig/search.html">Extended Search</a></b></p>
@ -141,5 +144,7 @@ Repository</a></li>
<br>
<br>
<br>
<br>
</body>
</html>

195
STABLE/documentation/configuration_file_basics.htm
View File

@ -34,7 +34,7 @@
href="http://www.megaloman.com/%7Ehany/software/hd2u/"> dos2unix</a>
before you use them with Shorewall.</b></p>
<h2>Files</h2>
<h2><a name="Files"></a>Files</h2>
<p>Shorewall's configuration files are in the directory /etc/shorewall.</p>
@ -44,20 +44,20 @@
<li>/etc/shorewall/params - use this file to set shell
variables that you will expand in other files.</li>
<li>/etc/shorewall/zones - partition the firewall's
view of the world into <i>zones.</i></li>
view of the world into <i>zones.</i></li>
<li>/etc/shorewall/policy - establishes firewall high-level
policy.</li>
<li>/etc/shorewall/interfaces - describes the interfaces
on the firewall system.</li>
<li>/etc/shorewall/hosts - allows defining zones in
terms of individual hosts and subnetworks.</li>
terms of individual hosts and subnetworks.</li>
<li>/etc/shorewall/masq - directs the firewall where
to use many-to-one (dynamic) Network Address Translation (a.k.a.
Masquerading) and Source Network Address Translation (SNAT).</li>
<li>/etc/shorewall/modules - directs the firewall to
load kernel modules.</li>
<li>/etc/shorewall/rules - defines rules that are exceptions
to the overall policies established in /etc/shorewall/policy.</li>
<li>/etc/shorewall/modules - directs the firewall
to load kernel modules.</li>
<li>/etc/shorewall/rules - defines rules that are
exceptions to the overall policies established in /etc/shorewall/policy.</li>
<li>/etc/shorewall/nat - defines static NAT rules.</li>
<li>/etc/shorewall/proxyarp - defines use of Proxy
ARP.</li>
@ -68,22 +68,22 @@ ARP.</li>
<li>/etc/shorewall/tos - defines rules for setting
the TOS field in packet headers.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE and
IPIP tunnels with end-points on the firewall system.</li>
IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC
addresses.</li>
<li>/etc/shorewall/init - commands that you wish to execute at the beginning
of a "shorewall start" or "shorewall restart".</li>
of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/start - commands that you wish to execute at the completion
of a "shorewall start" or "shorewall restart"</li>
of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the beginning
of a "shorewall stop".</li>
of a "shorewall stop".</li>
<li>/etc/shorewall/stopped - commands that you wish to execute at the
completion of a "shorewall stop".<br>
</li>
</ul>
<h2>Comments</h2>
<h2><a name="Comments"></a>Comments</h2>
<p>You may place comments in configuration files by making the first non-whitespace
character a pound sign ("#"). You may also place comments at
@ -96,7 +96,7 @@ of the line with a pound sign.</p>
<pre>ACCEPT net fw tcp www #This is an end-of-line comment</pre>
<h2>Line Continuation</h2>
<h2><a name="Continuation"></a>Line Continuation</h2>
<p>You may continue lines in the configuration files using the usual backslash
("\") followed immediately by a new line character.</p>
@ -124,21 +124,21 @@ of the line with a pound sign.</p>
Names.<br>
<br>
DNS names in iptables rules aren't nearly as useful as they
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those addresses
into the rule. So changes in the DNS-&gt;IP address relationship that
occur after the firewall has started have absolutely no effect on the
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those addresses
into the rule. So changes in the DNS-&gt;IP address relationship that
occur after the firewall has started have absolutely no effect on the
firewall's ruleset. </p>
<p align="left"> If your firewall rules include DNS names then:</p>
<ul>
<li>If your /etc/resolv.conf is wrong then your firewall won't
start.</li>
<li>If your /etc/resolv.conf is wrong then your firewall
won't start.</li>
<li>If your /etc/nsswitch.conf is wrong then your firewall
won't start.</li>
won't start.</li>
<li>If your Name Server(s) is(are) down then your firewall
won't start.</li>
won't start.</li>
<li>If your startup scripts try to start your firewall before
starting your DNS server then your firewall won't start.<br>
</li>
@ -151,9 +151,9 @@ won't start.</li>
</ul>
<p align="left"> Each DNS name much be fully qualified and include a minumum
of two periods (although one may be trailing). This restriction is imposed
by Shorewall to insure backward compatibility with existing configuration
files.<br>
of two periods (although one may be trailing). This restriction is
imposed by Shorewall to insure backward compatibility with existing
configuration files.<br>
<br>
Examples of valid DNS names:<br>
</p>
@ -182,14 +182,14 @@ won't start.</li>
These restrictions are not imposed by Shorewall simply for
your inconvenience but are rather limitations of iptables.<br>
<h2>Complementing an Address or Subnet</h2>
<h2><a name="Compliment"></a>Complementing an Address or Subnet</h2>
<p>Where specifying an IP address, a subnet or an interface, you can
precede the item with "!" to specify the complement of the item. For
example, !192.168.1.4 means "any host but 192.168.1.4". There must be
no white space following the "!".</p>
example, !192.168.1.4 means "any host but 192.168.1.4". There must
be no white space following the "!".</p>
<h2>Comma-separated Lists</h2>
<h2><a name="Lists"></a>Comma-separated Lists</h2>
<p>Comma-separated lists are allowed in a number of contexts within the
configuration files. A comma separated list:</p>
@ -199,29 +199,29 @@ no white space following the "!".</p>
Valid: routestopped,dhcp,norfc1918<br>
Invalid: routestopped,     dhcp,     norfc1818</li>
<li>If you use line continuation to break a comma-separated
list, the continuation line(s) must begin in column 1 (or there
would be embedded white space)</li>
list, the continuation line(s) must begin in column 1 (or
there would be embedded white space)</li>
<li>Entries in a comma-separated list may appear in
any order.</li>
any order.</li>
</ul>
<h2>Port Numbers/Service Names</h2>
<h2><a name="Ports"></a>Port Numbers/Service Names</h2>
<p>Unless otherwise specified, when giving a port number you can use
either an integer or a service name from /etc/services. </p>
<h2>Port Ranges</h2>
<h2><a name="Ranges"></a>Port Ranges</h2>
<p>If you need to specify a range of ports, the proper syntax is &lt;<i>low
port number</i>&gt;:&lt;<i>high port number</i>&gt;. For example,
if you want to forward the range of tcp ports 4000 through 4100 to local
host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
if you want to forward the range of tcp ports 4000 through 4100 to
local host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
</p>
<pre> DNAT net loc:192.168.1.3 tcp 4000:4100<br></pre>
<h2>Using Shell Variables</h2>
<h2><a name="Variables"></a>Using Shell Variables</h2>
<p>You may use the /etc/shorewall/params file to set shell variables
that you can then use in some of the other configuration files.</p>
@ -261,7 +261,7 @@ any order.</li>
<p>Variables may be used anywhere in the other configuration
files.</p>
<h2>Using MAC Addresses</h2>
<h2><a name="MAC"></a>Using MAC Addresses</h2>
<p>Media Access Control (MAC) addresses can be used to specify packet
source in several of the configuration files. To use this feature,
@ -290,129 +290,33 @@ series of 6 hex numbers separated by colons. Example:<br>
<br>
Because Shorewall uses colons as a separator for address
fields, Shorewall requires MAC addresses to be written in another
way. In Shorewall, MAC addresses begin with a tilde ("~") and
consist of 6 hex numbers separated by hyphens. In Shorewall, the
MAC address in the example above would be written "~02-00-08-E3-FA-55".<br>
way. In Shorewall, MAC addresses begin with a tilde ("~") and consist
of 6 hex numbers separated by hyphens. In Shorewall, the MAC address
in the example above would be written "~02-00-08-E3-FA-55".<br>
</p>
<p><b>Note: </b>It is not necessary to use the special Shorewall notation
in the <a href="MAC_Validation.html">/etc/shorewall/maclist</a> file.<br>
</p>
<h2><a name="Levels"></a>Logging</h2>
By default, Shorewall directs NetFilter to log using syslog (8). Syslog
classifies log messages by a <i>facility</i> and a <i>priority</i> (using
the notation <i>facility.priority</i>). <br>
<br>
The facilities defined by syslog are <i>auth, authpriv, cron, daemon,
kern, lpr, mail, mark, news, syslog, user, uucp</i> and <i>local0</i> through
<i>local7</i>.<br>
<br>
Throughout the Shorewall documentation, I will use the term <i>level</i>
rather than <i>priority</i> since <i>level</i> is the term used by NetFilter.
The syslog documentation uses the term <i>priority</i>.<br>
<h3>Syslog Levels<br>
</h3>
Syslog levels are a method of describing to syslog (8) the importance
of a message and a number of Shorewall parameters have a syslog level
as their value.<br>
<br>
Valid levels are:<br>
<br>
       7       debug<br>
       6       info<br>
       5       notice<br>
       4       warning<br>
       3       err<br>
       2       crit<br>
       1       alert<br>
       0       emerg<br>
<br>
For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall
log messages are generated by NetFilter and are logged using the <i>kern</i>
facility and the level that you specify. If you are unsure of the level
to choose, 6 (info) is a safe bet. You may specify levels by name or by
number.<br>
<br>
Syslogd writes log messages to files (typically in /var/log/*) based
on their facility and level. The mapping of these facility/level pairs to
log files is done in /etc/syslog.conf (5). If you make changes to this file,
you must restart syslogd before the changes can take effect.<br>
<h3>Configuring a Separate Log for Shorewall Messages</h3>
There are a couple of limitations to syslogd-based logging:<br>
<ol>
<li>If you give, for example, kern.info it's own log destination then
that destination will also receive all kernel messages of levels 5 (notice)
through 0 (emerg).</li>
<li>All kernel.info messages will go to that destination and not just
those from NetFilter.<br>
</li>
</ol>
Beginning with Shorewall version 1.3.12, if your kernel has ULOG target
support (and most vendor-supplied kernels do), you may also specify a log
level of ULOG (must be all caps). When ULOG is used, Shorewall will direct
netfilter to log the related messages via the ULOG target which will send
them to a process called 'ulogd'. The ulogd program is available from http://www.gnumonks.org/projects/ulogd
and can be configured to log all Shorewall message to their own log file.<br>
<br>
Download the ulod tar file and:<br>
<ol>
<li>cd /usr/local/src (or wherever you do your builds)</li>
<li>tar -zxf <i>source-tarball-that-you-downloaded</i></li>
<li>cd ulogd-<i>version</i><br>
</li>
<li>./configure</li>
<li>make</li>
<li>make install<br>
</li>
</ol>
If you are like me and don't have a development environment on your firewall,
you can do the first five steps on another system then either NFS mount your
/usr/local/src directory or tar up the /usr/local/src/ulogd-<i>version</i>
directory and move it to your firewall system.<br>
<br>
Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:<br>
<ol>
<li>syslogfile <i>&lt;file that you wish to log to&gt;</i></li>
<li>syslogsync 1</li>
</ol>
I also copied the file /usr/local/src/ulogd-<i>version</i>/ulogd.init to
/etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd"
to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple "chkconfig
--level 3 ulogd on" starts ulogd during boot up. Your init system may need
something else done to activate the script.<br>
<br>
Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<i>&lt;file that
you wish to log to&gt;</i>. This tells the /sbin/shorewall program where to
look for the log when processing its "show log", "logwatch" and "monitor"
commands.<br>
<h2><a name="Configs"></a>Shorewall Configurations</h2>
<h2><a name="Levels"></a>Shorewall Configurations</h2>
<p> Shorewall allows you to have configuration directories other than /etc/shorewall.
The <a href="starting_and_stopping_shorewall.htm">shorewall start and
restart</a> commands allow you to specify an alternate configuration
The <a href="starting_and_stopping_shorewall.htm">shorewall start
and restart</a> commands allow you to specify an alternate configuration
directory and Shorewall will use the files in the alternate directory
rather than the corresponding files in /etc/shorewall. The alternate directory
need not contain a complete configuration; those files not in the alternate
directory will be read from /etc/shorewall.</p>
rather than the corresponding files in /etc/shorewall. The alternate
directory need not contain a complete configuration; those files not
in the alternate directory will be read from /etc/shorewall.</p>
<p> This facility permits you to easily create a test or temporary configuration
by:</p>
<ol>
<li> copying the files that need modification from
/etc/shorewall to a separate directory;</li>
/etc/shorewall to a separate directory;</li>
<li> modify those files in the separate directory;
and</li>
and</li>
<li> specifying the separate directory in a shorewall
start or shorewall restart command (e.g., <i><b>shorewall -c /etc/testconfig
restart</b></i> ).</li>
@ -422,7 +326,7 @@ and</li>
<p><font size="2"> Updated 12/20/2002 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 12/29/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -432,5 +336,6 @@ and</li>
</p>
<br>
<br>
<br>
</body>
</html>

55
STABLE/documentation/copyright.htm
View File

@ -1,34 +1,45 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Copyright</title>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Copyright</title>
</head>
<body>
<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">Copyright</font></h1>
<h1 align="center"><font color="#ffffff">Copyright</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="left">Copyright <font face="Trebuchet MS">©</font>&nbsp; 2000, 2001
Thomas M Eastep<br>
&nbsp;</p>
<p align="left">Copyright <font face="Trebuchet MS">©</font>  2000, 2001,
2003 Thomas M Eastep<br>
 </p>
<blockquote>
<p align="left">Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the
license is included in the section entitled &quot;<a href="GnuCopyright.htm">GNU Free Documentation License</a>&quot;.<br>
&nbsp;</p>
</blockquote>
<p align="left">Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License, Version
1.1 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts.
A copy of the license is included in the section entitled "<a
href="GnuCopyright.htm">GNU Free Documentation License</a>".<br>
 </p>
</blockquote>
<br>
</body>
</html>

80
STABLE/documentation/download.htm
View File

@ -28,43 +28,46 @@
</tbody>
</table>
<p><b>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.<br>
</b></p>
<p>The entire set of Shorewall documentation is available in PDF format at:</p>
<p>The entire set of Shorewall documentation is available in PDF format
at:</p>
<p>    <a href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
    <a href="rsync://slovakia.shorewall.net/shorewall/pdf/">rsync://slovakia.shorewall.net/shorewall/pdf/</a>
</p>
<p>The documentation in HTML format is included in the .rpm and in the .tgz
packages below.</p>
<p>The documentation in HTML format is included in the .rpm and in the
.tgz packages below.</p>
<p> Once you've done that, download <u> one</u> of the modules:</p>
<ul>
<li>If you run a <b>RedHat</b>, <b>SuSE, Mandrake</b>, <b>
Linux PPC</b> or <b> TurboLinux</b> distribution with
a 2.4 kernel, you can use the RPM version (note: the RPM
should also work with other distributions that store init
scripts in /etc/init.d and that include chkconfig or insserv).
If you find that it works in other cases, let <a
a 2.4 kernel, you can use the RPM version (note: the
RPM should also work with other distributions that store
init scripts in /etc/init.d and that include chkconfig or
insserv). If you find that it works in other cases, let <a
href="mailto:teastep@shorewall.net"> me</a> know so that
I can mention them here. See the <a href="Install.htm">Installation Instructions</a>
if you have problems installing the RPM.</li>
<li>If you are running LRP, download the .lrp file (you might
also want to download the .tgz so you will have a copy of the documentation).</li>
I can mention them here. See the <a href="Install.htm">Installation
Instructions</a> if you have problems installing the RPM.</li>
<li>If you are running LRP, download the .lrp file (you
might also want to download the .tgz so you will have a copy of
the documentation).</li>
<li>If you run <a href="http://www.debian.org"><b>Debian</b></a>
and would like a .deb package, Shorewall is included in both the
<a href="http://packages.debian.org/testing/net/shorewall.html">Debian
Testing Branch</a> and the <a
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
Unstable Branch</a>.</li>
Unstable Branch</a>.</li>
<li>Otherwise, download the <i>shorewall</i>
module (.tgz)</li>
module (.tgz)</li>
</ul>
@ -72,32 +75,32 @@ module (.tgz)</li>
and there is an documentation .deb that also contains the documentation.</p>
<p>Please verify the version that you have downloaded -- during the
release of a new version of Shorewall, the links below may point
to a newer or an older version than is shown below.</p>
release of a new version of Shorewall, the links below may
point to a newer or an older version than is shown below.</p>
<ul>
<li>RPM - "rpm -qip LATEST.rpm"</li>
<li>TARBALL - "tar -ztf LATEST.tgz" (the directory name
will contain the version)</li>
<li>LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar
-zxf &lt;downloaded .lrp&gt;; cat var/lib/lrpkg/shorwall.version" </li>
-zxf &lt;downloaded .lrp&gt;; cat var/lib/lrpkg/shorwall.version"
</li>
</ul>
<p><font face="Arial">Once you have verified the version, check the
</font><font color="#ff0000" face="Arial"> <a href="errata.htm"> errata</a></font><font
face="Arial"> to see if there are updates that apply to the version
that you have downloaded.</font></p>
<p>Once you have verified the version, check the <font
color="#ff0000"> <a href="errata.htm"> errata</a></font> to see
if there are updates that apply to the version that you have
downloaded.</p>
<p><font color="#ff0000" face="Arial"><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. Once you have completed
configuration of your firewall, you can enable startup by removing the
file /etc/shorewall/startup_disabled.</b></font></p>
<p><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. Once you have completed configuration
of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.</b></font></p>
<p><b>Download Latest Version</b> (<b>1.3.12</b>): <b>Remember that updates
to the mirrors occur 1-12 hours after an update to the Washington
State site.</b></p>
<p><b>Download Latest Version</b> (<b>1.3.13</b>): <b>Remember that updates
to the mirrors occur 1-12 hours after an update to the Washington State
site.</b></p>
<blockquote>
<table border="2" cellspacing="3" cellpadding="3"
@ -236,9 +239,11 @@ State site.</b></p>
<td><a
href="http://france.shorewall.net/pub/LATEST.rpm">Download .rpm</a><br>
<a
href="http://france.shorewall.net/pub/LATEST.tgz">Download .tgz</a> <br>
href="http://france.shorewall.net/pub/LATEST.tgz">Download
.tgz</a> <br>
<a
href="http://france.shorewall.net/pub/LATEST.lrp">Download .lrp</a><br>
href="http://france.shorewall.net/pub/LATEST.lrp">Download
.lrp</a><br>
<a
href="http://france.shorewall.net/pub/LATEST.md5sums">Download
.md5sums</a></td>
@ -356,8 +361,8 @@ State site.</b></p>
<td>Shorewall.net</td>
<td><a
href="http://www.shorewall.net/pub/shorewall/">Browse</a></td>
<td><a href="ftp://ftp.shorewall.net/pub/shorewall/"
target="_blank">Browse</a></td>
<td><a
href="ftp://ftp.shorewall.net/pub/shorewall/" target="_blank">Browse</a></td>
</tr>
@ -371,17 +376,18 @@ State site.</b></p>
<p align="left">The <a target="_top"
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS repository at
cvs.shorewall.net</a> contains the latest snapshots of the each Shorewall
component. There's no guarantee that what you find there will work at
all.<br>
component. There's no guarantee that what you find there will work
at all.<br>
</p>
</blockquote>
<p align="left"><font size="2">Last Updated 12/12/2002 - <a
<p align="left"><font size="2">Last Updated 1/13/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

161
STABLE/documentation/errata.htm
View File

@ -49,21 +49,23 @@ untar the archive, replace the 'firewall' script in the untarred director
</li>
<li>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to
overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD
/etc/shorewall/firewall or /var/lib/shorewall/firewall before
you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall
are symbolic links that point to the 'shorewall' file used by your
system initialization scripts to start Shorewall during boot.
It is that file that must be overwritten with the corrected
script.</b></p>
<p align="left"> <b>If you are running a Shorewall version earlier
than 1.3.11, when the instructions say to install a corrected firewall
script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite
the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall
or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall
and /var/lib/shorewall/firewall are symbolic links that point
to the 'shorewall' file used by your system initialization scripts
to start Shorewall during boot. It is that file that must be overwritten
with the corrected script. Beginning with Shorewall 1.3.11, you
may rename the existing file before copying in the new file.</b></p>
</li>
<li>
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For
example, do NOT install the 1.3.9a firewall script if you are running 1.3.7c.</font></b><br>
example, do NOT install the 1.3.9a firewall script if you are running
1.3.7c.</font></b><br>
</p>
</li>
@ -75,14 +77,15 @@ script.</b></p>
in Version 1.3</a></b></li>
<li> <b><a
href="errata_2.htm">Problems in Version 1.2</a></b></li>
<li> <b><font color="#660066">
<a href="errata_1.htm">Problems in Version 1.1</a></font></b></li>
<li> <b><font color="#660066"><a
href="#iptables"> Problem with iptables version 1.2.3 on RH7.2</a></font></b></li>
<li> <b><font
color="#660066"> <a href="errata_1.htm">Problems in Version 1.1</a></font></b></li>
<li> <b><font
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a href="#Debug">Problems
with kernels &gt;= 2.4.18 and RedHat iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading RPM
on SuSE</a></b></li>
on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables version
1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10 and NAT</a></b><br>
@ -93,33 +96,56 @@ on SuSE</a></b></li>
<hr>
<h2 align="left"><a name="V1.3"></a>Problems in Version 1.3</h2>
<h3>Version 1.3.12</h3>
<ul>
<li>If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is the
same as if RFC_1918_LOG_LEVEL=info had been specified. The problem is corrected
by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.12/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.<br>
</li>
</ul>
<h3>Version 1.3.12 LRP</h3>
<ul>
<li>The .lrp was missing the /etc/shorewall/routestopped file -- a new
lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.<br>
</li>
</ul>
<h3>Version 1.3.11a</h3>
<ul>
<li><a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/rfc1918">This
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of 82.0.0.0/8.<br>
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of 82.0.0.0/8.<br>
</li>
</ul>
<h3>Version 1.3.11</h3>
<ul>
<li>When installing/upgrading using the .rpm, you may receive the following
warnings:<br>
<li>When installing/upgrading using the .rpm, you may receive the
following warnings:<br>
<br>
     user teastep does not exist - using root<br>
     group teastep does not exist - using root<br>
<br>
These warnings are harmless and may be ignored. Users downloading the
.rpm from shorewall.net or mirrors should no longer see these warnings as
the .rpm you will get from there has been corrected.</li>
.rpm from shorewall.net or mirrors should no longer see these warnings
as the .rpm you will get from there has been corrected.</li>
<li>DNAT rules that exclude a source subzone (SOURCE column contains
! followed by a sub-zone list) result in an error message and Shorewall
! followed by a sub-zone list) result in an error message and Shorewall
fails to start.<br>
<br>
Install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/firewall">this
corrected script</a> in /usr/lib/shorewall/firewall to correct this problem.
Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
<br>
This problem is corrected in version 1.3.11a.<br>
</li>
@ -130,7 +156,7 @@ Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
<ul>
<li>If you experience problems connecting to a PPTP server running
on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels,
on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels,
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">this
version of the firewall script</a> may help. Please report any cases where
@ -177,8 +203,8 @@ incorrectly when updating old configurations that had the file /etc/shorewall/f
</ul>
<h3>Version 1.3.9</h3>
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated firewall script
at <a
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated firewall
script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
-- copy that file to /usr/lib/shorewall/firewall as described above.<br>
@ -188,7 +214,7 @@ incorrectly when updating old configurations that had the file /etc/shorewall/f
<li> Use of shell variables in the LOG LEVEL or SYNPARMS columns
of the policy file doesn't work.</li>
<li>A DNAT rule with the same original and new IP addresses
but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24
but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24
tcp 25 - 10.1.1.1")<br>
</li>
@ -230,22 +256,24 @@ but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:
<ol>
<li>If the firewall is running
a DHCP server, the client won't be able
to obtain an IP address lease from
a DHCP server, the client won't be
able to obtain an IP address lease from
that server.</li>
<li>With this order of checking,
the "dhcp" option cannot be used as
a noise-reduction measure where there
are both dynamic and static clients on
a LAN segment.</li>
a noise-reduction measure where there
are both dynamic and static clients
on a LAN segment.</li>
</ol>
<p> <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
This version of the 1.3.7a firewall script </a>
corrects the problem. It must be installed
in /var/lib/shorewall as described above.</p>
in /var/lib/shorewall as described
above.</p>
<h3>Version 1.3.7</h3>
@ -269,7 +297,7 @@ a LAN segment.</li>
<p align="left">If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf,
an error occurs when the firewall script attempts to add
an SNAT alias. </p>
an SNAT alias. </p>
</li>
<li>
@ -350,10 +378,10 @@ so it's a good idea to run that command after you have made configura
<p align="left">If you have upgraded from Shorewall 1.2 and after
"Activating rules..." you see the message: "iptables: No chains/target/match
by that name" then you probably have an entry in /etc/shorewall/hosts
that specifies an interface that you didn't include in /etc/shorewall/interfaces.
To correct this problem, you must add an entry to /etc/shorewall/interfaces.
Shorewall 1.3.3 and later versions produce a clearer error
message in this case.</p>
that specifies an interface that you didn't include in
/etc/shorewall/interfaces. To correct this problem, you
must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 and
later versions produce a clearer error message in this case.</p>
<h3 align="left">Version 1.3.2</h3>
@ -365,9 +393,9 @@ version has a size of 38126 bytes.</p>
<ul>
<li>The code to detect a duplicate interface entry
in /etc/shorewall/interfaces contained a typo that prevented
it from working correctly. </li>
it from working correctly. </li>
<li>"NAT_BEFORE_RULES=No" was broken; it behaved
just like "NAT_BEFORE_RULES=Yes".</li>
just like "NAT_BEFORE_RULES=Yes".</li>
</ul>
@ -392,26 +420,26 @@ just like "NAT_BEFORE_RULES=Yes".</li>
<ul>
<li>TCP SYN packets may be double counted when
LIMIT:BURST is included in a CONTINUE or ACCEPT policy (i.e.,
each packet is sent through the limit chain twice).</li>
<li>An unnecessary jump to the policy chain is sometimes
generated for a CONTINUE policy.</li>
<li>When an option is given for more than one interface
in /etc/shorewall/interfaces then depending on the option,
Shorewall may ignore all but the first appearence of the
option. For example:<br>
each packet is sent through the limit chain twice).</li>
<li>An unnecessary jump to the policy chain is
sometimes generated for a CONTINUE policy.</li>
<li>When an option is given for more than one
interface in /etc/shorewall/interfaces then depending
on the option, Shorewall may ignore all but the first
appearence of the option. For example:<br>
<br>
net    eth0    dhcp<br>
loc    eth1    dhcp<br>
<br>
Shorewall will ignore the 'dhcp' on eth1.</li>
<li>Update 17 June 2002 - The bug described in the
prior bullet affects the following options: dhcp, dropunclean,
<li>Update 17 June 2002 - The bug described in
the prior bullet affects the following options: dhcp, dropunclean,
logunclean, norfc1918, routefilter, multi, filterping and
noping. An additional bug has been found that affects only
the 'routestopped' option.<br>
<br>
Users who downloaded the corrected script prior
to 1850 GMT today should download and install the corrected
to 1850 GMT today should download and install the corrected
script again to ensure that this second problem is corrected.</li>
</ul>
@ -424,10 +452,11 @@ to 1850 GMT today should download and install the corrected
<h3 align="left">Version 1.3.0</h3>
<ul>
<li>Folks who downloaded 1.3.0 from the links on
the download page before 23:40 GMT, 29 May 2002 may have
downloaded 1.2.13 rather than 1.3.0. The "shorewall version"
command will tell you which version that you have installed.</li>
<li>Folks who downloaded 1.3.0 from the links
on the download page before 23:40 GMT, 29 May 2002 may
have downloaded 1.2.13 rather than 1.3.0. The "shorewall
version" command will tell you which version that you
have installed.</li>
<li>The documentation NAT.htm file uses non-existent
wallpaper and bullet graphic files. The <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.0/NAT.htm">
@ -446,10 +475,12 @@ command will tell you which version that you have installed.</
iptables version 1.2.3</font></h3>
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably, RedHat
released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
corrected 1.2.3 rpm which you can download here</a>  and I have also
@ -465,6 +496,7 @@ iptables-1.2.4 rpm which you can download here</a>. If you are currently
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>
<p align="left">If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</a>
@ -473,6 +505,7 @@ iptables-1.2.4 rpm which you can download here</a>. If you are currently
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</a>
corrects a problem in handling the  TOS target.</p>
<p align="left">To install one of the above patches:</p>
<ul>
@ -540,27 +573,29 @@ iptables-1.2.4 rpm which you can download here</a>. If you are currently
<h3><a name="NAT"></a>Problems with RH Kernel 2.4.18-10 and NAT<br>
</h3>
/etc/shorewall/nat entries of the following form will result in Shorewall
being unable to start:<br>
/etc/shorewall/nat entries of the following form will result in
Shorewall being unable to start:<br>
<br>
<pre>#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL<br>192.0.2.22    eth0    192.168.9.22   yes     yes<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
Error message is:<br>
<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>
The solution is to put "no" in the LOCAL column. Kernel support
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled it.
The 2.4.19 kernel contains corrected support under a new kernel configuraiton
option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 12/3/2002 -
<p><font size="2"> Last updated 1/3/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 Thomas M. Eastep.</font></a></font><br>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

4
STABLE/documentation/errata_1.htm
View File

@ -207,8 +207,8 @@ ignored<br>
<a href="support.htm">Tom Eastep</a></font>
</p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm">
<font size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
<p align="left"><a href="copyright.htm">
<font size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
</body>

4
STABLE/documentation/fallback.htm
View File

@ -70,5 +70,5 @@ type &quot;rpm -e shorewall&quot;.</p>
<p><font size="2">Last updated 3/26/2001 - </font><font size="2">
<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>
<a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></body></html>

21
STABLE/documentation/gnu_mailman.htm
View File

@ -21,7 +21,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">GNU Mailman/Postfix the Easy
Way</font></h1>
Way</font></h1>
</td>
</tr>
@ -39,17 +39,17 @@ Way</font></h1>
aliases file so that rest of mailman's mail handling processes will run
with proper uid/gid. Postfix has an ability to run a command specified in
an alias as owner of that alias, thus mailman's wrapper is not needed here.
The best method to invoke mailman's mail handling via aliases is to use
The best method to invoke mailman's mail handling via aliases is to use
separate alias file especially for mailman, and made it owned by mailman
and group mailman. Like:<br>
<br>
alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases<br>
<br>
Make sure that /var/mailman/aliases.db is owned by mailman user (this may
be done by executing postalias as mailman userid).<br>
Make sure that /var/mailman/aliases.db is owned by mailman user (this
may be done by executing postalias as mailman userid).<br>
<br>
Next, instead of using mailman-suggested aliases entries with wrapper, use
the following:<br>
Next, instead of using mailman-suggested aliases entries with wrapper,
use the following:<br>
<br>
instead of<br>
mailinglist: /var/mailman/mail/wrapper post mailinglist<br>
@ -63,14 +63,17 @@ the following:<br>
mailinglist-request: /var/mailman/scripts/mailcmd mailinglist<br>
...</p>
<h4>The Shorewall mailing lists are currently running Postfix 1.1.11 together
with the stock RedHat Mailman-2.0.13 RPM configured as shown above.</h4>
<h4>The above tip works with Mailman 2.0; Mailman 2.1 has adopted something
very similar so that no workaround is necessary. See the README.POSTFIX file
included with Mailman-2.1. </h4>
<p align="left"><font size="2">Last updated 9/14/2002 - <a
<p align="left"><font size="2">Last updated 12/29/2002 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
</body>
</html>

BIN
STABLE/documentation/images/cache_now.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 493 B

BIN
STABLE/documentation/images/squidnow.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.7 KiB

4
STABLE/documentation/kernel.htm
View File

@ -142,5 +142,5 @@ the options selected above built as modules:</p>
<p><font size="2">Last updated 3/10/2002 - </font><font size="2">
<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>
<a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></body></html>

194
STABLE/documentation/mailing_list.htm
View File

@ -12,6 +12,7 @@
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall Mailing Lists</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
@ -21,38 +22,45 @@
border="0">
<tbody>
<tr>
<td width="100%">
<td width="33%" valign="middle">
<h1 align="center"><a
href="http://www.centralcommand.com/linux_products.html"><img
src="images/Vexira_Antivirus_Logo.gif" alt="Vexira Logo" width="78"
height="79" align="left">
</a><a href="http://www.gnu.org/software/mailman/mailman.html">
<img border="0" src="images/logo-sm.jpg" align="left" hspace="5"
width="110" height="35">
</a><a href="http://www.postfix.org/"> <img
</a></h1>
<h1 align="center"><a
href="http://www.gnu.org/software/mailman/mailman.html"> <img
border="0" src="images/logo-sm.jpg" align="left" hspace="5" width="110"
height="35" alt="">
</a></h1>
<p align="right"><br>
<font color="#ffffff"><b>   </b></font> </p>
</td>
<td valign="middle" width="34%" align="center">
<h1 align="center"><font color="#ffffff">Shorewall Mailing Lists</font></h1>
</td>
<td valign="middle" width="33%">
<h1 align="center"><a href="http://www.postfix.org/"> <img
src="images/small-picture.gif" align="right" border="0" width="115"
height="45">
</a><font color="#ffffff">Shorewall Mailing Lists<a
href="http://www.inter7.com/courierimap/"><img
src="images/courier-imap.png" alt="Courier-Imap" width="100"
height="38" align="right">
</a></font></h1>
height="45" alt="(Postfix Logo)">
</a></h1>
<br>
<p align="right"><font color="#ffffff"><b><br>
</b></font></p>
<p align="right"><font color="#ffffff"><b><br>
Powered by Postfix     </b></font> </p>
<div align="right"><br>
<b><font color="#ffffff">Powered by Postfix    </font></b><br>
</div>
</td>
</tr>
</tbody>
</table>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.</p>
<h2 align="left">Not getting List Mail? -- <a
href="mailing_list_problems.htm">Check Here</a></h2>
@ -64,9 +72,8 @@
<p align="left">You can report such problems by sending mail to tom dot eastep
at hp dot com.</p>
<h2>A Word about SPAM Filters <a href="http://ordb.org"> <img border="0"
src="images/but3.png" hspace="3" width="88" height="31">
 </a><a href="http://osirusoft.com/"> </a></h2>
<h2>A Word about SPAM Filters <a href="http://ordb.org"></a><a
href="http://osirusoft.com/"> </a></h2>
<p>Before subscribing please read my <a href="spam_filters.htm">policy
about list traffic that bounces.</a> Also please note that the mail server
@ -74,38 +81,45 @@
</p>
<ol>
<li>against the open relay databases at <a
href="http://ordb.org">ordb.org.</a></li>
<li>against <a href="http://spamassassin.org">Spamassassin</a>
(including <a href="http://razor.sourceforge.net/">Vipul's Razor</a>).<br>
</li>
<li>to ensure that the sender address is fully qualified.</li>
<li>to verify that the sender's domain has an A or MX record in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command is a valid
fully-qualified DNS name.</li>
<li>to verify that the sender's domain has an A or MX record
in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command is
a valid fully-qualified DNS name that resolves.</li>
</ol>
<h2>Please post in plain text</h2>
While the list server here at shorewall.net accepts and distributes HTML
posts, a growing number of MTAs serving list subscribers are rejecting this
HTML list traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse"!!<br>
<br>
I think that blocking all HTML is a rather draconian way to control spam
and that the unltimate loser here is not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. Nevertheless, all of you
can help by restricting your list posts to plain text.<br>
<br>
And as a bonus, subscribers who use email clients like pine and mutt will
be able to read your plain text posts whereas they are most likely simply
ignoring your HTML posts.<br>
<br>
A final bonus for the use of HTML is that it cuts down the size of messages
by a large percentage -- that is important when the same message must be
sent 500 times over the slow DSL line connecting the list server to the internet.<br>
<h2></h2>
<h2>Please post in plain text</h2>
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>(explitive 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. This means that HTML-only posts will be bounced by the list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<h2>Other Mail Delivery Problems</h2>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> headers contain the names
of certain ISPs. Again, I believe that such policies hurt more than they
help but I'm not prepared to go so far as to start stripping <i>Received:</i>
headers to circumvent those policies.<br>
<h2 align="left">Mailing Lists Archive Search</h2>
<form method="post" action="http://www.shorewall.net/cgi-bin/htsearch">
<form method="post" action="http://mail.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<select name="method">
@ -127,65 +141,66 @@ sent 500 times over the slow DSL line connecting the list server to the internet
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font> <input type="hidden" name="config" value="htdig"> <input
type="hidden" name="restrict"
value="[http://www.shorewall.net/pipermail/.*]"> <input type="hidden"
</font> <input type="hidden" name="config" value="htdig">
<input type="hidden" name="restrict"
value="[http://mail.shorewall.net/pipermail/.*]"> <input type="hidden"
name="exclude" value=""> <br>
Search: <input type="text" size="30" name="words" value=""> <input
type="submit" value="Search"> </p>
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"> </p>
</form>
<h2 align="left"><font color="#ff0000">Please do not try to download the entire
Archive -- its 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you'll be blacklisted.<br>
<h2 align="left"><font color="#ff0000">Please do not try to download the
entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply
won't stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left">Shorewall CA Certificate</h2>
If you want to trust X.509 certificates issued by Shoreline Firewall
(such as the one used on my web site), you may <a
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
in your browser. If you don't wish to trust my certificates then you
can either use unencrypted access when subscribing to Shorewall mailing
lists or you can use secure access (SSL) and accept the server's certificate
when prompted by your browser.<br>
can either use unencrypted access when subscribing to Shorewall mailing
lists or you can use secure access (SSL) and accept the server's certificate
when prompted by your browser.<br>
<h2 align="left">Shorewall Users Mailing List</h2>
<p align="left">The Shorewall Users Mailing list provides a way for users
to get answers to questions and to report problems. Information of general
interest to the Shorewall user community is also posted to this list.</p>
to get answers to questions and to report problems. Information of
general interest to the Shorewall user community is also posted to this
list.</p>
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="support.htm">problem reporting guidelines</a>.</b></p>
<p align="left">To subscribe to the mailing list, go to <a
href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>
href="http://mail.shorewall.net/mailman/listinfo/shorewall-users">http://mail.shorewall.net/mailman/listinfo/shorewall-users</a>
SSL: <a
href="https://www.shorewall.net/mailman/listinfo/shorewall-users"
target="_top">https//www.shorewall.net/mailman/listinfo/shorewall-users</a></p>
href="https://mail.shorewall.net/mailman/listinfo/shorewall-users"
target="_top">https//mail.shorewall.net/mailman/listinfo/shorewall-users</a></p>
<p align="left">To post to the list, post to <a
href="mailto:shorewall-users@shorewall.net">shorewall-users@shorewall.net</a>.</p>
<p align="left">The list archives are at <a
href="http://www.shorewall.net/pipermail/shorewall-users/index.html">http://www.shorewall.net/pipermail/shorewall-users</a>.</p>
href="http://mail.shorewall.net/pipermail/shorewall-users/index.html">http://mail.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
<p align="left">This list is for announcements of general interest to the
Shorewall community. To subscribe, go to <a
href="http://www.shorewall.net/mailman/listinfo/shorewall-announce">http://www.shorewall.net/mailman/listinfo/shorewall-announce</a>
href="http://mail.shorewall.net/mailman/listinfo/shorewall-announce">http://mail.shorewall.net/mailman/listinfo/shorewall-announce</a>
SSL: <a
href="https://www.shorewall.net/mailman/listinfo/shorewall-announce"
target="_top">https//www.shorewall.net/mailman/listinfo/shorewall-announce.<br>
href="https://mail.shorewall.net/mailman/listinfo/shorewall-announce"
target="_top">https//mail.shorewall.net/mailman/listinfo/shorewall-announce.<br>
</a><br>
The list archives are at <a
href="http://www.shorewall.net/pipermail/shorewall-announce">http://www.shorewall.net/pipermail/shorewall-announce</a>.</p>
href="http://mail.shorewall.net/pipermail/shorewall-announce">http://mail.shorewall.net/pipermail/shorewall-announce</a>.</p>
<h2 align="left">Shorewall Development Mailing List</h2>
@ -194,35 +209,39 @@ list may be found at <a
ongoing Shorewall Development.</p>
<p align="left">To subscribe to the mailing list, go to <a
href="http://www.shorewall.net/mailman/listinfo/shorewall-devel">http://www.shorewall.net/mailman/listinfo/shorewall-devel</a>
href="http://mail.shorewall.net/mailman/listinfo/shorewall-devel">http://mail.shorewall.net/mailman/listinfo/shorewall-devel</a>
SSL: <a
href="https://www.shorewall.net/mailman/listinfo/shorewall-devel"
target="_top">https//www.shorewall.net/mailman/listinfo/shorewall-devel.</a><br>
href="https://mail.shorewall.net/mailman/listinfo/shorewall-devel"
target="_top">https//mail.shorewall.net/mailman/listinfo/shorewall-devel.</a><br>
To post to the list, post to <a
href="mailto:shorewall-devel@shorewall.net">shorewall-devel@shorewall.net</a>. </p>
<p align="left">The list archives are at <a
href="http://www.shorewall.net/pipermail/shorewall-devel">http://www.shorewall.net/pipermail/shorewall-devel</a>.</p>
href="http://mail.shorewall.net/pipermail/shorewall-devel">http://mail.shorewall.net/pipermail/shorewall-devel</a>.</p>
<h2 align="left"><a name="Unsubscribe"></a>How to Unsubscribe from one of
the Mailing Lists</h2>
<p align="left">There seems to be near-universal confusion about unsubscribing
from Mailman-managed lists. To unsubscribe:</p>
from Mailman-managed lists although Mailman 2.1 has attempted to make
this less confusing. To unsubscribe:</p>
<ul>
<li>
<p align="left">Follow the same link above that you used to subscribe
to the list.</p>
</li>
<li>
<p align="left">Down at the bottom of that page is the following text:
"To change your subscription (set options like digest and delivery
modes, get a reminder of your password, <b>or unsubscribe</b> from
&lt;name of list&gt;), enter your subscription email address:". Enter
your email address in the box and click on the "Edit Options" button.</p>
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a password
reminder, or change your subscription options enter your subscription
email address:". Enter your email address in the box and click
on the "<b>Unsubscribe</b> or edit options" button.</p>
</li>
<li>
<p align="left">There will now be a box where you can enter your password
and click on "Unsubscribe"; if you have forgotten your password, there
is another button that will cause your password to be emailed to you.</p>
@ -235,12 +254,17 @@ your email address in the box and click on the "Edit Options" button.</p>
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
<p align="left"><font size="2">Last updated 12/27/2002 - <a
<p align="left"><font size="2">Last updated 12/31/2002 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

15
STABLE/documentation/mailing_list_problems.htm
View File

@ -40,21 +40,10 @@
<p align="left"><font size="2">Last updated 12/17/2002 02:51 GMT - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font face="Trebuchet MS"> <font
size="2">Copyright</font> © <font size="2">2002 Thomas M. Eastep.</font></font></a></p>
<p align="left"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2002 Thomas M. Eastep.</font></a></p>
<p align="left"> </p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

60
STABLE/documentation/myfiles.htm
View File

@ -20,6 +20,7 @@
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">About My Network</font></h1>
</td>
</tr>
@ -32,6 +33,13 @@
<h1>My Current Network </h1>
<blockquote>
<p><big><font color="#ff0000"><b>Warning: </b></font><b><small>I</small></b></big><big><b><small>
use a combination of Static NAT and Proxy ARP, neither of which are relevant
to a simple configuration with a single public IP address.</small></b></big><big><b><small>
If you have just a single public IP address, most of what you see here won't
apply to your setup so beware of copying parts of this configuration and
expecting them to work for you. They may or may not work in your setup. </small></b></big><br>
</p>
<p> I have DSL service and have 5 static IP addresses (206.124.146.176-180).
My DSL "modem" (<a href="http://www.fujitsu.com">Fujitsu</a> Speedport)
is connected to eth0. I have a local network connected to eth2 (subnet
@ -43,10 +51,10 @@
<ul>
<li>Static NAT for ursa (my XP System) - Internal address 192.168.1.5
and external address 206.124.146.178.</li>
<li>Proxy ARP for wookie (my Linux System). This system has two IP
addresses: 192.168.1.3/24 and 206.124.146.179/24.</li>
<li>SNAT through the primary gateway address (206.124.146.176) for 
my Wife's system (tarry) and the Wireless Access Point (wap)</li>
<li>Proxy ARP for wookie (my Linux System). This system has two
IP addresses: 192.168.1.3/24 and 206.124.146.179/24.</li>
<li>SNAT through the primary gateway address (206.124.146.176)
for  my Wife's system (tarry) and the Wireless Access Point (wap)</li>
</ul>
@ -62,8 +70,8 @@ the PopTop server running on my firewall. </p>
<p> The single system in the DMZ (address 206.124.146.177) runs postfix,
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP server
(Pure-ftpd). The system also runs fetchmail to fetch our email from our
old and current ISPs. That server is managed through Proxy ARP.</p>
(Pure-ftpd). The system also runs fetchmail to fetch our email from
our old and current ISPs. That server is managed through Proxy ARP.</p>
<p> The firewall system itself runs a DHCP server that serves the local
network.</p>
@ -91,11 +99,14 @@ the PopTop server running on my firewall. </p>
below).</p>
<p>A similar setup is used on eth3 (192.168.3.1) which
interfaces to my laptop (206.124.146.180).</p>
interfaces to my laptop (206.124.146.180).<br>
</p>
<p><font color="#ff0000" size="5"> Note: My files
use features not available before Shorewall
version 1.3.4.</font></p>
<p>Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior
access.<br>
</p>
<p><font color="#ff0000" size="5"></font></p>
</blockquote>
<h3>Shorewall.conf</h3>
@ -109,8 +120,8 @@ version 1.3.4.</font></p>
<h3>Interfaces File: </h3>
<blockquote>
<p> This is set up so that I can start the firewall before bringing up
my Ethernet interfaces. </p>
<p> This is set up so that I can start the firewall before bringing up my
Ethernet interfaces. </p>
</blockquote>
<pre><font face="Courier" size="2"> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping<br> loc eth2 192.168.1.255 dhcp,filterping,maclist<br> dmz eth1 206.124.146.255 filterping<br> net eth3 206.124.146.255 filterping,blacklist<br> - texas - filterping<br> loc ppp+ - filterping<br> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
@ -125,8 +136,7 @@ my Ethernet interfaces. </p>
<h3>Common File: </h3>
<pre><font size="2" face="Courier"> . /etc/shorewall/common.def<br> run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP<br> run_iptables -A common -p tcp --dport 113 -j REJECT</font></pre>
<pre><font size="2" face="Courier"> . /etc/shorewall/common.def<br> run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP<br></font></pre>
<h3>Policy File:</h3>
<pre><font size="2" face="Courier">
@ -140,9 +150,10 @@ my Ethernet interfaces. </p>
<h3>Masq File: </h3>
<blockquote>
<p> Although most of our internal systems use static NAT, my wife's system
(192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with
laptops. Also, I masquerade wookie to the peer subnet in Texas.</p>
laptops. Also, I masquerade wookie to the peer subnet in Texas.</p>
</blockquote>
<pre><font size="2" face="Courier"> #INTERFACE SUBNET ADDRESS<br> eth0 192.168.1.0/24 206.124.146.176<br> texas 206.124.146.179 192.168.1.254<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</font></pre>
@ -154,22 +165,23 @@ laptops. Also, I masquerade wookie to the peer subnet in Texas.</p>
<h3>Proxy ARP File:</h3>
<pre><font face="Courier" size="2"> #ADDRESS INTERFACE EXTERNAL HAVEROU</font><font
face="Courier" size="2">TE<br> 206.124.146.177 eth1 eth0 No<br> 206.124.146.180 eth3 eth0 No<br></font><font
face="Courier" size="2"> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
face="Courier" size="2">TE<br> 206.124.146.177 eth1 eth0 No<br> 206.124.146.180 eth3 eth0 No<br></font><pre><font
face="Courier" size="2"> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre></pre>
<h3>Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):</h3>
<pre><small> #TYPE          ZONE    GATEWAY</small><small> <br> gre             net     $TEXAS</small><small><br> #LAST LINE -- DO NOT REMOVE<br></small></pre>
<h3>Rules File (The shell variables
are set in /etc/shorewall/params):</h3>
<pre><font face="Courier" size="2"> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL<br> # PORT(S) PORT(S) PORT(S) DEST<br> #<br> # Local Network to Internet - Reject attempts by Trojans to call home<br> #<br> REJECT:info loc net tcp 6667<br> #<br> # Local Network to Firewall <br> #<br> ACCEPT loc fw tcp ssh<br> ACCEPT loc fw tcp time<br> #<br> # Local Network to DMZ <br> #<br> ACCEPT loc dmz udp domain<br> ACCEPT loc dmz tcp smtp<br> ACCEPT loc dmz tcp domain<br> ACCEPT loc dmz tcp ssh<br> ACCEPT loc dmz tcp auth<br> ACCEPT loc dmz tcp imap<br> ACCEPT loc dmz tcp https<br> ACCEPT loc dmz tcp imaps<br> ACCEPT loc dmz tcp cvspserver<br> ACCEPT loc dmz tcp www<br> ACCEPT loc dmz tcp ftp<br> ACCEPT loc dmz tcp pop3<br> ACCEPT loc dmz icmp echo-request<br> #<br> # Internet to DMZ <br> #<br> ACCEPT net dmz tcp www<br> ACCEPT net dmz tcp smtp<br> ACCEPT net dmz tcp ftp<br> ACCEPT net dmz tcp auth<br> ACCEPT net dmz tcp https<br> ACCEPT net dmz tcp imaps<br> ACCEPT net dmz tcp domain<br> ACCEPT net dmz tcp cvspserver<br> ACCEPT net dmz udp domain<br> ACCEPT net dmz icmp echo-request<br> ACCEPT net:$MIRRORS dmz tcp rsync<br> #<br> # Net to Me (ICQ chat and file transfers) <br> #<br> ACCEPT net me tcp 4000:4100<br> #<br> # Net to Local <br> #<br> ACCEPT net loc tcp auth<br> REJECT net loc tcp www<br> #<br> # DMZ to Internet<br> #<br> ACCEPT dmz net icmp echo-request<br> ACCEPT dmz net tcp smtp<br> ACCEPT dmz net tcp auth<br> ACCEPT dmz net tcp domain<br> ACCEPT dmz net tcp www<br> ACCEPT dmz net tcp https<br> ACCEPT dmz net tcp whois<br> ACCEPT dmz net tcp echo<br> ACCEPT dmz net udp domain<br> ACCEPT dmz net:$NTPSERVERS udp ntp<br> ACCEPT dmz net:$POPSERVERS tcp pop3<br> #<br> # The following compensates for a bug, either in some FTP clients or in the<br> # Netfilter connection tracking code that occasionally denies active mode<br> # FTP clients<br> #<br> ACCEPT:info dmz net tcp 1024: 20<br> #<br> # DMZ to Firewall -- snmp<br> #<br> ACCEPT dmz fw tcp snmp<br> ACCEPT dmz fw udp snmp<br> #<br> # DMZ to Local Network <br> #<br> ACCEPT dmz loc tcp smtp<br> ACCEPT dmz loc tcp auth<br> ACCEPT dmz loc icmp echo-request<br> # Internet to Firewall<br> #<br> ACCEPT net fw tcp 1723<br> ACCEPT net fw gre<br> REJECT net fw tcp www<br> #<br> # Firewall to Internet<br> #<br> ACCEPT fw net:$NTPSERVERS udp ntp<br> ACCEPT fw net udp domain<br> ACCEPT fw net tcp domain<br> ACCEPT fw net tcp www<br> ACCEPT fw net tcp https<br> ACCEPT fw net tcp ssh<br> ACCEPT fw net tcp whois<br> ACCEPT fw net icmp echo-request<br> #<br> # Firewall to DMZ<br> #<br> ACCEPT fw dmz tcp www<br> ACCEPT fw dmz tcp ftp<br> ACCEPT fw dmz tcp ssh<br> ACCEPT fw dmz tcp smtp<br> ACCEPT fw dmz udp domain<br> #<br> # Let Texas Ping<br> #<br> ACCEPT tx fw icmp echo-request<br> ACCEPT tx loc icmp echo-request<br><br> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
<pre><font face="Courier" size="2"> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL<br> # PORT(S) PORT(S) PORT(S) DEST<br> #<br> # Local Network to Internet - Reject attempts by Trojans to call home<br> #<br> REJECT:info loc net tcp 6667<br> #<br> # Local Network to Firewall <br> #<br> ACCEPT loc fw tcp ssh<br> ACCEPT loc fw tcp time<br> #<br> # Local Network to DMZ <br> #<br> ACCEPT loc dmz udp domain<br> ACCEPT loc dmz tcp smtp<br> ACCEPT loc dmz tcp domain<br> ACCEPT loc dmz tcp ssh<br> ACCEPT loc dmz tcp auth<br> ACCEPT loc dmz tcp imap<br> ACCEPT loc dmz tcp https<br> ACCEPT loc dmz tcp imaps<br> ACCEPT loc dmz tcp cvspserver<br> ACCEPT loc dmz tcp www<br> ACCEPT loc dmz tcp ftp<br> ACCEPT loc dmz tcp pop3<br> ACCEPT loc dmz icmp echo-request<br> #<br> # Internet to DMZ <br> #<br> ACCEPT net dmz tcp www<br> ACCEPT net dmz tcp smtp<br> ACCEPT net dmz tcp ftp<br> ACCEPT net dmz tcp auth<br> ACCEPT net dmz tcp https<br> ACCEPT net dmz tcp imaps<br> ACCEPT net dmz tcp domain<br> ACCEPT net dmz tcp cvspserver<br> ACCEPT net dmz udp domain<br> ACCEPT net dmz icmp echo-request<br> ACCEPT net:$MIRRORS dmz tcp rsync<br> #<br> # Net to Me (ICQ chat and file transfers) <br> #<br> ACCEPT net me tcp 4000:4100<br> #<br> # Net to Local <br> #<br> ACCEPT net loc tcp auth<br> REJECT net loc tcp www<br> ACCEPT net loc:192.168.1.5 tcp 1723<br> ACCEPT net loc:192.168.1.5 gre<br> #<br> # DMZ to Internet<br> #<br> ACCEPT dmz net icmp echo-request<br> ACCEPT dmz net tcp smtp<br> ACCEPT dmz net tcp auth<br> ACCEPT dmz net tcp domain<br> ACCEPT dmz net tcp www<br> ACCEPT dmz net tcp https<br> ACCEPT dmz net tcp whois<br> ACCEPT dmz net tcp echo<br> ACCEPT dmz net udp domain<br> ACCEPT dmz net:$NTPSERVERS udp ntp<br> ACCEPT dmz net:$POPSERVERS tcp pop3<br> #<br> # The following compensates for a bug, either in some FTP clients or in the<br> # Netfilter connection tracking code that occasionally denies active mode<br> # FTP clients<br> #<br> ACCEPT:info dmz net tcp 1024: 20<br> #<br> # DMZ to Firewall -- snmp<br> #<br> ACCEPT dmz fw tcp snmp<br> ACCEPT dmz fw udp snmp<br> #<br> # DMZ to Local Network <br> #<br> ACCEPT dmz loc tcp smtp<br> ACCEPT dmz loc tcp auth<br> ACCEPT dmz loc icmp echo-request<br> # Internet to Firewall<br> #<br> REJECT net fw tcp www<br> #<br> # Firewall to Internet<br> #<br> ACCEPT fw net:$NTPSERVERS udp ntp<br> ACCEPT fw net udp domain<br> ACCEPT fw net tcp domain<br> ACCEPT fw net tcp www<br> ACCEPT fw net tcp https<br> ACCEPT fw net tcp ssh<br> ACCEPT fw net tcp whois<br> ACCEPT fw net icmp echo-request<br> #<br> # Firewall to DMZ<br> #<br> ACCEPT fw dmz tcp www<br> ACCEPT fw dmz tcp ftp<br> ACCEPT fw dmz tcp ssh<br> ACCEPT fw dmz tcp smtp<br> ACCEPT fw dmz udp domain<br> #<br> # Let Texas Ping<br> #<br> ACCEPT tx fw icmp echo-request<br> ACCEPT tx loc icmp echo-request<br><br> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
<p><font size="2"> Last updated 10/14/2002 - </font><font size="2">
<p><font size="2"> Last updated 1/12/2003 - </font><font size="2">
<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><br>
<br>
<br>
<br>
<a href="copyright.htm"><font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<br>
</body>
</html>

12
STABLE/documentation/ping.html
View File

@ -26,11 +26,11 @@ way. This page describes how it now works.<br>
There are several aspects to Shorewall Ping management:<br>
<ol>
<li>The <b>noping</b> and <b>filterping </b>interface options in <a
href="file:///home/teastep/Shorewall-docs/Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>The <b>FORWARDPING</b> option in<a
href="file:///home/teastep/Shorewall-docs/Documentation.htm#Conf"> /etc/shorewall/shorewall.conf</a>.</li>
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf</a>.</li>
<li>Explicit rules in <a
href="file:///home/teastep/Shorewall-docs/Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
href="Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
</ol>
There are two cases to consider:<br>
<ol>
@ -81,10 +81,10 @@ then the request is responded to with an ICMP echo-reply.</li>
is either rejected or simply ignored.</li>
</ol>
<p><font size="2">Updated 12/13/2002 - <a
href="file:///home/teastep/Shorewall-docs/support.htm">Tom Eastep</a> </font></p>
href="support.htm">Tom Eastep</a> </font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
&copy; <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font>
&copy; <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
<br>
</body>
</html>

4
STABLE/documentation/ports.htm
View File

@ -187,8 +187,8 @@ Shorewall starts, then you should include the port list in /etc/modules.conf:<br
<p><font size="2">Last updated 11/10/2002 - </font><font size="2"> <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><br>
<a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a><br>
<br>
<br>
</body>

305
STABLE/documentation/seattlefirewall_index.htm
View File

@ -5,6 +5,7 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
@ -23,6 +24,7 @@
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%" height="90">
@ -33,13 +35,15 @@
<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.3 -
<font size="4">"<i>iptables made easy"</i></font></font></h1>
</a></i></font><font color="#ffffff">Shorewall 1.3
- <font size="4">"<i>iptables made easy"</i></font></font></h1>
@ -50,7 +54,9 @@
<div align="center"><a
href="http://shorewall.sf.net/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a><br>
</div>
<br>
</td>
@ -60,6 +66,7 @@
</tbody>
</table>
@ -74,6 +81,7 @@
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<td width="90%">
@ -84,6 +92,7 @@
<h2 align="left">What is it?</h2>
@ -114,18 +123,18 @@ General Public License</a> as published by the Free Software Foundation.<
<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>
@ -135,7 +144,8 @@ License for more details.<br>
<p><a href="copyright.htm">Copyright 2001, 2002 Thomas M. Eastep</a></p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -148,19 +158,22 @@ License for more details.<br>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</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.10
and Kernel-2.4.18. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</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.10 and Kernel-2.4.18. You
can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
</p>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
@ -174,6 +187,7 @@ Bering 1.0 Final!!! </b><br>
<h2>News</h2>
@ -183,6 +197,7 @@ Bering 1.0 Final!!! </b><br>
<h2></h2>
@ -190,52 +205,134 @@ Bering 1.0 Final!!! </b><br>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<p><b>1/13/2003 - Shorewall 1.3.13</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
<p>Just includes a few things that I had on the burner:<br>
</p>
<ol>
<li>A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules
file. DNAT- is intended for advanced users who wish to minimize the number
of rules that connection requests must traverse.<br>
<br>
A Shorewall DNAT rule actually generates two iptables rules: a header rewriting
rule in the 'nat' table and an ACCEPT rule in the 'filter' table. A DNAT-
rule only generates the first of these rules. This is handy when you have
several DNAT rules that would generate the same ACCEPT rule.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
<br>
   These three rules ended up generating _three_ copies of<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of the ACCEPT
rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
<br>
</li>
<li>The 'shorewall check' command now prints out the applicable policy
between each pair of zones.<br>
<br>
</li>
<li>A new CLEAR_TC option has been added to shorewall.conf. If this
option is set to 'No' then Shorewall won't clear the current traffic control
rules during [re]start. This setting is intended for use by people that prefer
to configure traffic shaping when the network interfaces come up rather than
when the firewall is started. If that is what you want to do, set TC_ENABLED=Yes
and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That way,
your traffic shaping rules can still use the 'fwmark' classifier based on
packet marking defined in /etc/shorewall/tcrules.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows distribution
packagers to easily move the shared directory (default /usr/lib/shorewall).
Users should never have a need to change the value of this shorewall.conf
setting.<br>
</li>
</ol>
<p><b>1/6/2003 -</b><b><big><big><big><big><big><big><big><big> B</big></big></big></big></big><small>U<small>R<small>N<small>O<small>U<small>T</small></small></small></small></small></small></big></big></big></b><b>
</b></p>
<p><b>Until further notice, I will not be involved in either Shorewall
Development or Shorewall Support</b></p>
<p><b>-Tom Eastep</b><br>
</p>
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b>
</b></p>
<p> Features include:<br>
</p>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules (tcrules
and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after an
error occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than 40% with
my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added which shows
the current packet classification filters. The output from this command
is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog level
and causes the subject packets to be logged using the ULOG target rather
than the LOG target. This allows you to run ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="configuration_file_basics.htm#Levels">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain in the mangle
table ("shorewall show mangle" will show you the chains in the mangle table),
you can set MARK_IN_FORWARD_CHAIN=Yes in <a
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after
an error occurs. This places the point of the failure near the end of
the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than
40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added
which shows the current packet classification filters. The output from
this command is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog
level and causes the subject packets to be logged using the ULOG target
rather than the LOG target. This allows you to run ulogd (available from
<a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain
in the mangle table ("shorewall show mangle" will show you the chains
in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
input packets based on their destination even when you are using Masquerading
or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with empty 'init',
'start', 'stop' and 'stopped' files. If you already have a file with one
of these names, don't worry -- the upgrade process won't overwrite your file.</li>
<li>I have cluttered up the /etc/shorewall directory with
empty 'init', 'start', 'stop' and 'stopped' files. If you already have
a file with one of these names, don't worry -- the upgrade process won't
overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable to <a
href="Documentation.htm#Conf">shorewall.conf</a>. This variable specifies
the syslog level at which packets are logged as a result of entries in the
/etc/shorewall/rfc1918 file. Previously, these packets were always logged
at the 'info' level.<br>
the syslog level at which packets are logged as a result of entries in
the /etc/shorewall/rfc1918 file. Previously, these packets were always
logged at the 'info' level.<br>
</li>
</ol>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
This version corrects a problem with Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL
was set to anything but ULOG, the firewall would fail to start and "shorewall
refresh" would also fail.<br>
This version corrects a problem with Blacklist logging. In Beta
2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would
fail to start and "shorewall refresh" would also fail.<br>
<p> You may download the Beta from:<br>
</p>
@ -245,93 +342,106 @@ refresh" would also fail.<br>
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is now available (Beta
1 was made available to a limited audience). <br>
The first public Beta version of Shorewall 1.3.12 is now available
(Beta 1 was made available to a limited audience). <br>
<br>
Features include:<br>
<br>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after
an error occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than 40%
with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added which
shows the current packet classification filters. The output from this command
is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog
level and causes the subject packets to be logged using the ULOG target
rather than the LOG target. This allows you to run ulogd (available from
<a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="configuration_file_basics.htm#Levels">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain in
the mangle table ("shorewall show mangle" will show you the chains in the
mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf.
This allows for marking input packets based on their destination even when
you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with empty
'init', 'start', 'stop' and 'stopped' files. If you already have a file
with one of these names, don't worry -- the upgrade process won't overwrite
your file.</li>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging
after an error occurs. This places the point of the failure near the
end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more
than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been
added which shows the current packet classification filters. The output
from this command is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid
syslog level and causes the subject packets to be logged using the ULOG
target rather than the LOG target. This allows you to run ulogd (available
from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain
in the mangle table ("shorewall show mangle" will show you the chains
in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf.
This allows for marking input packets based on their destination even
when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
won't overwrite your file.</li>
</ol>
You may download the Beta from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" width="150" height="21" border="0">
</a></b></p>
Shorewall is at the center of MandrakeSoft's recently-announced <a
Shorewall is at the center of MandrakeSoft's recently-announced
<a
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">Multi
Network Firewall (MNF)</a> product. Here is the <a
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
release</a>.<br>
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b><b>
</b></p>
<p>Two months and 3 days after I pre-ordered Mandrake 9.0, it was finally
delivered. I have installed 9.0 on one of my systems and I am now in
a position to support Shorewall users who run Mandrake 9.0.</p>
delivered. I have installed 9.0 on one of my systems and I am now
in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/6/2002 -  Debian 1.3.11a Packages Available</b><br>
</p>
<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users
who don't need rules of this type need not upgrade to 1.3.11.</p>
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11
users who don't need rules of this type need not upgrade to 1.3.11.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
@ -339,30 +449,34 @@ a position to support Shorewall users who run Mandrake 9.0.</p>
</p>
<p><b>11/24/2002 - Shorewall 1.3.11</b><b> </b><b>
</b></p>
<p>In this version:</p>
<ul>
<li>A 'tcpflags' option has been added to entries
in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
<li>A 'tcpflags' option has been added to
entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP packet
header flags.</li>
<li>It is now allowed to use 'all' in the SOURCE or
DEST column in a <a href="Documentation.htm#Rules">rule</a>. When
used, 'all' must appear by itself (in may not be qualified) and it does
not enable intra-zone traffic. For example, the rule <br>
header flags.</li>
<li>It is now allowed to use 'all' in the
SOURCE or DEST column in a <a href="Documentation.htm#Rules">rule</a>.
When used, 'all' must appear by itself (in may not be qualified) and
it does not enable intra-zone traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc' to 'loc'.</li>
<li>Shorewall's use of the 'echo' command is now compatible
with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate a startup error.
fw-&gt;fw rules generate a warning and are ignored</li>
<li>Shorewall's use of the 'echo' command
is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate a startup
error. fw-&gt;fw rules generate a warning and are ignored</li>
</ul>
@ -370,6 +484,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<p><b></b><a href="News.htm">More News</a></p>
@ -380,6 +495,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<h2><a name="Donations"></a>Donations</h2>
</td>
@ -392,6 +508,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
</tbody>
</table>
@ -405,7 +522,9 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<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;">
@ -416,6 +535,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
@ -429,6 +549,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<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
@ -436,18 +557,20 @@ but if you try it and find it useful, please consider making a donation
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 12/27/2002 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 1/13/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>

37
STABLE/documentation/shoreline.htm
View File

@ -6,6 +6,7 @@
content="text/html; charset=windows-1252">
<title>About the Shorewall Author</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
@ -58,7 +59,7 @@ present</li>
<p>I became interested in Internet Security when I established a home office
in 1999 and had DSL service installed in our home. I investigated
ipchains and developed the scripts which are now collectively known as
<a href="http://seawall.sourceforge.net"> Seattle Firewall</a>. Expanding
<a href="http://seawall.sourceforge.net"> Seattle Firewall</a>. Expanding
on what I learned from Seattle Firewall, I then designed and wrote
Shorewall. </p>
@ -69,22 +70,23 @@ present</li>
<ul>
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB &amp; 20GB
IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Also
has <a href="http://www.mandrakelinux.com">Mandrake</a> 9.0 installed.</li>
IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system.
Serves as a PPTP server for Road Warrior access. Also has <a
href="http://www.mandrakelinux.com">Mandrake</a> 9.0 installed.</li>
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
NIC - My personal Linux System which runs Samba configured as a WINS
server. This system also has <a href="http://www.vmware.com/">VMware</a>
installed and can run both <a href="http://www.debian.org">Debian
Woody</a> and <a href="http://www.suse.com">SuSE 8.1</a> in virtual
machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  -
Email (Postfix &amp; Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), DNS
server (Bind).</li>
NIC - My personal Linux System which runs Samba configured as a
WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run
both <a href="http://www.debian.org">Debian Woody</a> and <a
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC 
- Email (Postfix &amp; Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd),
DNS server (Bind).</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX 
(Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.11  and a DHCP
server.  Also runs PoPToP for road warrior access.</li>
(Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.12+  and a
DHCP server.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My
wife's personal system.</li>
wife's personal system.</li>
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard
EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main
work system.</li>
@ -114,11 +116,10 @@ work system.</li>
width="125" height="40" hspace="4">
</font></p>
<p><font size="2">Last updated 12/7/2002 - </font><font size="2"> <a
<p><font size="2">Last updated 1/7/2003 - </font><font size="2"> <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><br>
<br>
<br>
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas
M. Eastep.</font></a></font><br>
</body>
</html>

156
STABLE/documentation/shorewall_logging.html Executable file
View File

@ -0,0 +1,156 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Shorewall Logging</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Logging</font></h1>
</td>
</tr>
</tbody>
</table>
<br>
By default, Shorewall directs NetFilter to log using syslog (8). Syslog
classifies log messages by a <i>facility</i> and a <i>priority</i> (using
the notation <i>facility.priority</i>). <br>
<br>
The facilities defined by syslog are <i>auth, authpriv, cron, daemon,
kern, lpr, mail, mark, news, syslog, user, uucp</i> and <i>local0</i> through
<i>local7</i>.<br>
<br>
Throughout the Shorewall documentation, I will use the term <i>level</i>
rather than <i>priority</i> since <i>level</i> is the term used by NetFilter.
The syslog documentation uses the term <i>priority</i>.<br>
<h3>Syslog Levels<br>
</h3>
Syslog levels are a method of describing to syslog (8) the importance
of a message and a number of Shorewall parameters have a syslog level
as their value.<br>
<br>
Valid levels are:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
debug<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
info<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
notice<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
warning<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
err<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
crit<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
alert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
emerg<br>
<br>
For most Shorewall logging, a level of 6 (info) is appropriate.
Shorewall log messages are generated by NetFilter and are logged using
the <i>kern</i> facility and the level that you specify. If you are unsure
of the level to choose, 6 (info) is a safe bet. You may specify levels
by name or by number.<br>
<br>
Syslogd writes log messages to files (typically in /var/log/*) based
on their facility and level. The mapping of these facility/level pairs
to log files is done in /etc/syslog.conf (5). If you make changes to this
file, you must restart syslogd before the changes can take effect.<br>
<h3>Configuring a Separate Log for Shorewall Messages</h3>
There are a couple of limitations to syslogd-based logging:<br>
<ol>
<li>If you give, for example, kern.info it's own log destination then
that destination will also receive all kernel messages of levels 5 (notice)
through 0 (emerg).</li>
<li>All kernel.info messages will go to that destination and not just
those from NetFilter.<br>
</li>
</ol>
Beginning with Shorewall version 1.3.12, if your kernel has ULOG
target support (and most vendor-supplied kernels do), you may also specify
a log level of ULOG (must be all caps). When ULOG is used, Shorewall will
direct netfilter to log the related messages via the ULOG target which will
send them to a process called 'ulogd'. The ulogd program is available from
http://www.gnumonks.org/projects/ulogd and can be configured to log all
Shorewall message to their own log file.<br>
<br>
<b>Note: </b>The ULOG logging mechanism is <u>completely separate</u> from
syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have absolutely
no effect on your Shorewall logging (except for Shorewall status messages
which still go to syslog).<br>
<br>
You will need to have the kernel source available to compile ulogd.<br>
<br>
Download the ulod tar file and:<br>
<ol>
<li>Be sure that /usr/src/linux is linked to your kernel source tree<br>
</li>
<li>cd /usr/local/src (or wherever you do your builds)</li>
<li>tar -zxf <i>source-tarball-that-you-downloaded</i></li>
<li>cd ulogd-<i>version</i><br>
</li>
<li>./configure</li>
<li>make</li>
<li>make install<br>
</li>
</ol>
If you are like me and don't have a development environment on your firewall,
you can do the first six steps on another system then either NFS mount
your /usr/local/src directory or tar up the /usr/local/src/ulogd-<i>version</i>
directory and move it to your firewall system.<br>
<br>
Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:<br>
<ol>
<li>syslogfile <i>&lt;file that you wish to log to&gt;</i></li>
<li>syslogsync 1</li>
</ol>
I also copied the file /usr/local/src/ulogd-<i>version</i>/ulogd.init
to /etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd"
to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple
"chkconfig --level 3 ulogd on" starts ulogd during boot up. Your init system
may need something else done to activate the script.<br>
<br>
You will need to change all instances of log levels (usually 'info') in
your configuration files to 'ULOG' - this includes entries in the policy,
rules and shorewall.conf files. Here's what I have:<br>
<pre> [root@gateway shorewall]# grep ULOG *<br> policy:loc&nbsp; fw&nbsp;&nbsp; REJECT&nbsp; ULOG<br> policy:net&nbsp; all&nbsp; DROP&nbsp;&nbsp;&nbsp; ULOG&nbsp;&nbsp;&nbsp;10/sec:40<br> policy:all&nbsp; all&nbsp; REJECT&nbsp; ULOG<br> rules:REJECT:ULOG loc net tcp 6667<br> shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG<br> shorewall.conf:RFC1918_LOG_LEVEL=ULOG<br> [root@gateway shorewall]#<br></pre>
Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<i>&lt;file
that you wish to log to&gt;</i>. This tells the /sbin/shorewall program
where to look for the log when processing its "show log", "logwatch" and
"monitor" commands.<br>
<p><font size="2"> Updated 1/11/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<font size="2">2001, 2002, 2003 Thomas M. Eastep</font></a><br>
</p>
</body>
</html>

110
STABLE/documentation/shorewall_quickstart_guide.htm
View File

@ -24,7 +24,9 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides<br>
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
Version 3.1</font></h1>
</td>
</tr>
@ -32,8 +34,8 @@
</tbody>
</table>
<p align="center">With thanks to Richard who reminded me once again that
we must all first walk before we can run.</p>
<p align="center">With thanks to Richard who reminded me once again that we
must all first walk before we can run.</p>
<h2>The Guides</h2>
@ -44,8 +46,8 @@ we must all first walk before we can run.</p>
<ul>
<li><a href="standalone.htm">Standalone</a> Linux System</li>
<li><a href="two-interface.htm">Two-interface</a> Linux System
acting as a firewall/router for a small local network</li>
<li><a href="two-interface.htm">Two-interface</a> Linux
System acting as a firewall/router for a small local network</li>
<li><a href="three-interface.htm">Three-interface</a> Linux
System acting as a firewall/router for a small local network and
a DMZ.</li>
@ -61,22 +63,23 @@ a DMZ.</li>
than is explained in the single-address guides above.</b></p>
<ul>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0 Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0
Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0 Shorewall
Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0 Network
Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0 Addressing,
Subnets and Routing</a>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0
Network Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0
Addressing, Subnets and Routing</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Addresses">4.1 IP
Addresses</a></li>
<li><a href="shorewall_setup_guide.htm#Addresses">4.1
IP Addresses</a></li>
<li><a
href="shorewall_setup_guide.htm#Subnets">4.2 Subnets</a></li>
<li><a href="shorewall_setup_guide.htm#Routing">4.3 Routing</a></li>
<li><a href="shorewall_setup_guide.htm#ARP">4.4 Address
Resolution Protocol</a></li>
Resolution Protocol</a></li>
</ul>
@ -84,7 +87,7 @@ Resolution Protocol</a></li>
<ul>
<li><a href="shorewall_setup_guide.htm#RFC1918">4.5 RFC
1918</a></li>
1918</a></li>
</ul>
@ -100,23 +103,27 @@ Resolution Protocol</a></li>
<ul>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2 Non-routed</a>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2
Non-routed</a>
<ul>
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1 SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2 DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1
SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2
DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#ProxyARP">5.2.3
Proxy ARP</a></li>
Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4 Static
NAT</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a href="shorewall_setup_guide.htm#OddsAndEnds">5.4
Odds and Ends</a></li>
Odds and Ends</a></li>
</ul>
@ -132,12 +139,13 @@ Odds and Ends</a></li>
<p>The following documentation covers a variety of topics and <b>supplements
the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
described above</b>. Please review the appropriate guide before trying
to use this documentation directly.</p>
described above</b>. Please review the appropriate guide before trying
to use this documentation directly.</p>
<ul>
<li><a href="blacklisting_support.htm">Blacklisting</a>
<ul>
<li>Static Blacklisting using /etc/shorewall/blacklist</li>
<li>Dynamic Blacklisting using /sbin/shorewall</li>
@ -149,18 +157,26 @@ to use this documentation directly.</p>
file features</a>
<ul>
<li>Comments in configuration files</li>
<li>Line Continuation</li>
<li>Port Numbers/Service Names</li>
<li>Port Ranges</li>
<li>Using Shell Variables</li>
<li>Using DNS Names<br>
</li>
<li>Complementing an IP address or Subnet</li>
<li>Shorewall Configurations (making a test configuration)</li>
<li>Using MAC Addresses in Shorewall</li>
<li>Logging<br>
<li><a href="configuration_file_basics.htm#Comments">Comments
in configuration files</a></li>
<li><a
href="configuration_file_basics.htm#Continuation">Line Continuation</a></li>
<li><a href="configuration_file_basics.htm#Ports">Port
Numbers/Service Names</a></li>
<li><a href="configuration_file_basics.htm#Ranges">Port
Ranges</a></li>
<li><a
href="configuration_file_basics.htm#Variables">Using Shell Variables</a></li>
<li><a href="configuration_file_basics.htm#dnsnames">Using
DNS Names</a><br>
</li>
<li><a
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a href="configuration_file_basics.htm#Configs">Shorewall
Configurations (making a test configuration)</a></li>
<li><a href="configuration_file_basics.htm#MAC">Using
MAC Addresses in Shorewall</a></li>
</ul>
@ -203,15 +219,18 @@ to use this documentation directly.</p>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font> (How
to extend Shorewall without modifying Shorewall code)</li>
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall Structure</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall
Structure</a></li>
<li><font color="#000099"><a href="kernel.htm">Kernel Configuration</a></font></li>
<li><a href="configuration_file_basics.htm#Levels">Logging</a><br>
<li><a href="shorewall_logging.html">Logging</a><br>
</li>
<li><a href="myfiles.htm">My Configuration Files</a> (How
I personally use Shorewall)</li>
<li><a href="MAC_Validation.html">MAC Verification</a><br>
</li>
<li><a href="myfiles.htm">My Configuration Files</a> (How I personally
use Shorewall)</li>
<li><a href="ping.html">'Ping' Management</a><br>
</li>
<li><a href="ports.htm">Port Information</a>
@ -235,7 +254,10 @@ I personally use Shorewall)</li>
</ul>
<li><font color="#000099"><a href="NAT.htm">Static NAT</a></font></li>
<li><a href="traffic_shaping.htm">Traffic Shaping/Control</a></li>
<li><a href="Shorewall_Squid_Usage.html">Squid as a Transparent Proxy with
Shorewall</a><br>
</li>
<li><a href="traffic_shaping.htm">Traffic Shaping/QOS</a></li>
<li>VPN
<ul>
@ -249,21 +271,19 @@ I personally use Shorewall)</li>
</ul>
</li>
<li><a href="whitelisting_under_shorewall.htm">White List
Creation</a></li>
Creation</a></li>
</ul>
<p>If you use one of these guides and have a suggestion for improvement <a
href="mailto:webmaster@shorewall.net">please let me know</a>.</p>
<p><font size="2">Last modified 12/13/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last modified 1/9/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002 Thomas M. Eastep</font></a><br>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

369
STABLE/documentation/shorewall_setup_guide.htm
View File

@ -58,12 +58,12 @@
more about Shorewall than is contained in the <a
href="shorewall_quickstart_guide.htm">single-address guides</a>. Because
the range of possible applications is so broad, the Guide will give you
general guidelines and will point you to other resources as necessary.</p>
general guidelines and will point you to other resources as necessary.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you run LEAF Bering, your Shorewall configuration is NOT what I
release -- I suggest that you consider installing a stock Shorewall lrp from
the shorewall.net site before you proceed.</p>
    If you run LEAF Bering, your Shorewall configuration is NOT what
I release -- I suggest that you consider installing a stock Shorewall lrp
from the shorewall.net site before you proceed.</p>
<p>This guide assumes that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
@ -81,16 +81,16 @@ for this program:</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows 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 with Shorewall. 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>
save them as Unix files if your editor supports that option or you must
run them through dos2unix before trying to use them with Shorewall. 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>
<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>
Version of dos2unix</a></li>
</ul>
@ -142,8 +142,8 @@ in this guide. Skeleton files are created during the <a
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
to zone names. Zones are entirely what YOU make of them. That means that
you should not expect Shorewall to do something special "because this is
the internet zone" or "because that is the DMZ".</p>
you should not expect Shorewall to do something special "because this
is the internet zone" or "because that is the DMZ".</p>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    Edit the /etc/shorewall/zones file and make any changes necessary.</p>
@ -152,8 +152,8 @@ in this guide. Skeleton files are created during the <a
in terms of zones.</p>
<ul>
<li>You express your default policy for connections from one zone to
another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
<li>You express your default policy for connections from one zone
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
</a>file.</li>
<li>You define exceptions to those default policies in the <a
href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
@ -166,7 +166,7 @@ another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
tracking function</a> that allows what is often referred to as <i>stateful
inspection</i> of packets. This stateful property allows firewall rules
to be defined in terms of <i>connections</i> rather than in terms of
packets. With Shorewall, you:</p>
packets. With Shorewall, you:</p>
<ol>
<li> Identify the source zone.</li>
@ -174,9 +174,9 @@ packets. With Shorewall, you:</p>
<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> 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>
@ -238,18 +238,18 @@ the request is first checked against the rules in /etc/shorewall/common.def.</
<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 and log a message at the <i>info</i> level
(<a href="configuration_file_basics.htm#Levels">here</a> is a description
of log levels).</li>
<li>reject all other connection requests and log a message at the <i>info</i>
level. When a request is rejected, the firewall will return an RST (if
the protocol is TCP) or an ICMP port-unreachable packet for other protocols.</li>
firewall or local network and log a message at the <i>info</i> level
(<a href="shorewall_logging.html">here</a> is a description of log levels).</li>
<li>reject all other connection requests and log a message at the
<i>info</i> level. When a request is rejected, the firewall will
return an RST (if the protocol is TCP) or an ICMP port-unreachable packet
for other protocols.</li>
</ol>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    At this point, edit your /etc/shorewall/policy and make any changes
that you wish.</p>
that you wish.</p>
<h2 align="left"><a name="Interfaces"></a>3.0 Network Interfaces</h2>
@ -261,11 +261,11 @@ that you wish.</p>
<ul>
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
to isolate your internet-accessible servers from your local systems so
to isolate your internet-accessible servers from your local systems so
that if one of those servers is compromised, you still have the firewall
between the compromised system and your local systems. </li>
<li>The Local Zone consists of systems Local 1, Local 2 and Local 3.
</li>
<li>The Local Zone consists of systems Local 1, Local 2 and Local
3. </li>
<li>All systems from the ISP outward comprise the Internet Zone. </li>
</ul>
@ -275,8 +275,8 @@ between the compromised system and your local systems. </li>
</p>
<p align="left">The simplest way to define zones is to simply associate the
zone name (previously defined in /etc/shorewall/zones) with a network interface.
This is done in the <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
zone name (previously defined in /etc/shorewall/zones) with a network
interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file.</p>
<p align="left">The firewall illustrated above has three network interfaces.
@ -284,33 +284,33 @@ between the compromised system and your local systems. </li>
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 via a regular
modem, your External Interface will also be <b>ppp0</b>. If you connect
using ISDN, you external interface will be <b>ippp0.</b></p>
<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
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then you
will want to set CLAMPMSS=yes in <a href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
will want to set CLAMPMSS=yes in <a href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
<p align="left">Your <i>Local Interface</i> will be an Ethernet adapter (eth0,
eth1 or eth2) and will be connected to a hub or switch. Your local computers
will be connected to the same switch (note: If you have only a single local
system, you can connect the firewall directly to the computer using a <i>cross-over
</i> cable).</p>
will be connected to the same switch (note: If you have only a single
local system, you can connect the firewall directly to 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>
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>
<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 Linux networking doesn't work at
will end up confused and believing that Linux networking doesn't work at
all.</p>
<p align="left">For the remainder of this Guide, we will assume that:</p>
@ -370,7 +370,8 @@ all.</p>
    Edit the /etc/shorewall/interfaces file and define the network interfaces
on your firewall and associate each interface with a zone. If you have
a zone that is interfaced through more than one interface, simply include
one entry for each interface and repeat the zone name as many times as necessary.</p>
one entry for each interface and repeat the zone name as many times as
necessary.</p>
<p align="left">Example:</p>
@ -446,10 +447,10 @@ one entry for each interface and repeat the zone name as many times as necessar
<h2 align="left"><a name="Addressing"></a>4.0 Addressing, Subnets and Routing</h2>
<p align="left">Normally, your ISP will assign you a set of <i> Public</i>
IP addresses. You will configure your firewall's external interface to use
one of those addresses permanently and you will then have to decide how
you are going to use the rest of your addresses. Before we tackle that question
though, some background is in order.</p>
IP addresses. You will configure your firewall's external interface to
use one of those addresses permanently and you will then have to decide
how you are going to use the rest of your addresses. Before we tackle that
question though, some background is in order.</p>
<p align="left">If you are thoroughly familiar with IP addressing and routing,
you may <a href="#Options">go to the next section</a>.</p>
@ -481,8 +482,8 @@ value "w", the next byte has value "x", etc. If we take the address 192.0.2.14
<p align="left">You will still hear the terms "Class A network", "Class B
network" and "Class C network". In the early days of IP, networks only
came in three sizes (there were also Class D networks but they were used
differently):</p>
came in three sizes (there were also Class D networks but they were used
differently):</p>
<blockquote>
<p align="left">Class A - netmask 255.0.0.0, size = 2 ** 24</p>
@ -495,10 +496,10 @@ differently):</p>
<p align="left">The class of a network was uniquely determined by the value
of the high order byte of its address so you could look at an IP address
and immediately determine the associated <i>netmask</i>. The netmask is
a number that when logically ANDed with an address isolates the <i>network
a number that when logically ANDed with an address isolates the <i>network
number</i>; the remainder of the address is the <i>host number</i>. For
example, in the Class C address 192.0.2.14, the network number is hex C00002
and the host number is hex 0E.</p>
example, in the Class C address 192.0.2.14, the network number is hex C00002
and the host number is hex 0E.</p>
<p align="left">As the internet grew, it became clear that such a gross partitioning
of the 32-bit address space was going to be very limiting (early on, large
@ -533,15 +534,15 @@ to as
<p align="left">As you can see by this definition, in each subnet of size
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that can
be assigned to hosts). The first and last address in the subnet are used
for the subnet address and subnet broadcast address respectively. Consequently,
small subnetworks are more wasteful of IP addresses than are large ones.
</p>
be assigned to hosts). The first and last address in the subnet are
used for the subnet address and subnet broadcast address respectively.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
<p align="left">Since <b>n</b> is a power of two, we can easily calculate
the <i>Natural Logarithm</i> (<b>log2</b>) of <b>n</b>. For the more common
subnet sizes, the size and its natural logarithm are given in the following
table:</p>
the <i>Natural Logarithm</i> (<b>log2</b>) of <b>n</b>. For the more
common subnet sizes, the size and its natural logarithm are given in the
following table:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -630,7 +631,7 @@ to as
<p align="left">You will notice that the above table also contains a column
for (32 - log2 <b>n</b>). That number is the <i>Variable Length Subnet
Mask</i> for a network of size <b>n</b>. From the above table, we can
derive the following one which is a little easier to use.</p>
derive the following one which is a little easier to use.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -738,12 +739,13 @@ subnet mask has 26 leading one bits:</p>
<p align="left">The subnet mask has the property that if you logically AND
the subnet mask with an address in the subnet, the result is the subnet
address. Just as important, if you logically AND the subnet mask with
an address outside the subnet, the result is NOT the subnet address. As
we will see below, this property of subnet masks is very useful in routing.</p>
an address outside the subnet, the result is NOT the subnet address.
As we will see below, this property of subnet masks is very useful in
routing.</p>
<p align="left">For a subnetwork whose address is <b>a.b.c.d</b> and whose
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork as
"<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
"<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
<p align="left">Example:</p>
@ -835,9 +837,9 @@ to VLSM <b>/v</b>.</p>
the Dallas, Texas area.<br>
<br>
The first three routes are <i>host routes</i> since they indicate how
to get to a single host. In the 'netstat' output this can be seen by the
"Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags column.
The remainder are 'net' routes since they tell the kernel how to route
to get to a single host. In the 'netstat' output this can be seen by the
"Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags column.
The remainder are 'net' routes since they tell the kernel how to route
packets to a subnetwork. The last route is the <i>default route</i> and
the gateway mentioned in that route is called the <i>default gateway</i>.</p>
@ -883,8 +885,8 @@ router at your ISP.</p>
<p align="left">Lets take an example. Suppose that we want to route a packet
to 192.168.1.5. That address clearly doesn't match any of the host routes
in the table but if we logically and that address with 255.255.255.0, the
result is 192.168.1.0 which matches this routing table entry:</p>
in the table but if we logically and that address with 255.255.255.0,
the result is 192.168.1.0 which matches this routing table entry:</p>
<div align="left">
<blockquote>
@ -956,11 +958,11 @@ with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.</p>
</blockquote>
<p align="left">The leading question marks are a result of my having specified
the 'n' option (Windows 'arp' doesn't allow that option) which causes the
'arp' program to forego IP-&gt;DNS name translation. Had I not given that
option, the question marks would have been replaced with the FQDN corresponding
to each IP address. Notice that the last entry in the table records the
information we saw using tcpdump above.</p>
the 'n' option (Windows 'arp' doesn't allow that option) which causes
the 'arp' program to forego IP-&gt;DNS name translation. Had I not given
that option, the question marks would have been replaced with the FQDN
corresponding to each IP address. Notice that the last entry in the table
records the information we saw using tcpdump above.</p>
<h3 align="left"><a name="RFC1918"></a>4.5 RFC 1918</h3>
@ -971,7 +973,7 @@ information we saw using tcpdump above.</p>
sub-Sahara Africa is delegated to the <i><a href="http://www.arin.net">American
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn delegate
to national registries. Most of us don't deal with these registrars but
rather get our IP addresses from our ISP.</p>
rather get our IP addresses from our ISP.</p>
<p align="left">It's a fact of life that most of us can't afford as many
Public IP addresses as we have devices to assign them to so we end up making
@ -985,9 +987,9 @@ ranges for this purpose:</p>
<div align="left">
<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. This is understandable
forward packets which have an RFC-1918 destination address. This is understandable
given that anyone can select any of these addresses for their private
use.</p>
use.</p>
</div>
<div align="left">
@ -1005,7 +1007,7 @@ more organizations (including ISPs) are beginning to use RFC 1918 addresses
<li>
<p align="left">You don't want to use addresses that are being used by
your ISP or by another organization with whom you want to establish
a VPN relationship. </p>
a VPN relationship. </p>
</li>
</ul>
@ -1033,9 +1035,9 @@ your ISP will handle that set of addresses in one of two ways:</p>
<li>
<p align="left"><b>Routed - </b>Traffic to any of your addresses will
be routed through a single <i>gateway address</i>. This will generally
only be done if your ISP has assigned you a complete subnet (/29 or larger).
In this case, you will assign the gateway address as the IP address of
your firewall/router's external interface. </p>
only be done if your ISP has assigned you a complete subnet (/29 or
larger). In this case, you will assign the gateway address as the IP
address of your firewall/router's external interface. </p>
</li>
<li>
<p align="left"><b>Non-routed - </b>Your ISP will send traffic to each
@ -1048,18 +1050,22 @@ your ISP will handle that set of addresses in one of two ways:</p>
<div align="left">
<p align="left">In the subsections that follow, we'll look at each of these
separately.<br>
</p>
</p>
<p align="left">Before we begin, there is one thing for you to check:</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    If you are using the Debian package, please check your shorewall.conf
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
</p>
<ul>
<li>NAT_ENABLED=Yes</li>
<li>IP_FORWARDING=On<br>
</li>
</ul>
</div>
@ -1092,12 +1098,12 @@ the local network would be 192.0.2.73.</p>
<div align="left">
<p align="left">Notice that this arrangement is rather wasteful of public
IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet addresses,
192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and 192.0.2.66
and 168.0.2.73 for internal addresses on the firewall/router. Nevertheless,
it shows how subnetting can work and if we were dealing with a /24 rather
than a /28 network, the use of 6 IP addresses out of 256 would be justified
because of the simplicity of the setup.</p>
IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses
and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
Nevertheless, it shows how subnetting can work and if we were dealing
with a /24 rather than a /28 network, the use of 6 IP addresses out
of 256 would be justified because of the simplicity of the setup.</p>
</div>
<div align="left">
@ -1116,10 +1122,10 @@ routing table on DMZ 1 will look like this:</p>
<div align="left">
<p align="left">This means that DMZ 1 will send an ARP "who-has 192.0.2.65"
request and no device on the DMZ Ethernet segment has that IP address.
Oddly enough, the firewall will respond to the request with the MAC address
of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames addressed
to that MAC address and the frames will be received (correctly) by the
firewall/router.</p>
Oddly enough, the firewall will respond to the request with the MAC
address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames
addressed to that MAC address and the frames will be received (correctly)
by the firewall/router.</p>
</div>
<div align="left">
@ -1128,8 +1134,8 @@ the Linux Kernel that prompts the warning earlier in this guide regarding
the connecting of multiple firewall/router interfaces to the same hub
or switch. When an ARP request for one of the firewall/router's IP addresses
is sent by another system connected to the hub/switch, all of the firewall's
interfaces that connect to the hub/switch can respond! It is then a race
as to which "here-is" response reaches the sender first.</p>
interfaces that connect to the hub/switch can respond! It is then a
race as to which "here-is" response reaches the sender first.</p>
</div>
<div align="left">
@ -1152,7 +1158,7 @@ IP addresses to set up our networks as shown in the preceding example
<div align="left">
<p align="left"><b>For the remainder of this section, assume that your ISP
has assigned you IP addresses 192.0.2.176-180 and has told you to use
netmask 255.255.255.0 and default gateway 192.0.2.254.</b></p>
netmask 255.255.255.0 and default gateway 192.0.2.254.</b></p>
</div>
<div align="left">
@ -1196,17 +1202,17 @@ these will be discussed in the sections that follow.</p>
<p align="left">With SNAT, an internal LAN segment is configured using RFC
1918 addresses. When a host <b>A </b>on this internal segment initiates
a connection to host <b>B</b> on the internet, the firewall/router rewrites
the IP header in the request to use one of your public IP addresses as
the source address. When <b>B</b> responds and the response is received
the IP header in the request to use one of your public IP addresses
as the source address. When <b>B</b> responds and the response is received
by the firewall, the firewall changes the destination address back to
the RFC 1918 address of <b>A</b> and forwards the response back to <b>A.</b></p>
the RFC 1918 address of <b>A</b> and forwards the response back to <b>A.</b></p>
</div>
<div align="left">
<p align="left">Let's suppose that you decide to use SNAT on your local zone
and use public address 192.0.2.176 as both your firewall's external IP
address and the source IP address of internet requests sent from that
zone.</p>
and use public address 192.0.2.176 as both your firewall's external
IP address and the source IP address of internet requests sent from
that zone.</p>
</div>
<div align="left">
@ -1223,7 +1229,7 @@ zone.</p>
<div align="left"> <img border="0" src="images/BD21298_2.gif"
width="13" height="13">
    The systems in the local zone would be configured with a default
gateway of 192.168.201.1 (the IP address of the firewall's local interface).</div>
gateway of 192.168.201.1 (the IP address of the firewall's local interface).</div>
<div align="left">  </div>
@ -1255,11 +1261,11 @@ gateway of 192.168.201.1 (the IP address of the firewall's local interface).<
<div align="left">
<p align="left">This example used the normal technique of assigning the same
public IP address for the firewall external interface and for SNAT. If
you wanted to use a different IP address, you would either have to use
your distributions network configuration tools to add that IP address
to the external interface or you could set ADD_SNAT_ALIASES=Yes in
/etc/shorewall/shorewall.conf and Shorewall will add the address for you.</p>
public IP address for the firewall external interface and for SNAT.
If you wanted to use a different IP address, you would either have to
use your distributions network configuration tools to add that IP address
to the external interface or you could set ADD_SNAT_ALIASES=Yes in
/etc/shorewall/shorewall.conf and Shorewall will add the address for you.</p>
</div>
<div align="left">
@ -1268,9 +1274,9 @@ to the external interface or you could set ADD_SNAT_ALIASES=Yes in
<div align="left">
<p align="left">When SNAT is used, it is impossible for hosts on the internet
to initiate a connection to one of the internal systems since those systems
do not have a public IP address. DNAT provides a way to allow selected
connections from the internet.</p>
to initiate a connection to one of the internal systems since those
systems do not have a public IP address. DNAT provides a way to allow
selected connections from the internet.</p>
</div>
<div align="left">
@ -1368,8 +1374,8 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<div align="left"> Here, we've assigned the IP addresses 192.0.2.177 to
system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned
an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface
on the firewall. That address and netmask isn't relevant - just be sure
it doesn't overlap another subnet that you've defined.</div>
on the firewall. That address and netmask isn't relevant - just be sure
it doesn't overlap another subnet that you've defined.</div>
<div align="left">  </div>
@ -1409,32 +1415,74 @@ it doesn't overlap another subnet that you've defined.</div>
<div align="left">
<p align="left">Because the HAVE ROUTE column contains No, Shorewall will
add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.</p>
add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.<br>
</p>
<p align="left">The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
to have the IP addresses shown but should have the same default gateway as
the firewall itself -- namely 192.0.2.254.<br>
</p>
</div>
<div align="left">
<p align="left"></p>
</div>
<div align="left">
<div align="left">
<p align="left">A word of warning is in order here. ISPs typically configure
their routers with a long ARP cache timeout. If you move a system from
parallel to your firewall to behind your firewall with Proxy ARP, it
will probably be HOURS before that system can communicate with the internet.
You can call your ISP and ask them to purge the stale ARP cache entry
but many either can't or won't purge individual entries. You can determine
if your ISP's gateway ARP cache is stale using ping and tcpdump. Suppose
that we suspect that the gateway router has a stale ARP cache entry for
192.0.2.177. On the firewall, run tcpdump as follows:</p>
parallel to your firewall to behind your firewall with Proxy ARP, it will
probably be HOURS before that system can communicate with the internet.
There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their ARP
cache (section 4.7). A gratuitous ARP is simply a host requesting the MAC
address for its own IP; in addition to ensuring that the IP address isn't
a duplicate,...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware address...,
this packet causes any other host...that has an entry in its cache for the
old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP (or
static NAT for that matter). Happily enough, recent versions of Redhat's iputils
package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly proxied
IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to gratuitous
ARPs, but googling for "arping -U" seems to support the idea that it works
most of the time.<br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.</li>
</ol>
You can determine if your ISP's gateway ARP cache is stale using ping
and tcpdump. Suppose that we suspect that the gateway router has a stale
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
</div>
<div align="left">
<pre> tcpdump -nei eth0 icmp</pre>
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
will assume is 130.252.100.254):</p>
</div>
<div align="left">
<p align="left">Now from 192.0.2.177, ping the default gateway (which we
are assuming is 192.0.2.254):</p>
<pre> <b><font color="#009900">ping 130.252.100.254</font></b></pre>
</div>
<div align="left">
<pre> ping 192.0.2.254</pre>
</div>
<div align="left">
@ -1450,8 +1498,8 @@ are assuming is 192.0.2.254):</p>
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of DMZ 1. In other words, the gateway's ARP cache
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the
firewall's eth0.</p>
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the
firewall's eth0.</p>
</div>
<div align="left">
@ -1503,8 +1551,9 @@ firewall's eth0.</p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Suppose now that you have decided to give your daughter her own
IP address (192.0.2.179) for both inbound and outbound connections. You
would do that by adding an entry in <a href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
IP address (192.0.2.179) for both inbound and outbound connections.
You would do that by adding an entry in <a
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
</div>
<div align="left">
@ -1540,10 +1589,10 @@ would do that by adding an entry in <a href="Documentation.htm#NAT">/etc/sho
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Once the relationship between 192.0.2.179 and 192.168.201.4 is established
by the nat file entry above, it is no longer appropriate to use a
DNAT rule for you daughter's web server -- you would rather just use
an ACCEPT rule:</p>
    Once the relationship between 192.0.2.179 and 192.168.201.4 is
established by the nat file entry above, it is no longer appropriate
to use a DNAT rule for you daughter's web server -- you would rather just
use an ACCEPT rule:</p>
</div>
<div align="left">
@ -1582,12 +1631,13 @@ an ACCEPT rule:</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    With the default policies, your local systems (Local 1-3) can access
any servers on the internet and the DMZ can't access any other host (including
the firewall). With the exception of <a href="#DNAT">DNAT rules</a> which
cause address translation and allow the translated connection request
to pass through the firewall, the way to allow connection requests through
your firewall is to use ACCEPT rules.</p>
    With the default policies, your local systems (Local 1-3) can
access any servers on the internet and the DMZ can't access any other
host (including the firewall). With the exception of <a
href="#DNAT">DNAT rules</a> which cause address translation and allow
the translated connection request to pass through the firewall, the way
to allow connection requests through your firewall is to use ACCEPT
rules.</p>
</div>
<div align="left">
@ -1887,8 +1937,9 @@ I prefer to use NAT only in cases where a system that is part of an RFC
    If you haven't already, it would be a good idea to browse through
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a> just
to see if there is anything there that might be of interest. You might
also want to look at the other configuration files that you haven't touched
yet just to get a feel for the other things that Shorewall can do.</p>
also want to look at the other configuration files that you haven't
touched yet just to get a feel for the other things that Shorewall can
do.</p>
</div>
<div align="left">
@ -1939,10 +1990,10 @@ site-specific).</p>
<div align="left">
<p align="left">The setup described here requires that your network interfaces
be brought up before Shorewall can start. This opens a short window during
which you have no firewall protection. If you replace 'detect' with the
actual broadcast addresses in the entries above, you can bring up Shorewall
before you bring up your network interfaces.</p>
be brought up before Shorewall can start. This opens a short window
during which you have no firewall protection. If you replace 'detect'
with the actual broadcast addresses in the entries above, you can bring
up Shorewall before you bring up your network interfaces.</p>
</div>
<div align="left">
@ -2289,11 +2340,11 @@ DNS servers. You can combine the two into a single BIND 9 server using
<div align="left">
<p align="left">Suppose that your domain is foobar.net and you want the two
DMZ systems named www.foobar.net and mail.foobar.net and you want the
three local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net.
You want your firewall to be known as firewall.foobar.net externally
and it's interface to the local network to be know as gateway.foobar.net
three local systems named "winken.foobar.net, blinken.foobar.net and
nod.foobar.net. You want your firewall to be known as firewall.foobar.net
externally and it's interface to the local network to be know as gateway.foobar.net
and its interface to the dmz as dmz.foobar.net. Let's have the DNS server
on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
</div>
<div align="left">
@ -2307,7 +2358,7 @@ on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
</div>
<div align="left">
<pre>#<br># This is the view presented to our internal systems<br>#<br><br>view "internal" {<br> #<br> # These are the clients that see this view<br> #<br> match-clients { 192.168.201.0/29;<br> 192.168.202.0/29;<br> 127.0.0/24;<br> 192.0.2.176/32; <br> 192.0.2.178/32;<br> 192.0.2.179/32;<br> 192.0.2.180/32; };<br> #<br> # If this server can't complete the request, it should use outside<br> # servers to do so<br> #<br> recursion yes;<br><br> zone "." in {<br> type hint;<br> file "int/root.cache";<br> };<br><br> zone "foobar.net" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.foobar";<br> };<br><br> zone "0.0.127.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.127.0.0"; <br> };<br><br> zone "201.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.201";<br> };<br><br> zone "202.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.202";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.176";<br> };<br><br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.206.124.146.179";<br> };<br><br>};<br>#<br># This is the view that we present to the outside world<br>#<br>view "external" {<br> match-clients { any; };<br> #<br> # If we can't answer the query, we tell the client so<br> #<br> recursion no;<br><br> zone "foobar.net" in {<br> type master;<br> notify yes;<br> allow-update {none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "ext/db.foobar";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.176";<br> };<br><br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.179";<br> };<br>};</pre>
<pre>#<br># This is the view presented to our internal systems<br>#<br><br>view "internal" {<br> #<br> # These are the clients that see this view<br> #<br> match-clients { 192.168.201.0/29;<br> 192.168.202.0/29;<br> 127.0.0/24;<br> 192.0.2.176/32; <br> 192.0.2.178/32;<br> 192.0.2.179/32;<br> 192.0.2.180/32; };<br> #<br> # If this server can't complete the request, it should use outside<br> # servers to do so<br> #<br> recursion yes;<br><br> zone "." in {<br> type hint;<br> file "int/root.cache";<br> };<br><br> zone "foobar.net" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.foobar";<br> };<br><br> zone "0.0.127.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.127.0.0"; <br> };<br><br> zone "201.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.201";<br> };<br><br> zone "202.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.202";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.176";<br> };<br> (or status NAT for that matter)<br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.206.124.146.179";<br> };<br><br>};<br>#<br># This is the view that we present to the outside world<br>#<br>view "external" {<br> match-clients { any; };<br> #<br> # If we can't answer the query, we tell the client so<br> #<br> recursion no;<br><br> zone "foobar.net" in {<br> type master;<br> notify yes;<br> allow-update {none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "ext/db.foobar";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.176";<br> };<br><br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i>&lt;secondary NS IP&gt;</i>; };<br> file "db.192.0.2.179";<br> };<br>};</pre>
</div>
</blockquote>
</div>
@ -2430,26 +2481,28 @@ on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/routestopped file and configure those systems
that you want to be able to access the firewall when it is stopped.</p>
    Edit the /etc/shorewall/routestopped file and configure those
systems that you want to be able to access the firewall when it is stopped.</p>
</div>
<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
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="Documentation.htm#Configs">alternate configuration</a></i>
and test it using the <a href="Documentation.htm#Starting">"shorewall
try" command</a>.</p>
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 12/13/2002 - <a
<p align="left"><font size="2">Last updated 1/13/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>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>

327
STABLE/documentation/sourceforge_index.htm
View File

@ -13,7 +13,8 @@
<base target="_self">
<base
target="_self">
</head>
<body>
@ -35,14 +36,16 @@
<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.3 -
<font size="4">"<i>iptables made easy"</i></font></font><a
href="http://www.sf.net"> </a></h1>
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables made
easy"</i></font></font><a href="http://www.sf.net"> </a></h1>
@ -84,6 +87,7 @@
<h2 align="left">What is it?</h2>
@ -94,9 +98,10 @@
<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>
@ -107,24 +112,25 @@
<p>This program is free software; you can redistribute it and/or modify
it under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
Public License</a> as published by the Free Software Foundation.<br>
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,
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>
@ -135,7 +141,9 @@ Public License</a> as published by the Free Software Foundation.<br>
<p><a href="copyright.htm">Copyright 2001, 2002 Thomas M. Eastep</a></p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -149,16 +157,17 @@ Public License</a> as published by the Free Software Foundation.<br>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</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.10 and Kernel-2.4.18. 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.10 and Kernel-2.4.18.
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.0 Final!!! <br>
<b>Congratulations to Jacques and Eric on
the recent release of Bering 1.0 Final!!! <br>
</b>
<h2>News</h2>
@ -172,109 +181,242 @@ Public License</a> as published by the Free Software Foundation.<br>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<p><b>1/13/2003 - Shorewall 1.3.13</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
This version corrects a problem with Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL
was set to anything but ULOG, the firewall would fail to start and "shorewall
refresh" would also fail.<br>
<p>Just includes a few things that I had on the burner:<br>
</p>
<ol>
<li>A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules
file. DNAT- is intended for advanced users who wish to minimize the number
of rules that connection requests must traverse.<br>
<br>
A Shorewall DNAT rule actually generates two iptables rules: a header rewriting
rule in the 'nat' table and an ACCEPT rule in the 'filter' table. A DNAT-
rule only generates the first of these rules. This is handy when you have
several DNAT rules that would generate the same ACCEPT rule.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
<br>
   These three rules ended up generating _three_ copies of<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of the ACCEPT
rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
<br>
</li>
<li>The 'shorewall check' command now prints out the applicable policy
between each pair of zones.<br>
<br>
</li>
<li>A new CLEAR_TC option has been added to shorewall.conf. If this
option is set to 'No' then Shorewall won't clear the current traffic control
rules during [re]start. This setting is intended for use by people that prefer
to configure traffic shaping when the network interfaces come up rather than
when the firewall is started. If that is what you want to do, set TC_ENABLED=Yes
and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That way,
your traffic shaping rules can still use the 'fwmark' classifier based on
packet marking defined in /etc/shorewall/tcrules.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows distribution
packagers to easily move the shared directory (default /usr/lib/shorewall).
Users should never have a need to change the value of this shorewall.conf
setting.</li>
</ol>
<p><b>1/6/2003 - </b><b><big><big><big><big><big><big><big><big>B</big></big></big></big></big><small>U<small>R<small>N<small>O<small>U<small>T</small></small></small></small></small></small></big></big></big></b><b>
</b></p>
<p><b>Until further notice, I will not be involved in either Shorewall
Development or Shorewall Support</b></p>
<p><b>-Tom Eastep</b><br>
</p>
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b>
</b></p>
<p> Features include:<br>
</p>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after
an error occurs. This places the point of the failure near the end of
the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than
40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added
which shows the current packet classification filters. The output from
this command is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog
level and causes the subject packets to be logged using the ULOG target
rather than the LOG target. This allows you to run ulogd (available from
<a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain
in the mangle table ("shorewall show mangle" will show you the chains
in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
input packets based on their destination even when you are using Masquerading
or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with
empty 'init', 'start', 'stop' and 'stopped' files. If you already have
a file with one of these names, don't worry -- the upgrade process won't
overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable to <a
href="Documentation.htm#Conf">shorewall.conf</a>. This variable specifies
the syslog level at which packets are logged as a result of entries in
the /etc/shorewall/rfc1918 file. Previously, these packets were always
logged at the 'info' level.</li>
</ol>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
This version corrects a problem with Blacklist logging. In Beta
2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would
fail to start and "shorewall refresh" would also fail.<br>
<p> You may download the Beta from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is now available (Beta
1 was made available only to a limited audience). <br>
The first public Beta version of Shorewall 1.3.12 is now available
(Beta 1 was made available only to a limited audience). <br>
<br>
Features include:<br>
<br>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after
an error occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than 40%
with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added which
shows the current packet classification filters. The output from this command
is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog
level and causes the subject packets to be logged using the ULOG target rather
than the LOG target. This allows you to run ulogd (available from
<a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="configuration_file_basics.htm#Levels">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain in the
mangle table ("shorewall show mangle" will show you the chains in the mangle
table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows
for marking input packets based on their destination even when you are using
Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with empty
'init', 'start', 'stop' and 'stopped' files. If you already have a file with
one of these names, don't worry -- the upgrade process won't overwrite your
file.</li>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging
after an error occurs. This places the point of the failure near the
end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more
than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been
added which shows the current packet classification filters. The output
from this command is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid
syslog level and causes the subject packets to be logged using the ULOG
target rather than the LOG target. This allows you to run ulogd (available
from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain
in the mangle table ("shorewall show mangle" will show you the chains
in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf.
This allows for marking input packets based on their destination even
when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
won't overwrite your file.</li>
</ol>
You may download the Beta from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" width="150" height="23" border="0">
</a></b></p>
Shorewall is at the center of MandrakeSofts's recently-announced <a
Shorewall is at the center of MandrakeSofts's recently-announced
<a
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">Multi
Network Firewall (MNF)</a> product. Here is the <a
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
release</a>.<br>
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b><b>
</b></p>
<p>Two months and 3 days after I pre-ordered Mandrake 9.0, it was finally
delivered. I have installed 9.0 on one of my systems and I am now in a
position to support Shorewall users who run Mandrake 9.0.</p>
delivered. I have installed 9.0 on one of my systems and I am now
in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/6/2002 -  Debian 1.3.11a Packages Available</b><b></b><br>
</p>
<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users
who don't need rules of this type need not upgrade to 1.3.11.</p>
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11
users who don't need rules of this type need not upgrade to 1.3.11.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
@ -282,43 +424,50 @@ Masquerading or SNAT.</li>
</p>
<p><b>11/24/2002 - Shorewall 1.3.11</b><b>
</b></p>
<p>In this version:</p>
<ul>
<li>A 'tcpflags' option has been added to entries
in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
<li>A 'tcpflags' option has been added to
entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP packet
header flags.</li>
<li>It is now allowed to use 'all' in the SOURCE or
DEST column in a <a href="Documentation.htm#Rules">rule</a>. When
used, 'all' must appear by itself (in may not be qualified) and it does
not enable intra-zone traffic. For example, the rule <br>
header flags.</li>
<li>It is now allowed to use 'all' in the
SOURCE or DEST column in a <a href="Documentation.htm#Rules">rule</a>.
When used, 'all' must appear by itself (in may not be qualified)
and it does not enable intra-zone traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc' to 'loc'.</li>
<li>Shorewall's use of the 'echo' command is now compatible
with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate a startup error.
fw-&gt;fw rules generate a warning and are ignored</li>
<li>Shorewall's use of the 'echo' command
is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate a startup
error. fw-&gt;fw rules generate a warning and are ignored</li>
</ul>
<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
@ -326,20 +475,24 @@ used, 'all' must appear by itself (in may not be qualified) and it does
</p>
<p><b></b></p>
<ul>
</ul>
<p><b></b><a href="News.htm">More News</a></p>
@ -351,10 +504,12 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<h2> </h2>
<h1 align="center"><a href="http://www.sf.net"><img align="left"
alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
@ -362,21 +517,24 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<h4> </h4>
<h2>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </h2>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c" valign="top"
align="center"> <br>
<td width="88" bgcolor="#4b017c"
valign="top" align="center"> <br>
</td>
</tr>
@ -412,6 +570,7 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
@ -426,11 +585,12 @@ used, 'all' must appear by itself (in may not be qualified) and it does
<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>
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
@ -446,9 +606,10 @@ Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 12/22/2002 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 1/6/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
</body>
</html>

75
STABLE/documentation/starting_and_stopping_shorewall.htm
View File

@ -41,12 +41,12 @@
<p> If you have a permanent internet connection such as DSL or Cable,
I recommend that you start the firewall automatically at boot. Once
you have installed "firewall" in your init.d directory, simply type
"chkconfig --add firewall". This will start the firewall in run levels
2-5 and stop it in run levels 1 and 6. If you want to configure your
firewall differently from this default, you can use the "--level" option
in chkconfig (see "man chkconfig") or using your favorite graphical
run-level editor.</p>
you have installed "firewall" in your init.d directory, simply type
"chkconfig --add firewall". This will start the firewall in run
levels 2-5 and stop it in run levels 1 and 6. If you want to configure
your firewall differently from this default, you can use the "--level"
option in chkconfig (see "man chkconfig") or using your favorite
graphical run-level editor.</p>
@ -92,22 +92,27 @@ run-level editor.</p>
addresses of firewall interfaces and the black and white lists.</li>
</ul>
If you include the keyword <i>debug</i> as the first argument, then a shell
trace of the command is produced as in:<br>
<pre> <font color="#009900"><b>shorewall debug start 2&gt; /tmp/trace</b></font><br></pre>
<p>The above command would trace the 'start' command and place the trace
information in the file /tmp/trace</p>
<p> The "shorewall" program may also be used to monitor the firewall.</p>
<ul>
<li>shorewall status - produce a verbose report about the firewall
(iptables -L -n -v)</li>
<li>shorewall show <i>chain</i> - produce a verbose report about <i>chain
</i>(iptables -L <i>chain</i> -n -v)</li>
<li>shorewall show <i>chain</i> - produce a verbose report about
<i>chain </i>(iptables -L <i>chain</i> -n -v)</li>
<li>shorewall show nat - produce a verbose report about the nat table
(iptables -t nat -L -n -v)</li>
<li>shorewall show tos - produce a verbose report about the mangle
table (iptables -t mangle -L -n -v)</li>
table (iptables -t mangle -L -n -v)</li>
<li>shorewall show log - display the last 20 packet log entries.</li>
<li>shorewall show connections - displays the IP connections currently
being tracked by the firewall.</li>
@ -122,16 +127,17 @@ table (iptables -t mangle -L -n -v)</li>
packet log messages in the current /var/log/messages file.</li>
<li>shorewall version - Displays the installed version number.</li>
<li>shorewall check - Performs a <u>cursory</u> validation of
the zones, interfaces, hosts, rules and policy files. <font size="4"
color="#ff6666"><b>The "check" command does not parse and validate the
generated iptables commands so even though the "check" command completes
successfully, the configuration may fail to start. See the recommended
way to make configuration changes described below. </b></font> </li>
the zones, interfaces, hosts, rules and policy files. <font
size="4" color="#ff6666"><b>The "check" command does not parse and validate
the generated iptables commands so even though the "check" command
completes successfully, the configuration may fail to start. See the
recommended way to make configuration changes described below. </b></font>
</li>
<li>shorewall try<i> configuration-directory</i> [<i> timeout</i>
] - Restart shorewall using the specified configuration and if an error
occurs or if the<i> timeout </i> option is given and the new configuration
has been up for that many seconds then shorewall is restarted using the
standard configuration.</li>
has been up for that many seconds then shorewall is restarted using
the standard configuration.</li>
<li>shorewall deny, shorewall reject, shorewall accept and shorewall
save implement <a href="blacklisting_support.htm">dynamic blacklisting</a>.</li>
<li>shorewall logwatch (added in version 1.3.2) - Monitors the
@ -140,22 +146,22 @@ the zones, interfaces, hosts, rules and policy files. <font size="4"
</ul>
Finally, the "shorewall" program may be used to dynamically alter the contents
of a zone.<br>
of a zone.<br>
<ul>
<li>shorewall add <i>interface</i>[:<i>host]</i> <i>zone </i>- Adds the
specified interface (and host if included) to the specified zone.</li>
specified interface (and host if included) to the specified zone.</li>
<li>shorewall delete <i>interface</i>[:<i>host]</i> <i>zone </i>- Deletes
the specified interface (and host if included) from the specified zone.</li>
the specified interface (and host if included) from the specified zone.</li>
</ul>
<blockquote>Examples:<br>
<blockquote>shorewall add ipsec0:192.0.2.24 vpn1 -- adds the address 192.0.2.24
from interface ipsec0 to the zone vpn1<br>
shorewall delete ipsec0:192.0.2.24 vpn1 -- deletes the address 192.0.2.24
from interface ipsec0 from zone vpn1<br>
<blockquote><font color="#009900"><b>shorewall add ipsec0:192.0.2.24 vpn1</b></font>
-- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1<br>
<font color="#009900"><b> shorewall delete ipsec0:192.0.2.24 vpn1</b></font>
-- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1<br>
</blockquote>
</blockquote>
@ -175,8 +181,8 @@ from interface ipsec0 from zone vpn1<br>
<p> If a <i>configuration-directory</i> is specified, each time that Shorewall
is going to use a file in /etc/shorewall it will first look in the <i>configuration-directory</i>
. If the file is present in the <i>configuration-directory</i>, that
file will be used; otherwise, the file in /etc/shorewall will be used.</p>
. If the file is present in the <i>configuration-directory</i>, that file
will be used; otherwise, the file in /etc/shorewall will be used.</p>
@ -189,18 +195,18 @@ file will be used; otherwise, the file in /etc/shorewall will be used.</p>
<ul>
<li>mkdir /etc/test</li>
<li><font color="#009900"><b>mkdir /etc/test</b></font></li>
<li>cd /etc/test</li>
<li><font color="#009900"><b>cd /etc/test</b></font></li>
<li>&lt;copy any files that you need to change from /etc/shorewall
to . and change them here&gt;</li>
<li>shorewall -c . check</li>
<li><font color="#009900"><b>shorewall -c . check</b></font></li>
<li>&lt;correct any errors found by check and check again&gt;</li>
<li>/sbin/shorewall try .</li>
<li><font color="#009900"><b>/sbin/shorewall try .</b></font></li>
</ul>
@ -219,29 +225,30 @@ file will be used; otherwise, the file in /etc/shorewall will be used.</p>
<ul>
<li>cp * /etc/shorewall</li>
<li><font color="#009900"><b>cp * /etc/shorewall</b></font></li>
<li>cd</li>
<li><font color="#009900"><b>cd</b></font></li>
<li>rm -rf /etc/test</li>
<li><font color="#009900"><b>rm -rf /etc/test</b></font></li>
</ul>
<p><font size="2"> Updated 11/21/2002 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 1/9/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 Thomas M. Eastep.</font></a></font></p>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

309
STABLE/documentation/support.htm
View File

@ -30,6 +30,7 @@
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Support<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
@ -40,58 +41,55 @@
</tbody>
</table>
<p> <br>
<span style="font-weight: 400;"></span></p>
<p> <b><big><big><font color="#ff0000">Due to "Shorewall burnout", I am currently
not involved in either Shorewall development or Shorewall support. Nevertheless,
the mailing list is being ably manned by other Shorewall users.</font></big><span
style="font-weight: 400;"></span></big></b></p>
<h2><big><font color="#ff0000"><b>I don't look at problems sent to me directly
but I try to spend some amount of time each day responding to problems
posted on the Shorewall mailing list.</b></font></big></h2>
<h2 align="center"><big><font color="#ff0000"><b>-Tom</b></font></big></h2>
<h2 align="center"><big><font color="#ff0000"><b>-Tom Eastep</b></font></big></h2>
<h2>Before Reporting a Problem</h2>
<h3>T<b>here are a number of sources for problem solution information. Please
try these before you post.</b></h3>
There are a number of sources for problem
solution information. Please try these before you post.
<h3> </h3>
<h3> </h3>
<ul>
<li>
<h3><b>The <a href="FAQ.htm">FAQ</a> has solutions to more than 20 common
problems.</b></h3>
<li>More than half of the questions posted on the support list
have answers directly accessible from the <a
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a><br>
<br>
</li>
<li> The <a href="FAQ.htm">FAQ</a>
has solutions to more than 20 common problems. </li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>The <a href="troubleshoot.htm">Troubleshooting</a> Information
contains a number of tips to help you solve common problems.</b></h3>
</li>
<li> The <a
href="troubleshoot.htm">Troubleshooting</a> Information contains
a number of tips to help you solve common problems. </li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>The <a href="errata.htm"> Errata</a> has links to download
updated components.</b></h3>
</li>
<li> The <a
href="errata.htm"> Errata</a> has links to download updated
components. </li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>The Mailing List Archives search facility can locate posts
about similar problems:</b></h3>
<li> The Mailing List Archives
search facility can locate posts about similar problems:
</li>
</ul>
@ -102,6 +100,7 @@
<form method="post" action="http://www.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<select name="method">
@ -127,94 +126,172 @@
</select>
</font> <input type="hidden" name="config"
value="htdig"> <input type="hidden" name="restrict"
value="[http://www.shorewall.net/pipermail/.*]"> <input type="hidden"
value="[http://mail.shorewall.net/pipermail/.*]"> <input type="hidden"
name="exclude" value=""> <br>
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"> </p>
Search: <input type="text" size="30"
name="words" value=""> <input type="submit" value="Search"> </p>
</form>
<h2>Problem Reporting Guidelines</h2>
<i>"Let me see if I can translate your message into a real-world example. 
It would be like saying that you have three rooms at home, and when you
walk into one of the rooms, you detect this strange smell.  Can anyone tell
you what that strange smell is?<br>
<h2>Problem Reporting Guidelines </h2>
<i>"Let me see if I can translate your message into a real-world
example. It would be like saying that you have three rooms at home,
and when you walk into one of the rooms, you detect this strange smell.
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the smell and even
what's causing it.  You would be absolutely amazed at the range and variety
of smells we could come up with.  Even more amazing is that all of the explanations
for the smells would be completely plausible."<br>
Now, all of us could do some wonderful guessing as to the smell
and even what's causing it. You would be absolutely amazed at the range
and variety of smells we could come up with. Even more amazing is that
all of the explanations for the smells would be completely plausible."<br>
</i><br>
<div align="center">   - Russell Mosemann<br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
</div>
<br>
<h3> </h3>
<ul>
<li>
<h3><b>When reporting a problem, give as much information as you can.
Reports that say "I tried XYZ and it didn't work" are not at all helpful.</b></h3>
<li>Please remember we only know what is posted in your message. Do
not leave out any information that appears to be correct, or was mentioned
in a previous post. There have been countless posts by people who were
sure that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're asking for <strong>free</strong>
technical support. Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous practices
in writing and formatting your e-mail. Provide details that we need if
you expect good answers. <em>Exact quoting </em> of error messages, log
entries, command output, and other output is better than a paraphrase or
summary.<br>
<br>
</li>
<li> Please don't describe your environment
and then ask us to send you custom configuration files.
We're here to answer your questions but we can't do your
job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include this
information:</li>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall you are running.<br>
<br>
<b><font color="#009900">shorewall version</font><br>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version you are running<br>
<br>
<font color="#009900"><b>uname -a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip route show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized, the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses.<br>
<br>
</li>
</ul>
</ul>
<ul>
<li><b>NEVER </b>include the output of "<b><font color="#009900">iptables
-L</font></b>". Instead, please post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
</font></b>Since that command generates a lot of output, we suggest
that you redirect the output to a file and attach the file to your post<br>
<br>
<b><font color="#009900">/sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
<br>
</li>
<li>As a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address, netmask,
nameserver addresses, domain name, etc. These aren't secrets, and concealing
them often misleads us (and 80% of the time, a hacker could derive them
anyway from information contained in the SMTP headers of your post).<strong></strong></li>
</ul>
<ul>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>Please don't describe your environment and then ask us to send
you custom configuration files. We're here to answer your
questions but we can't do your job for you.</b></h3>
</li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>Do you see any "Shorewall" messages in /var/log/messages
when you exercise the function that is giving you problems?</b></h3>
<li> Do you see any "Shorewall"
messages ("<b><font color="#009900">/sbin/shorewall show log</font></b>")
when you exercise the function that is giving you problems? If
so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<br>
</li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>Have you looked at the packet flow with a tool like tcpdump
to try to understand what is going on?</b></h3>
</li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>Have you tried using the diagnostic capabilities of the
application that isn't working? For example, if "ssh" isn't able
to connect, using the "-v" option gives you a lot of valuable diagnostic
information.</b></h3>
</li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>Please include any of the Shorewall configuration files (especially
<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.</b></h3>
</li>
<li>
<h3><b>If an error occurs when you try to "shorewall start", include
a trace (See the <a href="troubleshoot.htm">Troubleshooting</a> section
for instructions).</b></h3>
</li>
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). </li>
</ul>
<h3> </h3>
<ul>
</ul>
<h3> </h3>
<ul>
<li> If an error occurs when
you try to "<font color="#009900"><b>shorewall start</b></font>",
include a trace (See the <a href="troubleshoot.htm">Troubleshooting</a>
section for instructions). </li>
</ul>
@ -223,41 +300,44 @@ for instructions).</b></h3>
<ul>
<li>
<h3><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></h3>
your network layout, etc. to the Mailing List -- your
post will be rejected.</b></h3>
</li>
</ul>
<h3> </h3>
The author gratefully acknowleges that the above list was heavily plagiarized
from the excellent LEAF document by <i>Ray</i> <em>Olszewski</em> found
at <a href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
<h2>Please post in plain text</h2>
<blockquote>
<h3><b> While the list server here at shorewall.net accepts and distributes
HTML posts, a growing number of MTAs serving list subscribers are rejecting
this HTML list traffic. At least one MTA has gone so far as to blacklist
shorewall.net "for continuous abuse"!!</b></h3>
<h3><b> I think that blocking all HTML is a rather draconian way to control
spam and that the unltimate loser here is not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. Nevertheless, all of you can
help by restricting your list posts to plain text.</b></h3>
<h3><b> And as a bonus, subscribers who use email clients like pine and
mutt will be able to read your plain text posts whereas they are most likely
simply ignoring your HTML posts.</b></h3>
<h3><b> A final bonus for the use of HTML is that it cuts down the size
of messages by a large percentage -- that is important when the same message
must be sent 500 times over the slow DSL line connecting the list server
to the internet.</b> </h3>
</blockquote>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<h3></h3>
<blockquote> </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>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi Network Firewall
(MNF) and you have not purchased an MNF license from MandrakeSoft then
you can post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@shorewall.net">Shorewall users mailing list.</a>
<b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@shorewall.net">Shorewall users mailing list.</a></p>
@ -265,23 +345,18 @@ to the internet.</b> </h3>
<p align="center"><big><font color="#ff0000"><b></b></font></big></p>
<p>To Subscribe to the mailing list go to <a
href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>
href="http://mail.shorewall.net/mailman/listinfo/shorewall-users">http://mail.shorewall.net/mailman/listinfo/shorewall-users</a>
.</p>
<p align="left"><font size="2">Last Updated 12/27/2002 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 1/9/2002 - 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 Thomas M. Eastep.</font></a></font><br>
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

117
STABLE/documentation/traffic_shaping.htm
View File

@ -38,46 +38,74 @@
<p align="left">Shorewall traffic shaping support consists of the following:</p>
<ul>
<li>A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic
Shaping also requires that you enable packet mangling.<br>
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in Shorewall
1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the setting of
this variable determines whether Shorewall clears the traffic shaping configuration
during Shorewall [re]start and Shorewall stop. <br>
</li>
<li>/etc/shorewall/tcrules - A file where you can specify firewall
marking of packets. The firewall mark value may be used to classify
packets for traffic shaping/control.<br>
<li><b>/etc/shorewall/tcrules</b> - A file where you can specify
firewall marking of packets. The firewall mark value may be used to
classify packets for traffic shaping/control.<br>
</li>
<li>/etc/shorewall/tcstart - A user-supplied file that is sourced
by Shorewall during "shorewall start" and which you can use to define
your traffic shaping disciplines and classes. I have provided a <a
href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a> that does
table-driven CBQ shaping but if you read the traffic shaping sections of
the HOWTO mentioned above, you can probably code your own faster than
you can learn how to use my sample. I personally use <a
href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below). HTB
support may eventually become an integral part of Shorewall since
HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you can
use to define your traffic shaping disciplines and classes. I have
provided a <a href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a>
that does table-driven CBQ shaping but if you read the traffic shaping
sections of the HOWTO mentioned above, you can probably code your
own faster than you can learn how to use my sample. I personally use
<a href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall since
HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the run_tc
function supplied by shorewall if you want tc errors to stop the firewall.<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
the firewall.<br>
<br>
You can generally use off-the-shelf traffic shaping scripts by simply copying
them to /etc/shorewall/tcstart. I use <a
You can generally use off-the-shelf traffic shaping scripts by simply
copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If you
use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
address the IP addresss of your firewall's external interface.<br>
</li>
<li>/etc/shorewall/tcclear - A user-supplied file that is sourced
by Shorewall when it is clearing traffic shaping. This file is normally
not required as Shorewall's method of clearing qdisc and filter definitions
is pretty general.</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file that
is sourced by Shorewall when it is clearing traffic shaping. This
file is normally not required as Shorewall's method of clearing qdisc
and filter definitions is pretty general.</li>
</ul>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic shaping
rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark packets
using entries in /etc/shorewall/tcrules.</li>
</ol>
To start traffic shaping when you bring up your network interfaces, you will
have to arrange for your traffic shaping configuration script to be run at
that time. How you do that is distribution dependent and will not be covered
here. You then should:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier, you
can mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
<h3 align="left">Kernel Configuration</h3>
@ -91,27 +119,28 @@ address the IP addresss of your firewall's external interface.<br>
<p align="left">The fwmark classifier provides a convenient way to classify
packets for traffic shaping. The /etc/shorewall/tcrules file provides
a means for specifying these marks in a tabular fashion.<br>
</p>
a means for specifying these marks in a tabular fashion.<br>
</p>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in case of
a match. This is an integer in the range 1-255.<br>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255.<br>
<br>
Example - 5<br>
</li>
<li>SOURCE - The source of the packet. If the packet originates
on the firewall, place "fw" in this column. Otherwise, this is a
comma-separated list of interface names, IP addresses, MAC addresses in
comma-separated list of interface names, IP addresses, MAC addresses in
<a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
@ -122,12 +151,12 @@ comma-separated list of interface names, IP addresses, MAC addresses in
IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/etc/protocol, a number or "all"<br>
/etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list of Port
names (from /etc/services), port numbers or port ranges (e.g., 21:22);
if the protocol is "icmp", this column is interpreted as the destination
icmp type(s).<br>
if the protocol is "icmp", this column is interpreted as the
destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client. If
omitted, any source port is acceptable. Specified as a comma-separate
@ -137,7 +166,7 @@ comma-separated list of interface names, IP addresses, MAC addresses in
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with 2.
All packets originating on the firewall itself should be marked with 3.</p>
All packets originating on the firewall itself should be marked with 3.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
@ -193,7 +222,7 @@ All packets originating on the firewall itself should be marked with 3.</p>
<p align="left">Example 2 - All GRE (protocol 47) packets not originating
on the firewall and destined for 155.186.235.151 should be marked with
12.</p>
12.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
@ -247,9 +276,9 @@ All packets originating on the firewall itself should be marked with 3.</p>
<p>While I am currently using the HTB version of <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (I just copied
wshaper.htb to /etc/shorewall/tcstart and modified it as shown in the Wondershaper
README), I have also run with the following set of hand-crafted rules in
my tcstart file:<br>
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown in
the Wondershaper README), I have also run with the following set of hand-crafted
rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<blockquote>
@ -284,10 +313,12 @@ can use all available bandwidth if there is no traffic from the local systems
</ol>
<p><font size="2">Last Updated 12/20/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last Updated 12/31/2002 - <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 Thomas M. Eastep.</font></a></font><br>
</p>
</p>
<br>
<br>
</body>
</html>

107
STABLE/documentation/troubleshoot.htm
View File

@ -41,50 +41,51 @@
problems.</p>
<h3 align="left">If the firewall fails to start</h3>
If you receive an error message when starting or restarting the
firewall and you can't determine the cause, then do the following:
If you receive an error message when starting or restarting
the firewall and you can't determine the cause, then do the following:
<ul>
<li>Make a note of the error message that you see.<br>
</li>
<li>shorewall debug start 2&gt; /tmp/trace</li>
<li>Look at the /tmp/trace file and see if that helps you
determine what the problem is. Be sure you find the place in the log where
the error message you saw is generated -- in 99.9% of the cases, it will
not be near the end of the log because after startup errors, Shorewall goes
through a "shorewall stop" phase which will also be traced.</li>
determine what the problem is. Be sure you find the place in the log
where the error message you saw is generated -- in 99.9% of the cases, it
will not be near the end of the log because after startup errors, Shorewall
goes through a "shorewall stop" phase which will also be traced.</li>
<li>If you still can't determine what's wrong then see the
<a href="support.htm">support page</a>.</li>
</ul>
Here's an example. During startup, a user sees the following:<br>
Here's an example. During startup, a user sees the following:<br>
<blockquote>
<pre>Adding Common Rules<br>iptables: No chain/target/match by that name<br>Terminated<br></pre>
</blockquote>
A search through the trace for "No chain/target/match by that name" turned
</blockquote>
A search through the trace for "No chain/target/match by that name" turned
up the following: 
<blockquote>
<pre>+ echo 'Adding Common Rules'<br>+ add_common_rules<br>+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ sed 's/!/! /g'<br>+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>iptables: No chain/target/match by that name<br></pre>
</blockquote>
The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with
</blockquote>
The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with
tcp-reset". In this case, the user had compiled his own kernel and had forgotten
to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
<h3>Your network environment</h3>
<p>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular snafus:
actually an ill-conceived network setup. Here are several popular snafus:
</p>
<ul>
<li>Port Forwarding where client and server are in the
same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Port Forwarding where client and server are in
the same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe that the system
is in the 'net' zone.</li>
<li>Multiple interfaces connected to the same HUB or Switch. Given
the way that the Linux kernel respond to ARP "who-has" requests, this
type of setup does NOT work the way that you expect it to.</li>
<li>Multiple interfaces connected to the same HUB or Switch.
Given the way that the Linux kernel respond to ARP "who-has" requests,
this type of setup does NOT work the way that you expect it to.</li>
</ul>
@ -92,9 +93,9 @@ to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
<p align="left">If the appropriate policy for the connection that you are
trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
TO MAKE IT WORK. Such additional rules will NEVER make it work, they add
clutter to your rule set and they represent a big security hole in the event
that you forget to remove them later.</p>
TO MAKE IT WORK. Such additional rules will NEVER make it work, they
add clutter to your rule set and they represent a big security hole in
the event that you forget to remove them later.</p>
<p align="left">I also recommend against setting all of your policies to
ACCEPT in an effort to make something work. That robs you of one of
@ -103,9 +104,9 @@ to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
by your rule set.</p>
<p align="left">Check your log ("/sbin/shorewall show log"). If you don't
see Shorewall messages, then your problem is probably NOT a Shorewall problem.
If you DO see packet messages, it may be an indication that you are missing
one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
see Shorewall messages, then your problem is probably NOT a Shorewall
problem. If you DO see packet messages, it may be an indication that you
are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<p align="left">While you are troubleshooting, it is a good idea to clear
two variables in /etc/shorewall/shorewall.conf:</p>
@ -128,8 +129,8 @@ LEN=47</font></p>
<ul>
<li>all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the "all"-&gt;"all" REJECT policy
(see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
chain -- the packet was rejected under the "all"-&gt;"all" REJECT
policy (see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
<li>IN=eth2 - the packet entered the firewall via eth2</li>
<li>OUT=eth1 - if accepted, the packet would be sent on eth1</li>
<li>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</li>
@ -149,19 +150,24 @@ LEN=47</font></p>
about how to interpret the chain name appearing in a Shorewall log message.<br>
</p>
<h3 align="left">'Ping' Problems?</h3>
Either can't ping when you think you should be able to or are able to ping
when you think that you shouldn't be allowed? Shorewall's 'Ping' Management<a
href="ping.html"> is described here</a>.<br>
<h3 align="left">Other Gotchas</h3>
<ul>
<li>Seeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that:
FORWARD chains? This means that:
<ol>
<li>your zone definitions are screwed up and the host that is
sending the packets or the destination host isn't in any zone (using
an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file
are you?); or</li>
<li>the source and destination hosts are both connected to the
same interface and that interface doesn't have the 'multi' option
specified in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>your zone definitions are screwed up and the host that
is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
file are you?); or</li>
<li>the source and destination hosts are both connected to
the same interface and that interface doesn't have the 'multi'
option specified in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
</ol>
</li>
@ -178,26 +184,26 @@ have the following in /etc/shorewall/nat:<br>
    10.1.1.2    eth0    130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type
8 between the zone containing the system you are pinging from and
the zone containing 10.1.1.2, the ping requests will be dropped. This
is true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.</li>
8 between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped. This is
true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.</li>
<li>If you specify "routefilter" for an interface, that interface
must be up prior to starting the firewall.</li>
<li>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect of
routing is that in order for two hosts to communicate, the routing between
them must be set up <u>in both directions.</u> So when setting up routing
between <b>A</b> and<b> B</b>, be sure to verify that the route from
<b>B</b> back to <b>A</b> is defined.</li>
of their nearest firewall interface. One often overlooked aspect
of routing is that in order for two hosts to communicate, the routing
between them must be set up <u>in both directions.</u> So when setting
up routing between <b>A</b> and<b> B</b>, be sure to verify that the
route from <b>B</b> back to <b>A</b> is defined.</li>
<li>Some versions of LRP (EigerStein2Beta for example) have a
shell with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected
shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a
href="kernel.htm">Click here to see my kernel configuration.</a> </li>
<li>Some features require the "ip" program. That program is
generally included in the "iproute" package which should be included
<li>Some features require the "ip" program. That program
is generally included in the "iproute" package which should be included
with your distribution (though many distributions don't install iproute
by default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
@ -205,8 +211,8 @@ is true even if you have NOT specified 'noping' for eth0 in /etc/shorewall
<li>If you have <u>any</u> entry for a zone in /etc/shorewall/hosts
then the zone must be entirely defined in /etc/shorewall/hosts unless
you have specified MERGE_HOSTS=Yes (Shorewall version 1.3.5 and later).
For example, if a zone has two interfaces but only one interface has
an entry in /etc/shorewall/hosts then hosts attached to the other interface
For example, if a zone has two interfaces but only one interface has an
entry in /etc/shorewall/hosts then hosts attached to the other interface
will <u>not</u> be considered part of the zone.</li>
<li>Problems with NAT? Be sure that you let Shorewall add all
external addresses to be use with NAT unless you have set <a
@ -216,19 +222,16 @@ an entry in /etc/shorewall/hosts then hosts attached to the other interface
<h3>Still Having Problems?</h3>
<p>See the<a href="support.htm"> support page.</a></p>
<p>See the<a href="support.htm"> support page.<br>
</a></p>
<font face="Century Gothic, Arial, Helvetica">
<blockquote> </blockquote>
</font>
<p><font size="2">Last updated 12/4/2002 - Tom Eastep</font> </p>
<p><font size="2">Last updated 1/7/2003 - Tom Eastep</font> </p>
<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><br>
</p>
<br>
<br>
<br>
<br>
</p>
</body>
</html>

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

@ -31,8 +31,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
@ -43,7 +43,7 @@
network.</li>
<li>Single public IP address.</li>
<li>Internet connection through cable modem, DSL, ISDN, Frame
Relay, dial-up ...</li>
Relay, dial-up ...</li>
</ul>
@ -61,32 +61,32 @@ Relay, dial-up ...</li>
<p>This guide assumes 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>
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>
<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"
changes. Points at which configuration changes are recommended are
flagged with <img border="0" src="images/BD21298_.gif" width="13"
height="13">
.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows 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>
    If you edit your configuration files on a Windows 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>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
of dos2unix</a></li>
</ul>
@ -95,8 +95,8 @@ Version of dos2unix</a></li>
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13"
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
/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
href="/pub/shorewall/LATEST.samples/two-interfaces.tgz">two-interface sample</a>,
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall
@ -107,8 +107,8 @@ few of these as described in this guide. After you have <a
and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the two-interface sample configuration, the following
zone names are used:</p>
set of <i>zones.</i> In the two-interface sample configuration, the
following zone names are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -154,8 +154,8 @@ zone to another zone in the<a href="Documentation.htm#Policy"> /etc/shorew
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;"
@ -197,7 +197,7 @@ the following policies:</p>
<blockquote>
<p>In the two-interface sample, the line below is included but commented
out. If you want your firewall system to have full access to servers
on the internet, uncomment that line.</p>
on the internet, uncomment that line.</p>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber3">
@ -226,8 +226,8 @@ on the internet, uncomment that line.</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>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>
@ -244,15 +244,15 @@ 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 Interface will
be a ppp interface (e.g., <b>ppp0</b>). If you connect via a regular modem,
your External Interface will also be <b>ppp0</b>. If you connect via ISDN,
your external interface will be <b>ippp0.</b></p>
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
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect via ISDN, your external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
@ -261,26 +261,26 @@ then you will want to set CLAMPMSS=yes in <a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
<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>
(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>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect the internal and external interface to the
same hub or switch (even for testing). It won't work the way that you think
that it will and you will end up confused and believing that Shorewall
doesn't work at all.</p>
</b></u>Do not connect the internal and external interface to
the same hub or switch (even for testing). It won't work the way that
you think that it will 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_.gif" align="left"
width="13" height="13">
    The Shorewall two-interface sample configuration assumes that
the external interface is <b>eth0</b> and the internal interface is
<b>eth1</b>. If your configuration is different, you will have to modify
the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
the external interface is <b>eth0</b> and the internal interface is <b>eth1</b>.
If your configuration is different, you will have to modify the sample
<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a> 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>
@ -290,7 +290,7 @@ of options that are specified for the interfaces. Some hints:</p>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the
option list. </p>
option list. </p>
</li>
</ul>
@ -298,17 +298,17 @@ option list. </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>
@ -328,9 +328,9 @@ 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, a subnet is
described using <a href="shorewall_setup_guide.htm#Subnets"><i>Classless
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 by "/24". The "24" refers to the number of consecutive
leading "1" bits from the left of the subnet mask. </p>
@ -390,8 +390,8 @@ be the IP address of the firewall's internal interface.<i>
</div>
<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:
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>
@ -408,23 +408,23 @@ be the IP address of the firewall's internal interface.<i>
<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 request
to an internet host, the firewall must perform <i>Network Address Translation
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; 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 across the internet so
the remote host can't address its response to computer 1). When the firewall
receives a return packet, it rewrites the destination address back to 10.10.10.1
and forwards the packet on to computer 1. </p>
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 across the
internet so the remote host can't address its response to computer 1).
When the firewall receives a return packet, it rewrites 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>
@ -434,8 +434,8 @@ receives a return packet, it rewrites the destination address back to 10.10.10
</li>
<li>
<p align="left"><i>SNAT</i> refers to the case when you explicitly specify
the source address that you want outbound packets from your local network
to use. </p>
the source address that you want outbound packets from your local
network to use. </p>
</li>
</ul>
@ -446,22 +446,24 @@ receives a return packet, it rewrites the destination address back to 10.10.10
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    If your external firewall interface is <b>eth0</b>, you do not
need to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq
and change the first column to the name of your external interface and
the second column to the name of your internal interface.</p>
    If your external firewall interface is <b>eth0</b>, you do
not need to modify the file provided with the sample. Otherwise, edit
/etc/shorewall/masq and change the first column to the name of your
external interface and the second column to the name of your internal
interface.</p>
<p align="left"><img border="0" src="images/BD21298_.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 your firewall
will work fine if you leave that column empty. Entering your static
IP in column 3 makes processing outgoing packets a little more efficient.<br>
will work fine if you leave that column empty. Entering your static IP
in column 3 makes processing outgoing packets a little more efficient.<br>
<br>
<img border="0" src="images/BD21298_.gif" width="13" height="13" alt="">
<img border="0" src="images/BD21298_.gif" width="13" height="13"
alt="">
    If you are using the Debian package, please check your shorewall.conf
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
</p>
<ul>
@ -475,12 +477,12 @@ them appropriately:<br>
<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>
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>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure port
@ -557,7 +559,7 @@ It is rather necessary for those clients to address their connection requests
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 the following
rule and try connecting to port 5000.</li>
rule and try connecting to port 5000.</li>
</ul>
@ -598,33 +600,34 @@ rules that you require.</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>
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>
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>
</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>
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>
@ -839,14 +842,14 @@ network to the firewall; you do that by adding the following rules in
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular application
uses, look <a href="ports.htm">here</a>.</p>
<p align="left">If you don't know what port and protocol a particular
application uses, look <a href="ports.htm">here</a>.</p>
</div>
<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">
@ -908,8 +911,8 @@ other connections as required.</p>
<div align="left">
<p align="left">The firewall is started using the "shorewall start" command
and stopped using "shorewall stop". When the firewall is stopped, routing
is enabled on those hosts that have an entry in <a
and stopped using "shorewall stop". When the firewall is stopped,
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
@ -920,7 +923,7 @@ other connections as required.</p>
<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 is stopped.
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>
@ -928,9 +931,9 @@ accordingly.</p>
<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
@ -952,5 +955,6 @@ accordingly.</p>
<br>
<br>
<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.3.12
VERSION=1.3.13
usage() # $1 = exit status
{

110
STABLE/firewall
View File

@ -70,7 +70,7 @@ list_count() {
#
# Mutual exclusion -- These functions are jackets for the mutual exclusion
# routines in /usr/lib/shorewall/functions. They invoke
# routines in $FUNCTIONS. They invoke
# the corresponding function in that file if the user did
# not specify "nolock" on the runline.
#
@ -833,6 +833,11 @@ validate_rule() {
target=ACCEPT
address=${address:=detect}
;;
DNAT-)
target=ACCEPT
address=${address:=detect}
logtarget=DNAT
;;
REDIRECT)
target=ACCEPT
address=${address:=all}
@ -983,6 +988,17 @@ validate_policy()
local zone1
local pc
local chain
local policy
local loglevel
local synparams
print_policy() # $1 = source zone, $2 = destination zone
{
[ $command != check ] || \
[ $1 = all ] || \
[ $2 = all ] || \
echo " Policy for $1 to $2 is $policy"
}
all_policy_chains=
@ -1048,27 +1064,34 @@ validate_policy()
for zone1 in $zones $FW all; do
eval pc=\$${zone}2${zone1}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${zone}2${zone1}_policychain=$chain
print_policy $zone $zone1
fi
done
done
else
for zone in $zones $FW all; do
eval pc=\$${zone}2${server}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${zone}2${server}_policychain=$chain
print_policy $zone $server
fi
done
fi
elif [ -n "$serverwild" ]; then
for zone in $zones $FW all; do
eval pc=\$${client}2${zone}_policychain
[ -n "$pc" ] || \
if [ -z "$pc" ]; then
eval ${client}2${zone}_policychain=$chain
print_policy $client $zone
fi
done
else
eval ${chain}_policychain=${chain}
print_policy $client $server
fi
done < $TMP_DIR/policy
@ -1234,7 +1257,7 @@ stop_firewall() {
[ -n "$NAT_ENABLED" ] && delete_nat
delete_proxy_arp
[ -n "$TC_ENABLED" ] && delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
setpolicy INPUT DROP
setpolicy OUTPUT DROP
@ -1344,12 +1367,18 @@ setup_tunnels() # $1 = name of tunnels file
run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options
else
run_iptables -A $inchain -p udp -s $1 --dport 500 $options
run_iptables -A $inchain -p udp -s $1 --dport 4500 $options
fi
for z in `separate_list $3`; do
if validate_zone $z; then
addrule ${FW}2${z} -p udp --sport 500 --dport 500 $options
if [ $2 = ipsec ]; then
addrule ${z}2${FW} -p udp --sport 500 --dport 500 $options
else
addrule ${z}2${FW} -p udp --dport 500 $options
addrule ${z}2${FW} -p udp --dport 4500 $options
fi
else
error_message "Warning: Invalid gateway zone ($z)" \
" -- Tunnel \"$tunnel\" may encounter keying problems"
@ -1820,6 +1849,7 @@ setup_tc() {
#
delete_tc()
{
clear_one_tc() {
tc qdisc del dev $1 root 2> /dev/null
tc qdisc del dev $1 ingress 2> /dev/null
@ -1846,7 +1876,7 @@ refresh_tc() {
echo "Refreshing Traffic Control Rules..."
delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
[ -n "$MARK_IN_FORWARD_CHAIN" ] && chain=tcfor || chain=tcpre
@ -2152,7 +2182,7 @@ add_a_rule()
add_nat_rule
fi
if [ $chain != ${FW}2${FW} ]; then
if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then
serv="${serv:+-d $serv}"
if [ -n "$loglevel" ]; then
@ -2229,14 +2259,23 @@ process_rule() # $1 = target
fi
logtarget="$target"
dnat_only=
# Convert 1.3 Rule formats to 1.2 format
[ "x$address" = "x-" ] && address=
case $target in
DNAT)
target=ACCEPT
address=${address:=detect}
;;
DNAT-)
target=ACCEPT
address=${address:=detect}
dnat_only=Yes
logtarget=DNAT
;;
REDIRECT)
target=ACCEPT
address=${address:=all}
@ -2379,7 +2418,7 @@ process_rules() # $1 = name of rules file
while read xtarget xclients xservers xprotocol xports xcports xaddress; do
case "$xtarget" in
ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT:*|REDIRECT|REDIRECT:*)
ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT-|DNAT:*|DNAT-:*|REDIRECT|REDIRECT:*)
expandv xclients xservers xprotocol xports xcports xaddress
if [ "x$xclients" = xall ]; then
@ -3233,7 +3272,7 @@ initialize_netfilter () {
run_iptables -t mangle -F && \
run_iptables -t mangle -X
[ -n "$TC_ENABLED" ] && delete_tc
[ -n "$CLEAR_TC" ] && delete_tc
run_user_exit init
@ -3267,7 +3306,7 @@ initialize_netfilter () {
run_user_exit newnotsyn
if [ -n "$LOGNEWNOTSYN" ]; then
if [ "$LOGNEWNOTSYN" = ULOG ]; then
run_iptables -A newnotsyn -j ULOG \
run_iptables -A newnotsyn -j ULOG
--ulog-prefix "Shorewall:newnotsyn:DROP:"
else
run_iptables -A newnotsyn -j LOG \
@ -4432,6 +4471,10 @@ do_initialize() {
TCP_FLAGS_LOG_LEVEL=
RFC1918_LOG_LEVEL=
MARK_IN_FORWARD_CHAIN=
SHARED_DIR=/usr/lib/shorewall
FUNCTIONS=
VERSION_FILE=
stopping=
have_mutex=
masq_seq=1
@ -4445,31 +4488,35 @@ do_initialize() {
trap "rm -rf $TMP_DIR; my_mutex_off; exit 2" 1 2 3 4 5 6 9
functions=/usr/lib/shorewall/functions
if [ -f $functions ]; then
. $functions
if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then
config=$SHOREWALL_DIR/shorewall.conf
else
startup_error "$functions does not exist!"
config=/etc/shorewall/shorewall.conf
fi
version_file=/usr/lib/shorewall/version
if [ -f $config ]; then
. $config
else
echo "$config does not exist!" >&2
exit 2
fi
[ -f $version_file ] && version=`cat $version_file`
#
# Strip the files that we use often
#
strip_file interfaces
strip_file hosts
FUNCTIONS=$SHARED_DIR/functions
run_user_exit shorewall.conf
run_user_exit params
if [ -f $FUNCTIONS ]; then
. $FUNCTIONS
else
startup_error "$FUNCTIONS does not exist!"
fi
VERSION_FILE=$SHARED_DIR/version
[ -f $VERSION_FILE ] && version=`cat $VERSION_FILE`
[ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall
[ -d $STATEDIR ] || mkdir -p $STATEDIR
[ -z "$FW" ] && FW=fw
ALLOWRELATED="`added_param_value_yes ALLOWRELATED $ALLOWRELATED`"
@ -4544,7 +4591,20 @@ do_initialize() {
[ -z "$RFC1918_LOG_LEVEL" ] && RFC1918_LOG_LEVEL=info
MARK_IN_FORWARD_CHAIN=`added_param_value_no MARK_IN_FORWARD_CHAIN $MARK_IN_FORWARD_CHAIN`
[ -n "$MARK_IN_FORWARD_CHAIN" ] && marking_chain=tcfor || marking_chain=tcpre
if [ -n "$TC_ENABLED" ]; then
CLEAR_TC=`added_param_value_yes CLEAR_TC $CLEAR_TC`
else
CLEAR_TC=
fi
run_user_exit params
#
# Strip the files that we use often
#
strip_file interfaces
strip_file hosts
}
#

2
STABLE/install.sh
View File

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

67
STABLE/releasenotes.txt
View File

@ -2,39 +2,48 @@ This is a minor release of Shorewall that has a couple of new features.
New features include:
1) "shorewall refresh" now reloads the traffic shaping rules (tcrules
and tcstart).
1) A new 'DNAT-' action has been added for entries in the
/etc/shorewall/rules file. DNAT- is intended for advanced users who
wish to minimize the number of rules that connection requests must
traverse.
2) "shorewall debug [re]start" now turns off debugging after an error
occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.
A Shorewall DNAT rule actually generates two iptables rules: a
header rewriting rule in the 'nat' table and an ACCEPT rule in the
'filter' table. A DNAT- rule only generates the first of these
rules. This is handy when you have several DNAT rules that would
generate the same ACCEPT rule.
3) "shorewall [re]start" has been speeded up by more than 40% with
my configuration. Your milage may vary.
Here are three rules from my previous rules file:
4) A "shorewall show classifiers" command has been added which shows
the current packet classification filters. The output from this
command is also added as a separate page in "shorewall monitor"
DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.178
DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.179
ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,...
5) ULOG (must be all caps) is now accepted as a valid syslog level and
causes the subject packets to be logged using the ULOG target rather
than the LOG target. This allows you to run ulogd (available from
www.gnumonks.org/projects/ulogd) and log all Shorewall messages to
a separate log file.
These three rules ended up generating _three_ copies of
6) If you are running a kernel that has a FORWARD chain in the mangle
table ("shorewall show mangle" will show you the chains in the
mangle table), you can set MARK_IN_FORWARD=Yes in
shorewall.conf. This allows for marking inbound packets based on
their destination even when you are using Masquerading or SNAT.
ACCEPT net dmz:206.124.146.177 tcp smtp
7) I have cluttered up the /etc/shorewall directory with empty 'init',
'start', 'stop' and 'stopped' files. If you already have a file with
one of these names, don't worry -- the upgrade process won't
overwrite your file.
By writing the rules this way, I end up with only one copy of the
ACCEPT rule.
8) I have added a new RFC1918_LOG_LEVEL variable to
shorewall.conf. This variable specifies the syslog level at which
packets are logged as a result of entries in the
/etc/shorewall/rfc1918 file. Previously, these packets were always
logged at the 'info' level.
DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.178
DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179
ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,...
2) The 'shorewall check' command now prints out the applicable policy
between each pair of zones.
3. A new CLEAR_TC option has been added to shorewall.conf. If this
option is set to 'No' then Shorewall won't clear the current
traffic control rules during [re]start. This setting is intended
for use by people that prefer to configure traffic shaping when
the network interfaces come up rather than when the firewall
is started. If that is what you want to do, set TC_ENABLED=Yes and
CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
way, your traffic shaping rules can still use the 'fwmark'
classifier based on packet marking defined in /etc/shorewall/tcrules.
4. A new SHARED_DIR variable has been added that allows distribution
packagers to easily move the shared directory (default
/usr/lib/shorewall). Users should never have a need to change the
value of this shorewall.conf setting.

4
STABLE/rules
View File

@ -24,6 +24,10 @@
# DNAT -- Forward the request to another
# system (and optionally another
# port).
# DNAT- -- Advanced users only.
# Like DNAT but only generates the
# DNAT iptables rule and not
# the companion ACCEPT rule.
# REDIRECT -- Redirect the request to a local
# port on the firewall.
#

56
STABLE/shorewall
View File

@ -569,51 +569,65 @@ fi
[ -n "$SHOREWALL_DIR" ] && export SHOREWALL_DIR
functions=/usr/lib/shorewall/functions
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHARED_DIR=/usr/lib/shorewall
MUTEX_TIMEOUT=
if [ -f $functions ]; then
. $functions
if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then
config=$SHOREWALL_DIR/shorewall.conf
else
echo "$functions does not exist!" >&2
config=/etc/shorewall/shorewall.conf
fi
if [ -f $config ]; then
. $config
else
echo "$config does not exist!" >&2
exit 2
fi
firewall=/usr/lib/shorewall/firewall
[ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall
if [ ! -f $firewall ]; then
FIREWALL=$SHARED_DIR/firewall
FUNCTIONS=$SHARED_DIR/functions
VERSION_FILE=$SHARED_DIR/version
if [ -f $FUNCTIONS ]; then
. $FUNCTIONS
else
echo "$FUNCTIONS does not exist!" >&2
exit 2
fi
if [ ! -f $FIREWALL ]; then
echo "ERROR: Shorewall is not properly installed"
if [ -L $firewall ]; then
echo " $firewall is a symbolic link to a"
if [ -L $FIREWALL ]; then
echo " $FIREWALL is a symbolic link to a"
echo " non-existant file"
else
echo " The file /usr/lib/shorewall/firewall does not exist"
echo " The file $FIREWALL does not exist"
fi
exit 2
fi
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
version_file=/usr/lib/shorewall/version
if [ -f $version_file ]; then
version=`cat $version_file`
if [ -f $VERSION_FILE ]; then
version=`cat $VERSION_FILE`
else
echo "ERROR: Shorewall is not properly installed"
echo " The file /usr/lib/shorewall/version does not exist"
echo " The file $VERSION_FILE does not exist"
exit 1
fi
banner="Shorewall-$version Status at $HOSTNAME -"
get_statedir
case `echo -e` in
-e*)
RING_BELL="echo \'\a\'"
RING_BELL="echo \a"
;;
*)
RING_BELL="echo -e \'\a\'"
RING_BELL="echo -e \a"
;;
esac
@ -629,11 +643,11 @@ esac
case "$1" in
start|stop|restart|reset|clear|refresh|check)
[ $# -ne 1 ] && usage 1
exec $firewall $debugging $nolock $1
exec $FIREWALL $debugging $nolock $1
;;
add|delete)
[ $# -ne 3 ] && usage 1
exec $firewall $debugging $nolock $1 $2 $3
exec $FIREWALL $debugging $nolock $1 $2 $3
;;
show)
[ $# -gt 2 ] && usage 1

7
STABLE/shorewall.conf
View File

@ -9,6 +9,13 @@
# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net)
##############################################################################
#
# You should not have to change the variables in this section -- they are set
# by the packager of your Shorewall distribution
#
SHARED_DIR=/usr/lib/shorewall
#
##############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.

4
STABLE/shorewall.spec
View File

@ -1,5 +1,5 @@
%define name shorewall
%define version 1.3.12
%define version 1.3.13
%define release 1
%define prefix /usr
@ -105,6 +105,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Mon Jan 13 2003 Tom Eastep <tom@shorewall.net>
- Changes version to 1.3.13
* Fri Dec 27 2002 Tom Eastep <tom@shorewall.net>
- Changes version to 1.3.12
* Sun Dec 22 2002 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.3.12
VERSION=1.3.13
usage() # $1 = exit status
{