From 36aa2c8e88de762ae50a682dc423e7d126363eab Mon Sep 17 00:00:00 2001 From: teastep Date: Sat, 28 Dec 2002 15:38:03 +0000 Subject: [PATCH] Release changes for 1.3.12 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@385 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Lrp/etc/init.d/shorewall | 853 ++- Lrp/etc/shorewall/init | 6 + Lrp/etc/shorewall/interfaces | 10 + Lrp/etc/shorewall/policy | 10 + Lrp/etc/shorewall/rfc1918 | 2 +- Lrp/etc/shorewall/rules | 41 +- Lrp/etc/shorewall/shorewall.conf | 91 + Lrp/etc/shorewall/start | 6 + Lrp/etc/shorewall/stop | 6 + Lrp/etc/shorewall/stopped | 6 + Lrp/etc/shorewall/tcrules | 5 + Lrp/sbin/shorewall | 181 +- Lrp/usr/lib/shorewall/functions | 19 +- Lrp/var/lib/lrpkg/shorwall.conf | 4 + Lrp/var/lib/lrpkg/shorwall.version | 2 +- STABLE/changelog.txt | 44 +- STABLE/documentation/Documentation.htm | 4831 +++++++++-------- STABLE/documentation/FAQ.htm | 1724 +++--- STABLE/documentation/MAC_Validation.html | 152 +- STABLE/documentation/News.htm | 2786 +++++----- STABLE/documentation/Shorewall_CA_html.html | 92 + .../documentation/Shorewall_index_frame.htm | 153 +- .../documentation/Shorewall_sfindex_frame.htm | 145 + STABLE/documentation/VPN.htm | 171 +- .../configuration_file_basics.htm | 613 ++- STABLE/documentation/download.htm | 551 +- STABLE/documentation/errata.htm | 959 ++-- STABLE/documentation/images/MDKlinux.jpg | Bin 0 -> 15401 bytes .../images/Vexira_Antivirus_Logo.gif | Bin 0 -> 2621 bytes STABLE/documentation/images/courier-imap.png | Bin 0 -> 2353 bytes STABLE/documentation/images/debian.jpg | Bin 0 -> 8442 bytes STABLE/documentation/images/logo2.png | Bin 0 -> 17550 bytes STABLE/documentation/images/medbutton.png | Bin 0 -> 11185 bytes STABLE/documentation/images/obrasinf.gif | Bin 0 -> 7298 bytes STABLE/documentation/mailing_list.htm | 253 +- .../documentation/mailing_list_problems.htm | 55 +- STABLE/documentation/ping.html | 90 + .../documentation/seattlefirewall_index.htm | 663 +-- STABLE/documentation/sfindex.htm | 22 + STABLE/documentation/shoreline.htm | 168 +- .../shorewall_extension_scripts.htm | 202 +- .../shorewall_quickstart_guide.htm | 374 +- .../documentation/shorewall_setup_guide.htm | 4028 +++++++------- STABLE/documentation/sourceforge_index.htm | 454 ++ STABLE/documentation/standalone.htm | 701 +-- STABLE/documentation/support.htm | 364 +- STABLE/documentation/three-interface.htm | 2011 +++---- STABLE/documentation/traffic_shaping.htm | 448 +- STABLE/documentation/troubleshoot.htm | 310 +- STABLE/documentation/two-interface.htm | 1535 +++--- STABLE/fallback.sh | 10 +- STABLE/firewall | 642 ++- STABLE/functions | 19 +- STABLE/init | 6 + STABLE/install.sh | 42 +- STABLE/policy | 6 + STABLE/releasenotes.txt | 41 +- STABLE/rules | 7 + STABLE/shorewall | 52 +- STABLE/shorewall.conf | 71 + STABLE/shorewall.spec | 15 +- STABLE/start | 6 + STABLE/stop | 6 + STABLE/stopped | 6 + STABLE/uninstall.sh | 2 +- Shorewall-docs/Documentation.htm | 4831 +++++++++-------- Shorewall-docs/FAQ.htm | 1679 +++--- Shorewall-docs/MAC_Validation.html | 152 +- Shorewall-docs/News.htm | 2562 +++++---- Shorewall-docs/Shorewall_index_frame.htm | 153 +- Shorewall-docs/Shorewall_sfindex_frame.htm | 163 +- Shorewall-docs/VPN.htm | 171 +- Shorewall-docs/configuration_file_basics.htm | 613 ++- Shorewall-docs/download.htm | 684 ++- Shorewall-docs/errata.htm | 687 +-- Shorewall-docs/images/MDKlinux.jpg | Bin 0 -> 15401 bytes Shorewall-docs/images/courier-imap.png | Bin 0 -> 2353 bytes Shorewall-docs/images/logo2.png | Bin 0 -> 17550 bytes Shorewall-docs/images/medbutton.png | Bin 0 -> 11185 bytes Shorewall-docs/images/obrasinf.gif | Bin 0 -> 7298 bytes Shorewall-docs/mailing_list.htm | 253 +- Shorewall-docs/mailing_list_problems.htm | 55 +- Shorewall-docs/ping.html | 90 + Shorewall-docs/seattlefirewall_index.htm | 708 ++- Shorewall-docs/shoreline.htm | 160 +- .../shorewall_extension_scripts.htm | 202 +- Shorewall-docs/shorewall_quickstart_guide.htm | 392 +- Shorewall-docs/shorewall_setup_guide.htm | 4028 +++++++------- Shorewall-docs/sourceforge_index.htm | 810 ++- Shorewall-docs/standalone.htm | 701 +-- Shorewall-docs/subnet_masks.htm | 78 - Shorewall-docs/support.htm | 364 +- Shorewall-docs/three-interface.htm | 2011 +++---- Shorewall-docs/traffic_shaping.htm | 448 +- Shorewall-docs/troubleshoot.htm | 323 +- Shorewall-docs/two-interface.htm | 1535 +++--- Shorewall/fallback.sh | 2 +- Shorewall/install.sh | 2 +- Shorewall/shorewall.spec | 4 +- Shorewall/uninstall.sh | 2 +- 100 files changed, 26957 insertions(+), 22978 deletions(-) create mode 100644 Lrp/etc/shorewall/init create mode 100644 Lrp/etc/shorewall/start create mode 100644 Lrp/etc/shorewall/stop create mode 100644 Lrp/etc/shorewall/stopped create mode 100644 STABLE/documentation/Shorewall_CA_html.html create mode 100644 STABLE/documentation/Shorewall_sfindex_frame.htm create mode 100644 STABLE/documentation/images/MDKlinux.jpg create mode 100644 STABLE/documentation/images/Vexira_Antivirus_Logo.gif create mode 100644 STABLE/documentation/images/courier-imap.png create mode 100644 STABLE/documentation/images/debian.jpg create mode 100644 STABLE/documentation/images/logo2.png create mode 100644 STABLE/documentation/images/medbutton.png create mode 100644 STABLE/documentation/images/obrasinf.gif create mode 100644 STABLE/documentation/ping.html create mode 100644 STABLE/documentation/sfindex.htm create mode 100644 STABLE/documentation/sourceforge_index.htm create mode 100644 STABLE/init create mode 100644 STABLE/start create mode 100644 STABLE/stop create mode 100644 STABLE/stopped create mode 100644 Shorewall-docs/images/MDKlinux.jpg create mode 100644 Shorewall-docs/images/courier-imap.png create mode 100644 Shorewall-docs/images/logo2.png create mode 100644 Shorewall-docs/images/medbutton.png create mode 100644 Shorewall-docs/images/obrasinf.gif create mode 100644 Shorewall-docs/ping.html delete mode 100644 Shorewall-docs/subnet_masks.htm diff --git a/Lrp/etc/init.d/shorewall b/Lrp/etc/init.d/shorewall index b44f429ae..fbbab24f3 100755 --- a/Lrp/etc/init.d/shorewall +++ b/Lrp/etc/init.d/shorewall @@ -61,9 +61,11 @@ list_search() # $1 = element to search for , $2-$n = list # Function to count list elements # list_count() { - local temp="`separate_list $1`" - - echo $temp | wc -w + arg_count() { + echo $# + } + + arg_count `separate_list $1` } # @@ -141,15 +143,53 @@ expandv() # $* = list of variable names done } +# +# Replace all leading "!" with "! " in the passed argument list +# + +fix_bang() { + local i; + + for i in $@; do + case $i in + !*) + echo "! ${i#!}" + ;; + *) + echo $i + ;; + esac + done +} + # # Run iptables and if an error occurs, stop the firewall and quit # run_iptables() { - if ! iptables `echo $@ | sed 's/!/! /g'`; then + + if ! iptables $@ ; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } +# +# Version of 'run_iptables' that inserts white space after "!" in the arg list +# +run_iptables2() { + + if [ "x${*%!*}" = "x$*" ]; then + # + # No "!" in the command -- just execute it + # + run_iptables $@ + return + fi + # + # Need to insert white space before each "!" + # + run_iptables `fix_bang $@` +} + # # Run ip and if an error occurs, stop the firewall and quit # @@ -187,8 +227,6 @@ run_tc() { # createchain() # $1 = chain name, $2 = If non-null, don't create default rules { - local target - run_iptables -N $1 if [ $# -eq 1 ]; then @@ -196,7 +234,7 @@ createchain() # $1 = chain name, $2 = If non-null, don't create default rules [ -n "$ALLOWRELATED" ] && state="$state,RELATED" run_iptables -A $1 -m state --state $state -j ACCEPT [ -z "$NEWNOTSYN" ] && \ - run_iptables -A $1 -m state --state NEW -p tcp !--syn -j newnotsyn + run_iptables -A $1 -m state --state NEW -p tcp ! --syn -j newnotsyn fi eval ${1}_exists=Yes @@ -214,6 +252,22 @@ havechain() # $1 = name of chain eval test \"\$${1}_exists\" = Yes } +# +# Query NetFilter about the existence of a filter chain +# +chain_exists() # $1 = chain name +{ + qt iptables -L $1 -n +} + +# +# Query NetFilter about the existence of a mangle chain +# +mangle_chain_exists() # $1 = chain name +{ + qt iptables -t mangle -L $1 -n +} + # # Ensure that a chain exists (create it if it doesn't) # @@ -270,7 +324,7 @@ ensurenatchain() # $1 = chain name addnatrule() # $1 = chain name, remainder of arguments specify the rule { ensurenatchain $1 - run_iptables -t nat -A $@ + run_iptables2 -t nat -A $@ } # @@ -281,6 +335,14 @@ deletechain() # $1 = name of chain qt iptables -L $1 -n && qt iptables -F $1 && qt iptables -X $1 } +# +# Determine if a chain is a policy chain +# +is_policy_chain() # $1 = name of chain +{ + eval test \"\$${1}_is_policy\" = Yes +} + # # Set a standard chain's policy # @@ -305,21 +367,6 @@ flushnat() # $1 = name of chain run_iptables -t nat -F $1 } -# -# Find interfaces to a given zone -# -# Read the interfaces file and for each record matching the passed ZONE, -# echo the expanded contents of the "INTERFACE" column -# -find_interfaces() # $1 = interface zone -{ - local zne=$1 - - while read z interface subnet options; do - [ "x`expand $z`" = "x$zne" ] && echo `expand $interface` - done < $TMP_DIR/interfaces -} - # # Chain name base for an interface # @@ -330,6 +377,25 @@ chain_base() #$1 = interface echo ${c:=common} } +# +# Find interfaces to a given zone +# +# Search the variables representing the contents of the interfaces file and +# for each record matching the passed ZONE, echo the expanded contents of +# the "INTERFACE" column +# +find_interfaces() # $1 = interface zone +{ + local zne=$1 + local z + local interface + + for interface in $all_interfaces; do + eval z=\$`chain_base ${interface}`_zone + [ "x${z}" = x${zne} ] && echo $interface + done +} + # # Forward Chain for an interface # @@ -346,16 +412,6 @@ input_chain() # $1 = interface echo `chain_base $1`_in } -# -# Input Chains (input and forward) for an interface -# -input_chains() # $1 = interface -{ - local base=`chain_base $1` - - echo ${base}_in ${base}_fwd -} - # # Output Chain for an interface # @@ -520,16 +576,30 @@ validate_interfaces_file() { while read z interface subnet options; do expandv z interface subnet options r="$z $interface $subnet $options" - [ "x$z" = "x-" ] || validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" + + [ "x$z" = "x-" ] && z= + + if [ -n "$z" ]; then + validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" + fi + + [ "x$interface" = "xlo" ] && \ + startup_error "Error: The loopback interface (lo) may not be defined in /etc/shorewall/interfaces" list_search $interface $all_interfaces && \ startup_error "Error: Duplicate Interface $interface" all_interfaces="$all_interfaces $interface" + options=`separate_list $options` + interface=`chain_base $interface` + + eval ${interface}_broadcast="$subnet" + eval ${interface}_zone="$z" + eval ${interface}_options=\"$options\" - for option in `separate_list $options`; do + for option in $options; do case $option in - dhcp|noping|filterping|routestopped|norfc1918|multi) + dhcp|noping|filterping|routestopped|norfc1918|multi|tcpflags) ;; routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) ;; @@ -644,7 +714,7 @@ validate_rule() { serv=$server ;; ~*) - fatal_error "Error: Rule \"$rule\" - Server may not be specified by MAC Address" + startup_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" ;; *) dest_interface="-o $server" @@ -803,7 +873,7 @@ validate_rule() { # Validate the Source Zone # if ! validate_zone $clientzone; then - startup_error "Error: Undefined Client Zone in rule \"$rule\"" + [ "x$clientzone" = xall ] || startup_error "Error: Undefined Client Zone in rule \"$rule\"" fi source=$clientzone @@ -835,10 +905,24 @@ validate_rule() { # Validate the destination zone # if ! validate_zone $serverzone; then - startup_error "Error: Undefined Server Zone in rule \"$rule\"" + [ "x$serverzone" = xall ] || startup_error "Error: Undefined Server Zone in rule \"$rule\"" fi dest=$serverzone + + chain=${source}2${dest} + + if [ "x$chain" = x${FW}2${FW} ]; then + case $logtarget in + REDIRECT) + ;; + *) + error_message "WARNING: fw -> fw rules are not supported; rule \"$rule\" ignored" + return + ;; + esac + fi + # # Check length of port lists if MULTIPORT set # @@ -893,12 +977,26 @@ validate_rules() # $1 = name of rules file # validate_policy() { + local clientwild + local serverwild + local zone + local zone1 + local pc + local chain + + all_policy_chains= + strip_file policy $policy while read client server policy loglevel synparams; do expandv client server policy loglevel synparams + + clientwild= + serverwild= + case "$client" in all|ALL) + clientwild=Yes ;; *) if ! validate_zone $client; then @@ -908,6 +1006,7 @@ validate_policy() case "$server" in all|ALL) + serverwild=Yes ;; *) if ! validate_zone $server; then @@ -923,6 +1022,55 @@ validate_policy() ;; esac + chain=${client}2${server} + + [ "x$chain" = "x${FW}2${FW}" ] && \ + startup_error "Error: fw->fw policy not allowed: $policy" + + if is_policy_chain $chain ; then + startup_error "Error: Duplicate policy $policy" + fi + + [ "x$loglevel" = "x-" ] && loglevel= + + chain=${client}2${server} + + all_policy_chains="$all_policy_chains $chain" + + eval ${chain}_is_policy=Yes + eval ${chain}_policy=$policy + eval ${chain}_loglevel=$loglevel + eval ${chain}_synparams=$synparams + + if [ -n "${clientwild}" ]; then + if [ -n "${serverwild}" ]; then + for zone in $zones $FW all; do + for zone1 in $zones $FW all; do + eval pc=\$${zone}2${zone1}_policychain + + [ -n "$pc" ] || \ + eval ${zone}2${zone1}_policychain=$chain + done + done + else + for zone in $zones $FW all; do + eval pc=\$${zone}2${server}_policychain + + [ -n "$pc" ] || \ + eval ${zone}2${server}_policychain=$chain + done + fi + elif [ -n "$serverwild" ]; then + for zone in $zones $FW all; do + eval pc=\$${client}2${zone}_policychain + + [ -n "$pc" ] || \ + eval ${client}2${zone}_policychain=$chain + done + else + eval ${chain}_policychain=${chain} + fi + done < $TMP_DIR/policy } @@ -930,8 +1078,9 @@ validate_policy() # Find broadcast addresses # find_broadcasts() { - while read z interface bcast options; do - expandv interface bcast + for interface in $all_interfaces; do + interface=`chain_base $interface` + eval bcast=\$${interface}_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then @@ -942,7 +1091,7 @@ find_broadcasts() { elif [ "x${bcast}" != "x-" ]; then echo `separate_list $bcast` fi - done < $TMP_DIR/interfaces + done } # @@ -950,23 +1099,19 @@ find_broadcasts() { # find_interface_broadcasts() # $1 = Interface name { - while read z interface bcast options; do - expandv interface bcast - if [ "$interface" = "$1" ]; then - if [ "x$bcast" = "xdetect" ]; then - addr="`ip addr show $interface 2> /dev/null`" - if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then - addr="`echo "$addr" | \ + eval bcast=\$${1}_broadcast + + if [ "x$bcast" = "xdetect" ]; then + addr="`ip addr show $interface 2> /dev/null`" + if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then + addr="`echo "$addr" | \ grep "inet " | sed 's/^.* inet.*brd //;s/scope.*//'`" - echo $addr | cut -d' ' -f 1 - fi - elif [ "x${bcast}" != "x-" ]; then - echo `separate_list $bcast` - fi - - return + echo $addr | cut -d' ' -f 1 fi - done < $TMP_DIR/interfaces + elif [ "x${bcast}" != "x-" ]; then + echo `separate_list $bcast` + fi + } # @@ -995,11 +1140,10 @@ find_interface_address() # $1 = interface # find_interfaces_by_option() # $1 = option { - while read ignore interface subnet options; do - expandv options - list_search $1 `separate_list $options` && \ - echo `expand $interface` - done < $TMP_DIR/interfaces + for interface in $all_interfaces; do + eval options=\$`chain_base ${interface}`_options + list_search $1 $options && echo $interface + done } # @@ -1013,11 +1157,11 @@ find_hosts_by_option() # $1 = option echo `expand $hosts` done < $TMP_DIR/hosts - while read ignore interface ignore1 options; do - expandv options - list_search $1 `separate_list $options` && \ - echo `expand $interface`:0.0.0.0/0 - done < $TMP_DIR/interfaces + for interface in $all_interfaces; do + eval options=\$`chain_base ${interface}`_options + list_search $1 $options && \ + echo ${interface}:0.0.0.0/0 + done } # @@ -1028,12 +1172,17 @@ find_hosts_by_option() # $1 = option have_interfaces_in_zone_with_option() # $1 = zone, $2 = option { local zne=$1 + local z + local interface - while read z interface broadcast options; do - [ "x`expand $z`" = "x$zne" ] && expandv options && \ - list_search $1 `separate_list $options` && \ + for interface in $all_interfaces; do + eval z=\$`chain_base ${interface}`_zone + + [ "x$z" = "x$zne" ] && \ + list_search $1 $options && \ return 0 - done < $TMP_DIR/interfaces + done + return 1 } @@ -1062,6 +1211,17 @@ run_user_exit() # $1 = file name # Stop the Firewall # stop_firewall() { + # + # Turn off trace unless we were tracing "stop" or "clear" + # + case $command in + stop|clear) + ;; + *) + set +x + ;; + esac + stopping="Yes" deletechain shorewall @@ -1108,7 +1268,6 @@ stop_firewall() { iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT - for interface in `find_interfaces_by_option dhcp`; do iptables -A INPUT -p udp -i $interface --dport 67:68 -j ACCEPT iptables -A OUTPUT -p udp -o $interface --dport 67:68 -j ACCEPT @@ -1211,6 +1370,7 @@ setup_tunnels() # $1 = name of tunnels file setup_pptp_client() # $1 = gateway { addrule $outchain -p 47 -d $1 -j ACCEPT + addrule $inchain -p 47 -j ACCEPT addrule $outchain -p tcp --dport 1723 -d $1 -j ACCEPT echo " PPTP tunnel to $1 defined." @@ -1218,8 +1378,9 @@ setup_tunnels() # $1 = name of tunnels file setup_pptp_server() { - addrule $inchain -p 47 -j ACCEPT - addrule $inchain -p tcp --dport 1723 -j ACCEPT + addrule $inchain -p 47 -j ACCEPT + addrule $outchain -p 47 -j ACCEPT + addrule $inchain -p tcp --dport 1723 -j ACCEPT echo " PPTP server defined." } @@ -1384,7 +1545,7 @@ setup_mac_lists() { run_iptables -A $chain $macpart -j RETURN else for address in `separate_list $addresses` ; do - run_iptables -A $chain $macpart -s $address -j RETURN + run_iptables2 -A $chain $macpart -s $address -j RETURN done fi done < $TMP_DIR/maclist @@ -1392,7 +1553,11 @@ setup_mac_lists() { # Setup Logging variables # if [ -n "$MACLIST_LOG_LEVEL" ]; then - logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" + if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then + logpart="-j ULOG $LOGPARMS --ulog-prefix" + else + logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" + fi else logpart= fi @@ -1437,7 +1602,7 @@ setup_mac_lists() { for hosts in $maclist_hosts; do interface=${hosts%:*} hosts=${hosts#*:} - for chain in `input_chains $interface` ; do + for chain in `first_chains $interface` ; do run_iptables -A $chain -s $hosts -m state --state NEW \ -j `mac_chain $interface` done @@ -1514,14 +1679,13 @@ setup_nat() { qt ip addr del $external dev $interface fi - if [ -z "$allints" -o "$allints" = "Yes" \ - -o "$allints" = "yes" ] + if [ -z "$allints" -o "$allints" = "Yes" -o "$allints" = "yes" ] then addnatrule nat_in -d $external -j DNAT --to-destination $internal addnatrule nat_out -s $internal -j SNAT --to-source $external if [ "$localnat" = "Yes" -o "$localnat" = "yes" ]; then - run_iptables -t nat -A OUTPUT -d $external \ + run_iptables2 -t nat -A OUTPUT -d $external \ -j DNAT --to-destination $internal fi else @@ -1559,13 +1723,14 @@ delete_nat() { } # -# Process a TC Rule +# Process a TC Rule - $marking_chain is assumed to contain the name of the +# marking chain # process_tc_rule() { add_a_tc_rule() { r= - chain=tcpre + chain=$marking_chain if [ "x$source" != "x-" ]; then case $source in @@ -1592,7 +1757,7 @@ process_tc_rule() [ "x$port" = "x-" ] || r="${r}--dport $port " [ "x$sport" = "x-" ] || r="${r}--sport $sport " - run_iptables -t mangle -A $chain $r -j MARK --set-mark $mark + run_iptables2 -t mangle -A $chain $r -j MARK --set-mark $mark } @@ -1612,14 +1777,12 @@ process_tc_rule() # # Setup queuing and classes # -setup_tc() { - - echo "Setting up Traffic Control Rules..." - +setup_tc1() { # # Create the TC mangle chains # - run_iptables -t mangle -N tcpre + + run_iptables -t mangle -N $marking_chain run_iptables -t mangle -N tcout # # Process the TC Rules File @@ -1634,13 +1797,24 @@ setup_tc() { # # Link to the TC mangle chains from the main chains # - run_iptables -t mangle -A PREROUTING -j tcpre - run_iptables -t mangle -A OUTPUT -j tcout + + if [ $marking_chain = tcfor ]; then + run_iptables -t mangle -A FORWARD -j tcfor + else + run_iptables -t mangle -A PREROUTING -j tcpre + fi run_user_exit tcstart } +setup_tc() { + + echo "Setting up Traffic Control Rules..." + + setup_tc1 +} + # # Clear Traffic Shaping # @@ -1665,6 +1839,42 @@ delete_tc() done } +# +# Refresh queuing and classes +# +refresh_tc() { + + echo "Refreshing Traffic Control Rules..." + + delete_tc + + [ -n "$MARK_IN_FORWARD_CHAIN" ] && chain=tcfor || chain=tcpre + + if mangle_chain_exists $chain; then + # + # Flush the TC mangle chains + # + run_iptables -t mangle -F $chain + + run_iptables -t mangle -F tcout + # + # Process the TC Rules File + # + strip_file tcrules + + while read mark sources dests proto ports sports; do + expandv mark sources dests proto ports sports + rule=`echo "$mark $sources $dests $proto $ports $sports"` + process_tc_rule + done < $TMP_DIR/tcrules + + run_user_exit tcstart + else + setup_tc1 + fi + +} + # # Add a NAT rule - Helper function for the rules file processor # @@ -1737,7 +1947,7 @@ add_nat_rule() { # Generate nat table rules if [ "$source" = "$FW" ]; then - run_iptables -t nat -A OUTPUT $proto $sports -d $addr \ + run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \ $multiport $dports -j $target1 else chain=`dnat_chain $source` @@ -1841,6 +2051,9 @@ add_a_rule() *.*.*) serv=$server ;; + ~*) + fatal_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" + ;; *) dest_interface="-o $server" serv= @@ -1939,28 +2152,48 @@ add_a_rule() add_nat_rule fi - serv="${serv:+-d $serv}" + if [ $chain != ${FW}2${FW} ]; then + serv="${serv:+-d $serv}" - [ -n "$loglevel" ] && run_iptables -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j LOG $LOGPARMS \ - --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel - run_iptables -A $chain $proto $multiport $state $cli $sports \ - $serv $dports -j $target + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j LOG $LOGPARMS \ + --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + + + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ + $serv $dports -j $target + fi else # Destination is a simple zone [ -n "$addr" ] && fatal_error \ - "Error: An ADDRESS ($addr) is only allowed in" \ + "Error: An ORIGINAL DESTINATION ($addr) is only allowed in" \ " a DNAT or REDIRECT: \"$rule\"" - [ -n "$loglevel" ] && run_iptables -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j LOG \ - $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel - - run_iptables -A $chain $proto $multiport $dest_interface $state \ + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j ULOG \ + $LOGPARMS --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j LOG \ + $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + + run_iptables2 -A $chain $proto $multiport $dest_interface $state \ $cli $sports $dports -j $target fi } @@ -1968,21 +2201,26 @@ add_a_rule() # # Process a record from the rules file # -# The caller has loaded the column contents from the record into the following -# variables: -# -# target clients servers protocol ports cports address -# -# and has loaded a space-separated list of their values in "rule". -# -# The 'multioption' variable has also been loaded appropriately to reflect -# the setting of the MULTIPORT option in /etc/shorewall/shorewall.conf -# -process_rule() { +process_rule() # $1 = target + # $2 = clients + # $3 = servers + # $4 = protocol + # $5 = ports + # $6 = cports + # $7 = address +{ + local target="$1" + local clients="$2" + local servers="$3" + local protocol="$4" + local ports="$5" + local cports="$6" + local address="$7" + local rule="`echo $target $clients $servers $protocol $ports $cports $address`" # Function Body -- isolate log level - if [ "$target" = "${target%:*}" ]; then + if [ "$target" = "${target%:*}" ]; then loglevel= else loglevel="${target#*:}" @@ -2070,8 +2308,22 @@ process_rule() { # Create canonical chain if necessary chain=${source}2${dest} + ensurechain $chain + if [ "x$chain" = x${FW}2${FW} ]; then + case $logtarget in + REDIRECT) + ;; + *) + error_message "WARNING: fw -> fw rules are not supported; rule \"$rule\" ignored" + return + ;; + esac + else + ensurechain $chain + fi + # Generate Netfilter rule(s) if [ -n "$MULTIPORT" -a \ @@ -2109,20 +2361,49 @@ process_rule() { # process_rules() # $1 = name of rules file { - strip_file rules + # + # Process a rule where the source or destination is "all" + # + process_wildcard_rule() { + for yclients in $xclients; do + for yservers in $xservers; do + if [ "${yclients}" != "${yservers}" ] ; then + process_rule $xtarget $yclients $yservers $xprotocol $xports $xcports $xaddress + fi + done + done + } - while read target clients servers protocol ports cports address; do - case "$target" in + strip_file rules $1 - ACCEPT*|DROP*|REJECT*|DNAT*|REDIRECT*) - expandv clients servers protocol ports cports address - rule="`echo $target $clients $servers $protocol $ports $cports $address`" - process_rule - ;; - *) - rule="`echo $target $clients $servers $protocol $ports $cports $address`" - fatal_error "Error: Invalid Target in rule \"$rule\"" - ;; + while read xtarget xclients xservers xprotocol xports xcports xaddress; do + case "$xtarget" in + + ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT:*|REDIRECT|REDIRECT:*) + expandv xclients xservers xprotocol xports xcports xaddress + + if [ "x$xclients" = xall ]; then + xclients="$zones $FW" + if [ "x$xservers" = xall ]; then + xservers="$zones $FW" + fi + process_wildcard_rule + continue + fi + + if [ "x$xservers" = xall ]; then + xservers="$zones $FW" + process_wildcard_rule + continue + fi + + process_rule $xtarget $xclients $xservers $xprotocol $xports $xcports $xaddress + ;; + *) + rule="`echo $xtarget $xclients $xservers $xprotocol $xports $xcports $xaddress`" + fatal_error "Error: Invalid Target in rule \"$rule\"" + ;; + esac done < $TMP_DIR/rules } @@ -2263,24 +2544,24 @@ process_tos_rule() { case $srczone in $FW) - run_iptables -t mangle -A outtos \ + run_iptables2 -t mangle -A outtos \ $protocol $dest $dports $sports $tos ;; all|ALL) - run_iptables -t mangle -A outtos \ + run_iptables2 -t mangle -A outtos \ $protocol $dest $dports $sports $tos - run_iptables -t mangle -A pretos \ + run_iptables2 -t mangle -A pretos \ $protocol $dest $dports $sports $tos ;; *) if [ -n "$src" ]; then - run_iptables -t mangle -A pretos $src \ + run_iptables2 -t mangle -A pretos $src \ $protocol $dest $dports $sports $tos else eval interfaces=\$${srczone}_interfaces for interface in $interfaces; do - run_iptables -t mangle -A pretos -i $interface \ + run_iptables2 -t mangle -A pretos -i $interface \ $protocol $dest $dports $sports $tos done fi @@ -2390,8 +2671,16 @@ policy_rules() # $1 = chain to add rules to esac - [ $# -eq 3 ] && [ "x${3}" != "x-" ] && run_iptables -A $1 -j LOG $LOGPARMS \ - --log-prefix "Shorewall:${1}:${2}:" --log-level $3 + if [ $# -eq 3 -a "x${3}" != "x-" ]; then + if [ "$3" = ULOG ]; then + run_iptables -A $1 -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:${1}:${2}:" + else + run_iptables -A $1 -j LOG $LOGPARMS \ + --log-prefix "Shorewall:${1}:${2}:" --log-level $3 + fi + fi + [ -n "$target" ] && run_iptables -A $1 -j $target } @@ -2423,13 +2712,15 @@ default_policy() # $1 = client $2 = server apply_default() { + # + # Generate policy file column values from the policy chain + # + eval policy=\$${chain1}_policy + eval loglevel=\$${chain1}_loglevel + eval synparams=\$${chain1}_synparams # # Add the appropriate rules to the canonical chain ($chain) to enforce # the specified policy - # - # Construct policy chain name - # - chain1=${client}2${server} if [ "$chain" = "$chain1" ]; then # @@ -2483,27 +2774,13 @@ default_policy() # $1 = client $2 = server echo " Policy $policy for $1 to $2 using chain $chain" } - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - case "$client" in - all|ALL) - if [ "$server" = "$2" -o "$server" = "all" ]; then - apply_default $1 $2 - return - fi - ;; - *) - if [ "$client" = "$1" ] && \ - [ "$server" = "all" -o "$server" = "$2" ] - then - apply_default $1 $2 - return - fi - ;; - esac - done < $TMP_DIR/policy + eval chain1=\$${1}2${2}_policychain - fatal_error "Error: No default policy for zone $1 to zone $2" + if [ -n "$chain1" ]; then + apply_default $1 $2 + else + fatal_error "Error: No default policy for zone $1 to zone $2" + fi } # @@ -2519,33 +2796,20 @@ complete_standard_chain() # $1 = chain, $2 = source zone, $3 = destination zone { local policy= local loglevel= + local policychain= run_user_exit $1 + + eval policychain=\$${2}2${3}_policychain - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - - [ "x$loglevel" = "x-" ] && loglevel= + if [ -n "$policychain" ]; then + eval policy=\$${policychain}_policy + eval loglevel=\$${policychain}_loglevel - case "$client" in - all|ALL) - if [ "$server" = "$3" -o "$server" = "all" ]; then - policy_rules $1 $policy $loglevel - return - fi - ;; - *) - if [ "$client" = "$2" ] && \ - [ "$server" = "all" -o "$server" = "$3" ] - then - policy_rules $1 $policy $loglevel - return - fi - ;; - esac - done < $TMP_DIR/policy - - policy_rules $1 DROP INFO + policy_rules $1 $policy $loglevel + else + policy_rules $1 DROP INFO + fi } # @@ -2560,24 +2824,10 @@ rules_chain() # $1 = source zone, $2 = destination zone local chain=${1}2${2} havechain $chain && { echo $chain; return; } + + eval chain=\$${chain}_policychain - while read client server policy loglevel ; do - expandv client server policy loglevel - case "$client" in - all|ALL) - if [ "$server" = "$2" -o "$server" = "all" ]; then - echo all2${server} - return - fi - ;; - *) - if [ "$client" = "$1" -a "$server" = "all" ]; then - echo ${client}2${server} - return - fi - ;; - esac - done < $TMP_DIR/policy + [ -n "$chain" ] && { echo $chain; return; } fatal_error "Error: No appropriate chain for zone $1 to zone $2" } @@ -2649,7 +2899,7 @@ setup_masq() if [ -n "$nomasq" ]; then newchain=masq${masq_seq} - run_iptables -t nat -N $newchain + createnatchain $newchain addnatrule $chain -d $destnet $iface $subnet -j $newchain masq_seq=$(($masq_seq + 1)) chain=$newchain @@ -2709,12 +2959,20 @@ setup_intrazone() # $1 = zone # $dport = destination port selector # add_blacklist_rule() { - [ -n "$BLACKLIST_LOGLEVEL" ] && \ - run_iptables -A blacklst $source $proto $dport -j \ - LOG $LOGPARMS --log-prefix \ - "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" \ - --log-level $BLACKLIST_LOGLEVEL - run_iptables -A blacklst $source $proto $dport -j $disposition + if [ -n "$BLACKLIST_LOGLEVEL" ]; then + if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then + run_iptables2 -A blacklst $source $proto $dport -j \ + ULOG $LOGPARMS --ulog-prefix \ + "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" + else + run_iptables2 -A blacklst $source $proto $dport -j \ + LOG $LOGPARMS --log-prefix \ + "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" \ + --log-level $BLACKLIST_LOGLEVEL + fi + fi + + run_iptables2 -A blacklst $source $proto $dport -j $disposition } # @@ -3007,9 +3265,16 @@ initialize_netfilter () { if [ -z "$NEWNOTSYN" ]; then createchain newnotsyn no run_user_exit newnotsyn - [ -n "$LOGNEWNOTSYN" ] && \ - run_iptables -A newnotsyn -j LOG \ - --log-prefix "Shorewall:newnotsyn:DROP:" --log-level $LOGNEWNOTSYN + if [ -n "$LOGNEWNOTSYN" ]; then + if [ "$LOGNEWNOTSYN" = ULOG ]; then + run_iptables -A newnotsyn -j ULOG \ + --ulog-prefix "Shorewall:newnotsyn:DROP:" + else + run_iptables -A newnotsyn -j LOG \ + --log-prefix "Shorewall:newnotsyn:DROP:" --log-level $LOGNEWNOTSYN + fi + fi + run_iptables -A newnotsyn -j DROP fi @@ -3024,7 +3289,7 @@ initialize_netfilter () { while read target ignore1 ignore2 address rest; do case $target in DROP|reject) - run_iptables -A dynamic -s $address -j $target + run_iptables2 -A dynamic -s $address -j $target ;; *) ;; @@ -3084,7 +3349,11 @@ build_common_chain() { add_common_rules() { logdisp() # $1 = Chain Name { - echo "LOG --log-prefix "Shorewall:${1}:DROP:" --log-level info" + if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then + echo "ULOG --ulog-prefix Shorewall:${1}:DROP:" + else + echo "LOG --log-prefix Shorewall:${1}:DROP: --log-level info" + fi } # # Reject Rules @@ -3100,10 +3369,16 @@ add_common_rules() { createchain badpkt no if [ -n "$LOGUNCLEAN" ]; then - logoptions="$LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - run_iptables -A badpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A badpkt -p ! tcp -j LOG $logoptions + if [ "$LOGUNCLEAN" = ULOG ]; then + logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:badpkt:DROP:" + logoptions="$logoptions --log-ip-options" + else + logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" + logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" + fi + + run_iptables -A badpkt -p tcp $logoptions --log-tcp-options + run_iptables -A badpkt -p ! tcp $logoptions fi run_iptables -A badpkt -j DROP @@ -3125,10 +3400,17 @@ add_common_rules() { createchain logpkt no [ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info - logoptions="$LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - run_iptables -A logpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A logpkt -p ! tcp -j LOG $logoptions + + if [ "$LOGUNCLEAN" = ULOG ]; then + logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:logpkt:LOG:" + logoptions="$logoptions --log-ip-options" + else + logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" + logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" + fi + + run_iptables -A logpkt -p tcp $logoptions --log-tcp-options + run_iptables -A logpkt -p ! tcp $logoptions echo "Mangled/Invalid Packet Logging enabled on:" @@ -3191,13 +3473,13 @@ add_common_rules() { ;; esac - run_iptables -A rfc1918 -s $subnet -j $target + run_iptables2 -A rfc1918 -s $subnet -j $target # # If packet mangling is enabled, trap packets with an # RFC1918 destination # if [ -n "$MANGLE_ENABLED" ]; then - run_iptables -t mangle -A man1918 -d $subnet -j $target + run_iptables2 -t mangle -A man1918 -d $subnet -j $target fi done < $TMP_DIR/rfc1918 @@ -3211,6 +3493,58 @@ add_common_rules() { done fi + + interfaces=`find_interfaces_by_option tcpflags` + + if [ -n "$interfaces" ]; then + echo "Setting up TCP Flags checking..." + + createchain tcpflags no + + if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then + createchain logflags no + + if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then + run_iptables -A logflags -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:logflags:$TCP_FLAGS_DISPOSITION:" \ + --log-tcp-options --log-ip-options + else + run_iptables -A logflags -j LOG $LOGPARMS \ + --log-level $TCP_FLAGS_LOG_LEVEL \ + --log-prefix "Shorewall:logflags:$TCP_FLAGS_DISPOSITION:" \ + --log-tcp-options --log-ip-options + fi + case $TCP_FLAGS_DISPOSITION in + REJECT) + run_iptables -A logflags -j REJECT --reject-with tcp-reset + ;; + *) + run_iptables -A logflags -j $TCP_FLAGS_DISPOSITION + ;; + esac + + disposition="-j logflags" + else + disposition="-j $TCP_FLAGS_DISPOSITION" + fi + + run_iptables -A tcpflags -p tcp --tcp-flags ALL FIN,URG,PSH $disposition + run_iptables -A tcpflags -p tcp --tcp-flags ALL NONE $disposition + run_iptables -A tcpflags -p tcp --tcp-flags SYN,RST SYN,RST $disposition + run_iptables -A tcpflags -p tcp --tcp-flags SYN,FIN SYN,FIN $disposition + # + # There are a lot of probes to ports 80, 3128 and 8080 that use a source + # port of 0. This catches them even if they are directed at an IP that + # hosts a web server. + # + run_iptables -A tcpflags -p tcp --syn --sport 0 $disposition + + for interface in $interfaces; do + for chain in `first_chains $interface`; do + run_iptables -A $chain -p tcp -j tcpflags + done + done + fi # # Process Black List # @@ -3225,7 +3559,7 @@ add_common_rules() { # # Enable icmp output # - run_iptables -A OUTPUT -m state --state ! INVALID -p icmp -j ACCEPT + run_iptables -A OUTPUT -p icmp -j ACCEPT # # Route Filtering # @@ -3277,10 +3611,10 @@ apply_policy_rules() { # # Create policy chains # - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - - chain=${client}2${server} + for chain in $all_policy_chains; do + eval policy=\$${chain}_policy + eval loglevel=\$${chain}_loglevel + eval synparams=\$${chain}_synparams [ -n "$synparams" ] && setup_syn_flood_chain $chain $synparams @@ -3289,7 +3623,7 @@ apply_policy_rules() { run_iptables -I $chain 2 -p tcp --syn -j @$chain else # - # A wild-card rule. Create the chain and add policy + # The chain doesn't exist. Create the chain and add policy # rules # # We must include the ESTABLISHED and RELATED state @@ -3299,15 +3633,25 @@ apply_policy_rules() { # createchain $chain - [ "$client" = "all" -o "$server" = "all" ] && \ - policy_rules $chain $policy $loglevel + # + # If either client or server is 'all' then this MUST be + # a policy chain and we must apply the appropriate policy rules + # + # Otherwise, this is a canonical chain which will be handled in + # the for loop below + # + case $chain in + all2*|*2all) + policy_rules $chain $policy $loglevel + ;; + esac [ -n "$synparams" ] && \ [ $policy = ACCEPT -o $policy = CONTINUE ] && \ run_iptables -I $chain 2 -p tcp --syn -j @$chain fi - done < $TMP_DIR/policy + done # # Add policy rules to canonical chains # @@ -3632,6 +3976,8 @@ refresh_firewall() determine_zones + validate_interfaces_file + [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" determine_interfaces @@ -3649,19 +3995,16 @@ refresh_firewall() # refresh_blacklist + # + # Refresh Traffic Control + # + [ -n "$TC_ENABLED" ] && refresh_tc + report "Shorewall Refreshed" rm -rf $TMP_DIR } -# -# Query NetFilter about the existence of a filter chain -# -chain_exists() # $1 = chain name -{ - qt iptables -L $1 -n -} - # # Add a host or subnet to a zone # @@ -3723,6 +4066,7 @@ add_to_zone() # $1 = [:] $2 = zone blacklist_interfaces=`find_interfaces_by_option blacklist` filterping_interfaces=`find_interfaces_by_option filterping` maclist_interfaces=`find_interfaces_by_maclist` + tcpflags_interfaces=`find_interfaces_by_option tcpflags` # # Normalize the first argument to this function # @@ -3786,6 +4130,10 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=$(($rulenum + 1)) fi + if ! list_search $interface $tcpflags_interfaces; then + rulenum=$(($rulenum + 1)) + fi + do_iptables -I `input_chain $interface` $rulenum -s $host -j $chain else # @@ -3810,6 +4158,10 @@ add_to_zone() # $1 = [:] $2 = zone if ! list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi + + if ! list_search $interface $tcpflags_interfaces; then + rulenum=$(($rulenum + 1)) + fi fi for h in $dest_hosts; do @@ -4076,6 +4428,10 @@ do_initialize() { FORWARDPING= MACLIST_DISPOSITION= MACLIST_LOG_LEVEL= + TCP_FLAGS_DISPOSITION= + TCP_FLAGS_LOG_LEVEL= + RFC1918_LOG_LEVEL= + MARK_IN_FORWARD_CHAIN= stopping= have_mutex= masq_seq=1 @@ -4173,6 +4529,22 @@ do_initialize() { MACLIST_DISPOSITION=REJECT fi + if [ -n "$TCP_FLAGS_DISPOSITION" ] ; then + case $TCP_FLAGS_DISPOSITION in + REJECT|ACCEPT|DROP) + ;; + *) + startup_error "Invalid value ($TCP_FLAGS_DISPOSITION) for TCP_FLAGS_DISPOSITION" + ;; + esac + else + TCP_FLAGS_DISPOSITION=DROP + fi + + [ -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 + } # @@ -4244,7 +4616,8 @@ case "$command" in status) [ $# -ne 1 ] && usage - echo -e "Shorewall-$version Status at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Status at $HOSTNAME - `date`" + echo iptables -L -n -v ;; diff --git a/Lrp/etc/shorewall/init b/Lrp/etc/shorewall/init new file mode 100644 index 000000000..d7bee1d0a --- /dev/null +++ b/Lrp/etc/shorewall/init @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/init +# +# Add commands below that you want to be executed at the beginning of +# a "shorewall start" or "shorewall restart" command. +# diff --git a/Lrp/etc/shorewall/interfaces b/Lrp/etc/shorewall/interfaces index 8be1de806..595d49581 100644 --- a/Lrp/etc/shorewall/interfaces +++ b/Lrp/etc/shorewall/interfaces @@ -20,6 +20,8 @@ # an alias (e.g., eth0:0) here; see # http://www.shorewall.net/FAQ.htm#faq18 # +# DO NOT DEFINE THE LOOPBACK INTERFACE (lo) IN THIS FILE. +# # BROADCAST The broadcast address for the subnetwork to which the # interface belongs. For P-T-P interfaces, this # column is left black.If the interface has multiple @@ -89,6 +91,14 @@ # is specified, the interface must be # an ethernet NIC and must be up before # Shorewall is started. +# tcpflags - Packets arriving on this interface are +# checked for certain illegal combinations +# of TCP flags. Packets found to have +# such a combination of flags are handled +# according to the setting of +# TCP_FLAGS_DISPOSITION after having been +# logged according to the setting of +# TCP_FLAGS_LOG_LEVEL. # proxyarp - # Sets # /proc/sys/net/ipv4/conf//proxy_arp. diff --git a/Lrp/etc/shorewall/policy b/Lrp/etc/shorewall/policy index 4b144d54e..421d05c78 100644 --- a/Lrp/etc/shorewall/policy +++ b/Lrp/etc/shorewall/policy @@ -17,6 +17,10 @@ # DEST Destination zone. Must be the name of a zone defined # in /etc/shorewall/zones, $FW or "all" # +# WARNING: Firewall->Firewall policies are not allowed; if +# you have a policy where both SOURCE and DEST are $FW, +# Shorewall will not start! +# # POLICY Policy if no match from the rules file is found. Must # be "ACCEPT", "DROP", "REJECT" or "CONTINUE" # @@ -25,6 +29,12 @@ # log message is generated. See syslog.conf(5) for a # description of log levels. # +# Beginning with Shorewall version 1.3.12, you may +# also specify ULOG (must be in upper case). This will +# log to the ULOG target and sent to a separate log +# through use of ulogd +# (http://www.gnumonks.org/projects/ulogd). +# # If you don't want to log but need to specify the # following column, place "_" here. # diff --git a/Lrp/etc/shorewall/rfc1918 b/Lrp/etc/shorewall/rfc1918 index a2e066f49..eae549722 100644 --- a/Lrp/etc/shorewall/rfc1918 +++ b/Lrp/etc/shorewall/rfc1918 @@ -47,7 +47,7 @@ 60.0.0.0/8 logdrop # Reserved 70.0.0.0/7 logdrop # Reserved 72.0.0.0/5 logdrop # Reserved -82.0.0.0/7 logdrop # Reserved +83.0.0.0/8 logdrop # Reserved 84.0.0.0/6 logdrop # Reserved 88.0.0.0/5 logdrop # Reserved 96.0.0.0/3 logdrop # Reserved diff --git a/Lrp/etc/shorewall/rules b/Lrp/etc/shorewall/rules index 39a81eb4d..8554645d9 100644 --- a/Lrp/etc/shorewall/rules +++ b/Lrp/etc/shorewall/rules @@ -31,18 +31,26 @@ # level (e.g, REJECT:info). This causes the packet to be # logged at the specified level. # -# SOURCE Source hosts to which the rule applies. May be a zone -# defined in /etc/shorewall/zones or $FW to indicate the -# firewall itself. If the ACTION is DNAT or REDIRECT, -# sub-zones of the specified zone may be excluded from -# the rule by following the zone name with "!' and a -# comma-separated list of sub-zone names. +# Beginning with Shorewall version 1.3.12, you may +# also specify ULOG (must be in upper case) as a log level.\ +# This will log to the ULOG target and sent to a separate log +# through use of ulogd +# (http://www.gnumonks.org/projects/ulogd). # -# Clients may be further restricted to a list of subnets -# and/or hosts by appending ":" and a comma-separated -# list of subnets and/or hosts. Hosts may be specified -# by IP or MAC address; mac addresses must begin with -# "~" and must use "-" as a separator. +# +# SOURCE Source hosts to which the rule applies. May be a zone +# defined in /etc/shorewall/zones, $FW to indicate the +# firewall itself, or "all" If the ACTION is DNAT or +# REDIRECT, sub-zones of the specified zone may be +# excluded from the rule by following the zone name with +# "!' and a comma-separated list of sub-zone names. +# +# Except when "all" is specified, clients may be further +# restricted to a list of subnets and/or hosts by +# appending ":" and a comma-separated list of subnets +# and/or hosts. Hosts may be specified by IP or MAC +# address; mac addresses must begin with "~" and must use +# "-" as a separator. # # dmz:192.168.2.2 Host 192.168.2.2 in the DMZ # @@ -64,12 +72,13 @@ # as described above (e.g., loc:eth1:192.168.1.5). # # DEST Location of Server. May be a zone defined in -# /etc/shorewall/zones or $FW to indicate the firewall -# itself. +# /etc/shorewall/zones, $FW to indicate the firewall +# itself or "all" # -# The server may be further restricted to a particular -# subnet, host or interface by appending ":" and the -# subnet, host or interface. See above. +# Except when "all" is specified, the server may be +# further restricted to a particular subnet, host or +# interface by appending ":" and the subnet, host or +# interface. See above. # # Restrictions: # diff --git a/Lrp/etc/shorewall/shorewall.conf b/Lrp/etc/shorewall/shorewall.conf index 0d652e7d5..522ad8445 100644 --- a/Lrp/etc/shorewall/shorewall.conf +++ b/Lrp/etc/shorewall/shorewall.conf @@ -9,6 +9,35 @@ # (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) ############################################################################## # +# General note about log levels. Log levels are a method of describing +# to syslog (8) the importance of a message and a number of parameters +# in this file have log levels as their value. +# +# Valid levels are: +# +# 7 debug +# 6 info +# 5 notice +# 4 warning +# 3 err +# 2 crit +# 1 alert +# 0 emerg +# +# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall +# log messages are generated by NetFilter and are logged using facility +# 'kern' and the level that you specifify. If you are unsure of the level +# to choose, 6 (info) is a safe bet. You may specify levels by name or by +# number. +# +# If you have build your kernel with ULOG target support, you may also +# specify a log level of ULOG (must be all caps). Rather than log its +# messages to syslogd, Shorewall will direct netfilter to log the messages +# via the ULOG target which will send them to a process called 'ulogd'. +# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be +# configured to log all Shorewall message to their own log file +################################################################################ +# # PATH - Change this if you want to change the order in which Shorewall # searches directories for executable files. # @@ -97,6 +126,8 @@ LOGBURST= # packets are logged under the 'logunclean' interface option. If the variable # is empty, these packets will still be logged at the 'info' level. # +# See the comment at the top of this file for a description of log levels +# LOGUNCLEAN=info @@ -192,6 +223,8 @@ BLACKLIST_DISPOSITION=DROP # (beward of DOS attacks resulting from such logging). If not set, no logging # of blacklist packets occurs. # +# See the comment at the top of this file for a description of log levels +# BLACKLIST_LOGLEVEL= # @@ -354,6 +387,8 @@ MUTEX_TIMEOUT=60 # it will be rejected by the firewall. If you want these rejects logged, # then set LOGNEWNOTSYN to the syslog log level at which you want them logged. # +# See the comment at the top of this file for a description of log levels +# # Example: LOGNEWNOTSYN=debug @@ -401,8 +436,64 @@ MACLIST_DISPOSITION=REJECT # Specifies the logging level for connection requests that fail MAC # verification. If set to the empty value (MACLIST_LOG_LEVEL="") then # such connection requests will not be logged. +# +# See the comment at the top of this file for a description of log levels # MACLIST_LOG_LEVEL=info +# +# TCP FLAGS Disposition +# +# This variable determins the disposition of packets having an invalid +# combination of TCP flags that are received on interfaces having the +# 'tcpflags' option specified in /etc/shorewall/interfaces. If not specified +# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is assumed. + +TCP_FLAGS_DISPOSITION=DROP + +# +# TCP FLAGS Log Level +# +# Specifies the logging level for packets that fail TCP Flags +# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then +# such packets will not be logged. +# +# See the comment at the top of this file for a description of log levels +# + +TCP_FLAGS_LOG_LEVEL=info + +# +# RFC1918 Log Level +# +# Specifies the logging level for packets that fail RFC 1918 +# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then +# RFC1918_LOG_LEVEL=info is assumed. +# +# See the comment at the top of this file for a description of log levels +# + +RFC1918_LOG_LEVEL=info + +# +# Mark Packets in the forward chain +# +# When processing the tcrules file, Shorewall normally marks packets in the +# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set +# this to "Yes". If not specified or if set to the empty value (e.g., +# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. +# +# Marking packets in the FORWARD chain has the advantage that inbound +# packets destined for Masqueraded/SNATed local hosts have had their destination +# address rewritten so they can be marked based on their destination. When +# packets are marked in the PREROUTING chain, packets destined for +# Masqueraded/SNATed local hosts still have a destination address corresponding +# to the firewall's external interface. +# +# Note: Older kernels do not support marking packets in the FORWARD chain and +# setting this variable to Yes may cause startup problems. + +MARK_IN_FORWARD_CHAIN=No + #LAST LINE -- DO NOT REMOVE diff --git a/Lrp/etc/shorewall/start b/Lrp/etc/shorewall/start new file mode 100644 index 000000000..bd36e8544 --- /dev/null +++ b/Lrp/etc/shorewall/start @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/start +# +# Add commands below that you want to be executed after shorewall has +# been started or restarted. +# diff --git a/Lrp/etc/shorewall/stop b/Lrp/etc/shorewall/stop new file mode 100644 index 000000000..5f097b037 --- /dev/null +++ b/Lrp/etc/shorewall/stop @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/stop +# +# Add commands below that you want to be executed at the beginning of a +# "shorewall stop" command. +# diff --git a/Lrp/etc/shorewall/stopped b/Lrp/etc/shorewall/stopped new file mode 100644 index 000000000..90afeb3ac --- /dev/null +++ b/Lrp/etc/shorewall/stopped @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/stopped +# +# Add commands below that you want to be executed at the completion of a +# "shorewall stop" command. +# diff --git a/Lrp/etc/shorewall/tcrules b/Lrp/etc/shorewall/tcrules index 793a09994..d905a01ab 100644 --- a/Lrp/etc/shorewall/tcrules +++ b/Lrp/etc/shorewall/tcrules @@ -6,6 +6,11 @@ # Entries in this file cause packets to be marked as a means of # classifying them for traffic control or policy routing. # +# I M P O R T A N T ! ! ! ! +# +# FOR ENTRIES IN THIS FILE TO HAVE ANY EFFECT, YOU MUST SET +# TC_ENABLED=Yes in /etc/shorewall/shorewall.conf +# # Columns are: # # diff --git a/Lrp/sbin/shorewall b/Lrp/sbin/shorewall index 67741839f..0245eb4ae 100755 --- a/Lrp/sbin/shorewall +++ b/Lrp/sbin/shorewall @@ -58,6 +58,7 @@ # shorewall show nat Display the rules in the nat table # shorewall show {mangle|tos} Display the rules in the mangle table # shorewall show tc Display traffic control info +# shorewall show classifiers Display classifiers # shorewall version Display the installed version id # shorewall check Verify the more heavily-used # configuration files. @@ -150,8 +151,10 @@ display_chains() iptables -L -n -v > /tmp/chains-$$ clear - echo -e "$banner `date`\\n" - echo -e "Standard Chains\\n" + echo "$banner `date`" + echo + echo "Standard Chains" + echo firstchain="Yes" showchain INPUT showchain OUTPUT @@ -160,9 +163,11 @@ display_chains() timed_read clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo firstchain=Yes - echo -e "Input Chains\\n" + echo "Input Chains" + echo chains=`grep '^Chain.*_[in|fwd]' /tmp/chains-$$ | cut -d' ' -f 2` @@ -176,10 +181,12 @@ display_chains() if [ -n "`grep "^Chain \.*${zone}" /tmp/chains-$$`" ] ; then clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo firstchain=Yes eval display=\$${zone}_display - echo -e "$display Chains\\n" + echo "$display Chains" + echo for zone1 in $FW $zones; do showchain ${zone}2$zone1 showchain @${zone}2$zone1 @@ -193,9 +200,11 @@ display_chains() done clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo firstchain=Yes - echo -e "Policy Chains\\n" + echo "Policy Chains" + echo showchain common showchain badpkt showchain icmpdef @@ -212,9 +221,11 @@ display_chains() timed_read clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo firstchain=Yes - echo -e "Dynamic Chain\\n" + echo "Dynamic Chain" + echo showchain dynamic timed_read @@ -248,7 +259,8 @@ packet_log() # $1 = number of messages [ -n "$realtail" ] && options="-n$1" grep 'Shorewall:\|ipt_unclean' $LOGFILE | \ - sed s/" $host kernel: Shorewall:"/" "/ | \ + sed s/" kernel:"// | \ + sed s/" $host Shorewall:"/" "/ | \ sed s/" $host kernel: ipt_unclean: "/" "/ | \ sed 's/MAC=.*SRC=/SRC=/' | \ tail $options @@ -284,6 +296,34 @@ show_tc() { } +# +# Show classifier information +# +show_classifiers() { + + show_one_classifier() { + local device=${1%@*} + qdisc=`tc qdisc list dev $device` + + if [ -n "$qdisc" ]; then + echo Device $device: + tc -s filter ls dev $device + echo + fi + } + + ip link list | \ + while read inx interface details; do + case $inx in + [0-9]*) + show_one_classifier ${interface%:} + ;; + *) + ;; + esac + done + +} # # Monitor the Firewall # @@ -309,9 +349,11 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that display_chains clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo - echo -e "Dropped/Rejected Packet Log\\n" + echo "Dropped/Rejected Packet Log" + echo show_reset @@ -319,11 +361,14 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that if [ "$rejects" != "$oldrejects" ]; then oldrejects="$rejects" - echo -e '\a' + + $RING_BELL + packet_log 20 if [ "$pause" = "Yes" ]; then - echo -en '\nEnter any character to continue: ' + echo + echo $ECHO_N 'Enter any character to continue: ' read foo else timed_read @@ -335,28 +380,48 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that fi clear - echo -e "$banner `date`\\n" - echo -e "NAT Status\\n" + echo "$banner `date`" + echo + echo "NAT Status" + echo iptables -t nat -L -n -v timed_read clear - echo -e "$banner `date`\\n" - echo -e "\\nTOS/MARK Status\\n" + echo "$banner `date`" + echo + echo + echo "TOS/MARK Status" + echo iptables -t mangle -L -n -v timed_read clear - echo -e "$banner `date`\\n" - echo -e "\\nTracked Connections\\n" + echo "$banner `date`" + echo + echo + echo "Tracked Connections" + echo cat /proc/net/ip_conntrack timed_read clear - echo -e "$banner `date`\\n" - echo -e "\\nTraffic Shaping/Control\\n" + echo "$banner `date`" + echo + echo + echo "Traffic Shaping/Control" + echo show_tc timed_read + + clear + echo "$banner `date`" + echo + echo + echo "Packet Classifiers" + echo + show_classifiers + timed_read done } @@ -383,9 +448,11 @@ logwatch() # $1 = timeout -- if negative, prompt each time that while true; do clear - echo -e "$banner `date`\\n" + echo "$banner `date`" + echo - echo -e "Dropped/Rejected Packet Log\\n" + echo "Dropped/Rejected Packet Log" + echo show_reset @@ -393,11 +460,14 @@ logwatch() # $1 = timeout -- if negative, prompt each time that if [ "$rejects" != "$oldrejects" ]; then oldrejects="$rejects" - echo -e '\a' + + $RING_BELL + packet_log 40 if [ "$pause" = "Yes" ]; then - echo -en '\nEnter any character to continue: ' + echo + echo $ECHO_N 'Enter any character to continue: ' read foo else timed_read @@ -419,7 +489,7 @@ usage() # $1 = exit status echo "where is one of:" echo " add [:] " echo " delete [:] " - echo " show [|connections|log|nat|tc|tos]" + echo " show [|classifiers|connections|log|nat|tc|tos]" echo " start" echo " stop" echo " reset" @@ -445,7 +515,8 @@ usage() # $1 = exit status # show_reset() { [ -f $STATEDIR/restarted ] && \ - echo -e "Counters reset `cat $STATEDIR/restarted`\\n" + echo "Counters reset `cat $STATEDIR/restarted`" && \ + echo } # @@ -537,6 +608,24 @@ banner="Shorewall-$version Status at $HOSTNAME -" get_statedir +case `echo -e` in + -e*) + RING_BELL="echo \'\a\'" + ;; + *) + RING_BELL="echo -e \'\a\'" + ;; +esac + +case `echo -n "Testing"` in + -n*) + ECHO_N= + ;; + *) + ECHO_N=-n + ;; +esac + case "$1" in start|stop|restart|reset|clear|refresh|check) [ $# -ne 1 ] && usage 1 @@ -550,32 +639,43 @@ case "$1" in [ $# -gt 2 ] && usage 1 case "$2" in connections) - echo -e "Shorewall-$version Connections at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Connections at $HOSTNAME - `date`" + echo cat /proc/net/ip_conntrack ;; nat) - echo -e "Shorewall-$version NAT at $HOSTNAME - `date`\\n" + echo "Shorewall-$version NAT at $HOSTNAME - `date`" + echo show_reset iptables -t nat -L -n -v ;; tos|mangle) - echo -e "Shorewall-$version TOS at $HOSTNAME - `date`\\n" + echo "Shorewall-$version TOS at $HOSTNAME - `date`" + echo show_reset iptables -t mangle -L -n -v ;; log) get_config - echo -e "Shorewall-$version Log at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Log at $HOSTNAME - `date`" + echo show_reset host=`echo $HOSTNAME | sed 's/\..*$//'` packet_log 20 ;; tc) - echo -e "Shorewall-$version Traffic Control at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Traffic Control at $HOSTNAME - `date`" + echo show_tc ;; + classifiers) + echo "Shorewall-$version Clasifiers at $HOSTNAME - `date`" + echo + show_classifiers + ;; *) - echo -e "Shorewall-$version Chain $2 at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Chain $2 at $HOSTNAME - `date`" + echo show_reset iptables -L $2 -n -v ;; @@ -594,15 +694,20 @@ case "$1" in [ $# -eq 1 ] || usage 1 get_config clear - echo -e "Shorewall-$version Status at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Status at $HOSTNAME - `date`" + echo show_reset host=`echo $HOSTNAME | sed 's/\..*$//'` iptables -L -n -v echo packet_log 20 echo + echo "NAT Table" + echo iptables -t nat -L -n -v echo + echo "Mangle Table" + echo iptables -t mangle -L -n -v echo cat /proc/net/ip_conntrack @@ -611,7 +716,9 @@ case "$1" in [ $# -eq 1 ] || usage 1 get_config clear - echo -e "Shorewall-$version Hits at $HOSTNAME - `date`\\n" + echo "Shorewall-$version Hits at $HOSTNAME - `date`" + echo + timeout=30 if [ `grep -c "Shorewall:" $LOGFILE ` -gt 0 ] ; then diff --git a/Lrp/usr/lib/shorewall/functions b/Lrp/usr/lib/shorewall/functions index 340c0d9b2..90ad27b35 100644 --- a/Lrp/usr/lib/shorewall/functions +++ b/Lrp/usr/lib/shorewall/functions @@ -25,9 +25,22 @@ find_file() # # Replace commas with spaces and echo the result # -separate_list() -{ - echo $1 | sed 's/,/ /g' +separate_list() { + local list + local part + local newlist + + list="$@" + part="${list%%,*}" + newlist="$part" + + while [ "x$part" != "x$list" ]; do + list="${list#*,}"; + part="${list%%,*}"; + newlist="$newlist $part"; + done + + echo "$newlist" } # diff --git a/Lrp/var/lib/lrpkg/shorwall.conf b/Lrp/var/lib/lrpkg/shorwall.conf index 0cebe33a5..4433a561f 100644 --- a/Lrp/var/lib/lrpkg/shorwall.conf +++ b/Lrp/var/lib/lrpkg/shorwall.conf @@ -16,3 +16,7 @@ /etc/shorewall/tos TOS Type of Service policy /etc/shorewall/blacklist Blacklist Blacklisted hosts /etc/shorewall/rfc1918 RFC1918 Defines 'norfc1918' interface option +/etc/shorewall/init Init Commands executed before [re]start +/etc/shorewall/start Start Commands executed after [re]start +/etc/shorewall/stop Stop Commands executed before stop +/etc/shorewall/stopped Stopped Commands executed after stop diff --git a/Lrp/var/lib/lrpkg/shorwall.version b/Lrp/var/lib/lrpkg/shorwall.version index 0c00f6108..90a7f6029 100644 --- a/Lrp/var/lib/lrpkg/shorwall.version +++ b/Lrp/var/lib/lrpkg/shorwall.version @@ -1 +1 @@ -1.3.10 +1.3.12 diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index e7bd8925f..c8272f626 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,17 +1,43 @@ -Changes since 1.3.10 +Changes since 1.3.11 -1. Added TCP flags checking. +1. Fixed DNAT/REDIRECT bug with excluded sub-zones. -2. Accomodate bash clones like dash and ash +2. "shorewall refresh" now refreshes the traffic shaping rules -3. Added some comments in the policy chain creation/population logic. +3. Turned off debugging after error. -4. Check for fw->fw rules. +4. Removed drop of INVALID state output ICMP packets. -5. Allow 'all' in rules. +5. Replaced 'sed' invocation in separate_list() by shell code (speedup). -6. Add reverse GRE rules for PPTP server and clients. +6. Replaced 'wc' invocation in list_count() by shell code (speedup) -7. Add warning to tcrules file. +7. Replaced 'sed' invocation in run_iptables() by shell code and + optomized (speedup) -8. Add warning to policy file that fw->fw policies aren't allowed. +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 diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 82de396d7..26a605911 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,1161 +1,1204 @@ - + - + - + Shorewall 1.3 Documentation - + + - + - + - - - + + - - - + + + +
- +
+

Shorewall 1.3 Reference

-
- +

This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall in common setups - may be found in the QuickStart - Guides.

- + Step-by-step instructions for configuring Shorewall in common +setups may be found in the QuickStart Guides. +

Components

- +

Shorewall consists of the following components:

- +
    -
  • params -- a parameter file -installed in /etc/shorewall that can be used to establish the values -of shell variables for use in other files.
    • -
  • shorewall.conf -- a parameter - file installed in /etc/shorewall that is used to set several -firewall parameters.
    • -
  • zones - a parameter file installed - in /etc/shorewall that defines a network partitioning into "zones"
    • -
  • policy -- a parameter file - installed in /etc/shorewall/ that establishes overall firewall - policy.
    • -
  • rules -- a parameter file -installed in /etc/shorewall and used to express firewall rules -that are exceptions to the high-level policies established in -/etc/shorewall/policy.
    • -
  • blacklist -- a parameter file - installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC - addresses.
    • -
  • functions -- a set of shell functions used by both - the firewall and shorewall shell programs. Installed in /etc/shorewall - prior to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 -and in /usr/lib/shorewall in later versions.
    • -
  • modules -- a parameter file - installed in /etc/shorewall and that specifies kernel modules -and their parameters. Shorewall will automatically load the modules - specified in this file.
    • -
  • tos -- a parameter file installed - in /etc/shorewall that is used to specify how the Type of Service - (TOS) field in packets is to be set.
    • -
  • icmp.def -- a parameter file - installed in /etc/shorewall and that specifies the default handling - of ICMP packets when the applicable policy is DROP or REJECT.
    • -
  • common.def -- a parameter file - installed in in /etc/shorewall that defines firewall-wide rules that - are applied before a DROP or REJECT policy is applied.
    • -
  • interfaces -- a parameter - file installed in /etc/shorewall/ and used to describe the -interfaces on the firewall system.
    • -
  • hosts -- a parameter file installed - in /etc/shorewall/ and used to describe individual hosts or -subnetworks in zones.
    • -
  • maclist -- a parameter file installed - in /etc/shorewall and used to verify the MAC address (and possibly also -the IP address(es)) of devices.
    -
    • -
  • masq - This file -also describes IP masquerading under Shorewall and is installed in - /etc/shorewall.
    • -
  • firewall - -- a shell program that reads the configuration files in /etc/shorewall - and configures your firewall. This file is installed in your - init.d directory (/etc/rc.d/init.d ) where it is renamed shorewall.  - /etc/shorewall/firewall (/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 - and /usr/lib/shorewall/firewall in 1.3.9 and later) is a symbolic link - to this program.
    • -
  • nat -- a parameter file in /etc/shorewall - used to define static NAT .
    • -
  • proxyarp -- a parameter -file in /etc/shorewall used to define Proxy - Arp .
    • -
  • rfc1918 -- a parameter file -in /etc/shorewall used to define the treatment of packets under the - norfc1918 interface option.
    • -
  • routestopped -- a parameter - file in /etc/shorewall used to define those hosts that can access the - firewall when Shorewall is stopped.
    • -
  • tcrules -- - a parameter file in /etc/shorewall used to define rules for classifying - packets for Traffic Shaping/Control.
    • -
  • tunnels -- a parameter file - in /etc/shorewall used to define IPSec tunnels.
    • -
  • shorewall -- a shell program - (requiring a Bourne shell or derivative) used to control and - monitor the firewall. This should be placed in /sbin or in - /usr/sbin (the install.sh script and the rpm install this file - in /sbin).
    • -
  • version -- a file created in /etc/shorewall/ - (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall - beginning in version 1.3.9) that describes the version of  Shorewall - installed on your system.
    • - +
  • params -- a parameter +file installed in /etc/shorewall that can be used to establish the +values of shell variables for use in other files.
    • +
  • shorewall.conf -- a parameter + file installed in /etc/shorewall that is used to set several + firewall parameters.
    • +
  • zones - a parameter file + installed in /etc/shorewall that defines a network partitioning + into "zones"
    • +
  • policy -- a parameter +file installed in /etc/shorewall/ that establishes overall +firewall policy.
    • +
  • rules -- a parameter +file installed in /etc/shorewall and used to express firewall +rules that are exceptions to the high-level policies established +in /etc/shorewall/policy.
    • +
  • blacklist -- a parameter + file installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC + addresses.
    • +
  • functions -- a set of shell functions used by + both the firewall and shorewall shell programs. Installed in /etc/shorewall + prior to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 + and in /usr/lib/shorewall in later versions.
    • +
  • modules -- a parameter + file installed in /etc/shorewall and that specifies kernel modules + and their parameters. Shorewall will automatically load the +modules specified in this file.
    • +
  • tos -- a parameter file installed + in /etc/shorewall that is used to specify how the Type of Service + (TOS) field in packets is to be set.
    • +
  • icmp.def -- a parameter + file installed in /etc/shorewall and that specifies the default + handling of ICMP packets when the applicable policy is DROP or REJECT.
    • +
  • common.def -- a parameter + file installed in in /etc/shorewall that defines firewall-wide rules + that are applied before a DROP or REJECT policy is applied.
    • +
  • interfaces -- a +parameter file installed in /etc/shorewall/ and used to describe +the interfaces on the firewall system.
    • +
  • hosts -- a parameter file + installed in /etc/shorewall/ and used to describe individual + hosts or subnetworks in zones.
    • +
  • maclist -- a parameter file installed + in /etc/shorewall and used to verify the MAC address (and possibly also + the IP address(es)) of devices.
    +
    • +
  • masq - This file + also describes IP masquerading under Shorewall and is installed in + /etc/shorewall.
    • +
  • firewall + -- a shell program that reads the configuration files in /etc/shorewall + and configures your firewall. This file is installed in +your init.d directory (/etc/rc.d/init.d ) where it is renamed + shorewall.  /etc/shorewall/firewall (/var/lib/shorewall/firewall + in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 and + later) is a symbolic link to this program.
    • +
  • nat -- a parameter file +in /etc/shorewall used to define static +NAT .
    • +
  • proxyarp -- a parameter + file in /etc/shorewall used to define Proxy + Arp .
    • +
  • rfc1918 -- a parameter file + in /etc/shorewall used to define the treatment of packets under the + norfc1918 interface option.
    • +
  • routestopped -- a parameter + file in /etc/shorewall used to define those hosts that can access + the firewall when Shorewall is stopped.
    • +
  • tcrules -- + a parameter file in /etc/shorewall used to define rules for classifying + packets for Traffic Shaping/Control.
    • +
  • tunnels -- a parameter + file in /etc/shorewall used to define IPSec tunnels.
    • +
  • shorewall -- a shell + program (requiring a Bourne shell or derivative) used to + control and monitor the firewall. This should be placed in + /sbin or in /usr/sbin (the install.sh script and the rpm install + this file in /sbin).
    • +
  • version -- a file created in /etc/shorewall/ + (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall + beginning in version 1.3.9) that describes the version of  Shorewall + installed on your system.
    • +
- +

/etc/shorewall/params

- +

You may use the file /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.

- + that you can then use in some of the other configuration files.

+

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

- + within the Shorewall programs

+

Example:

- + 
 	NET_IF=eth0
	NET_BCAST=130.252.100.255
	NET_OPTIONS=noping,norfc1918
- +

Example (/etc/shorewall/interfaces record):

- + 
	net $NET_IF $NET_BCAST $NET_OPTIONS
- +

The result will be the same as if the record had been written

- + 
	net eth0 130.252.100.255 noping,norfc1918
- +

Variables may be used anywhere in the other configuration - files.

- + files.

+

/etc/shorewall/zones

- +

This file is used to define the network zones. There is one entry - in /etc/shorewall/zones for each zone; Columns in an entry are:

- + in /etc/shorewall/zones for each zone; Columns in an entry are:

+
    -
  • ZONE - short name for the zone. The name should -be 5 characters or less in length and consist of lower-case letters -or numbers. Short names must begin with a letter and the name assigned - to the firewall is reserved for use by Shorewall itself. Note that - the output produced by iptables is much easier to read if you select - short names that are three characters or less in length. The name - "all" may not be used as a zone name nor may the zone name assigned to - the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.
    • -
  • DISPLAY - The name of the zone as displayed during - Shorewall startup.
    • -
  • COMMENTS - Any comments that you want to make about - the zone. Shorewall ignores these comments.
    • - +
  • ZONE - short name for the zone. The name should + be 5 characters or less in length and consist of lower-case letters + or numbers. Short names must begin with a letter and the name assigned + to the firewall is reserved for use by Shorewall itself. Note that + the output produced by iptables is much easier to read if you +select short names that are three characters or less in length. +The name "all" may not be used as a zone name nor may the zone name +assigned to the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.
    • +
  • DISPLAY - The name of the zone as displayed +during Shorewall startup.
    • +
  • COMMENTS - Any comments that you want to make + about the zone. Shorewall ignores these comments.
    • +
- +

The /etc/shorewall/zones file released with Shorewall is as follows:

- + - + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + - + - +
ZONE DISPLAY COMMENTS
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
- +

You may add, delete and modify entries in the /etc/shorewall/zones file - as desired so long as you have at least one zone defined.

- + as desired so long as you have at least one zone defined.

+

Warning 1: If you rename or delete a zone, you should perform "shorewall - stop; shorewall start" to install the change rather than "shorewall -restart".

- + stop; shorewall start" to install the change rather than "shorewall + restart".

+

Warning 2: The order of entries in the /etc/shorewall/zones file is - significant in some cases.

- + significant in some cases.

+

/etc/shorewall/interfaces

- +

This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There will be one entry in - /etc/shorewall/interfaces for each of your interfaces. Columns in an entry - are:

- + interfaces are connected to which zone. There will be one entry in + /etc/shorewall/interfaces for each of your interfaces. Columns in an +entry are:

+
    -
  • ZONE - A zone defined in the /etc/shorewall/zones - file or  "-". If you specify "-", you must use the /etc/shorewall/hosts file to define the zones - accessed via this interface.
    • -
  • INTERFACE - the name of the interface (examples: -eth0, ppp0, ipsec+). DO NOT INCLUDE THE -LOOPBACK INTERFACE (lo) IN THIS FILE!!!
    • -
  • BROADCAST - the broadcast address(es) for the sub-network(s) - attached to the interface. This should be left empty for P-T-P interfaces - (ppp*, ippp*); if you need to specify options for such an interface, - enter "-" in this column. If you supply the special value "detect" in - this column, the firewall will automatically determine the broadcast - address. In order to use "detect": +
  • ZONE - A zone defined in the /etc/shorewall/zones file or  "-". If you +specify "-", you must use the /etc/shorewall/hosts + file to define the zones accessed via this interface.
    • +
  • INTERFACE - the name of the interface (examples: + eth0, ppp0, ipsec+). Each interface can be listed on only one record + in this file. DO NOT INCLUDE THE LOOPBACK + INTERFACE (lo) IN THIS FILE!!!
    • +
  • BROADCAST - the broadcast address(es) for the + sub-network(s) attached to the interface. This should be left +empty for P-T-P interfaces (ppp*, ippp*); if you need to specify +options for such an interface, enter "-" in this column. If you supply +the special value "detect" in this column, the firewall will automatically + determine the broadcast address. In order to use "detect": +
      -
    • you must have iproute installed
      • -
    • the interface must be up before you start your firewall
      • -
    • the interface must only be attached to a single sub-network - (i.e., there must have a single broadcast address). 
      • - +
    • you must have iproute installed
      • +
    • the interface must be up before you start your firewall
      • +
    • the interface must only be attached to a single sub-network + (i.e., there must have a single broadcast address). 
      • +
    -
    • -
  • OPTIONS - a comma-separated list of options. Possible - options include: - +
    • +
  • OPTIONS - a comma-separated list of options. +Possible options include: +

    tcpflags (added in version 1.3.11) - This option causes Shorewall to make sanity checks on the header flags in TCP packets arriving -on this interface. Packets failing these checks are logged according to the -TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf -and are disposed of according to the TCP_FLAGS_DISPOSITION option.
    -
    -blacklist     - This option causes incoming packets on this - interface to be checked against the blacklist.
    -
    - dhcp     - The interface is assigned an IP address via DHCP or -is used by a DHCP server running on the firewall. The firewall -will be configured to allow DHCP traffic to and from the interface -even when the firewall is stopped. You may also wish to use this option -if you have a static IP but you are on a LAN segment that has a lot of -Laptops that use DHCP and you select the norfc1918 option (see -below).

    +on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; +these flag combinations are typically used for "silent" port scans. Packets + failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option + in /etc/shorewall/shorewall.conf and are disposed of +according to the TCP_FLAGS_DISPOSITION option.
    +
    + blacklist     - This option causes incoming packets on this + interface to be checked against the blacklist.
    +
    + dhcp     - The interface is assigned an IP address via DHCP +or is used by a DHCP server running on the firewall. The firewall + will be configured to allow DHCP traffic to and from the interface + even when the firewall is stopped. You may also wish to use this option + if you have a static IP but you are on a LAN segment that has a lot + of Laptops that use DHCP and you select the norfc1918 option +(see below).

    - +

    noping - ICMP echo-request (ping) packets addressed to - the firewall will be ignored by this interface.
    -
    - filterping - ICMP echo-request (ping) packets addressed -to the firewall will be handled according to the /etc/shorewall/rules -and /etc/shorewall/policy file. If the applicable policy is DROP or REJECT - and you have supplied your own /etc/shorewall/icmpdef file then these - 'ping' requests will be passed through the rules in that file before -being dropped or rejected. If neither noping nor filterping -is specified then the firewall will automatically ACCEPT these 'ping' -requests. If both noping and filterping are specified, - filterping takes precedence.

    + the firewall will be ignored by this interface.
    +
    + filterping - ICMP echo-request (ping) packets addressed + to the firewall will be handled according to the /etc/shorewall/rules + and /etc/shorewall/policy file. If the applicable policy is DROP or +REJECT and you have supplied your own /etc/shorewall/icmpdef file then +these 'ping' requests will be passed through the rules in that file +before being dropped or rejected. If neither noping nor filterping + is specified then the firewall will automatically ACCEPT these 'ping' + requests. If both noping and filterping are specified, + filterping takes precedence.

    - +

    routestopped - Beginning with Shorewall 1.3.4, this option - is deprecated in favor of the /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from this interface - will be accepted and routing will occur between this interface and - other routestopped interfaces.

    + is deprecated in favor of the /etc/shorewall/routestopped + file. When the firewall is stopped, traffic to and from this interface + will be accepted and routing will occur between this interface + and other routestopped interfaces.

    - +

    norfc1918 - Packets arriving on this interface and that - have a source address that is reserved in RFC 1918 or in other RFCs -will be dropped after being optionally logged. If packet -mangling is enabled in /etc/shorewall/shorewall.conf , then packets -arriving on this interface that have a destination address that is -reserved by one of these RFCs will also be logged and dropped.
    -
    - Addresses blocked by the standard rfc1918 - file include those addresses reserved by RFC1918 plus other - ranges reserved by the IANA or by other RFCs.

    + have a source address that is reserved in RFC 1918 or in other RFCs + will be dropped after being optionally logged. If packet + mangling is enabled in /etc/shorewall/shorewall.conf , then + packets arriving on this interface that have a destination address + that is reserved by one of these RFCs will also be logged and dropped.
    +
    + Addresses blocked by the standard rfc1918 + file include those addresses reserved by RFC1918 plus +other ranges reserved by the IANA or by other RFCs.

    - +

    Beware that as IPv4 addresses become in increasingly short supply, - ISPs are beginning to use RFC 1918 addresses within their own infrastructure. - Also, many cable and DSL "modems" have an RFC 1918 address that can -be used through a web browser for management and monitoring functions. -If you want to specify norfc1918 on your external interface but -need to allow access to certain addresses from the above list, see FAQ 14.

    + ISPs are beginning to use RFC 1918 addresses within their own infrastructure. + Also, many cable and DSL "modems" have an RFC 1918 address that can + be used through a web browser for management and monitoring functions. + If you want to specify norfc1918 on your external interface but + need to allow access to certain addresses from the above list, see + FAQ 14.

    - +

    routefilter - Invoke the Kernel's route filtering - (anti-spoofing) facility on this interface. The kernel will reject - any packets incoming on this interface that have a source address - that would be routed outbound through another interface on the firewall. - Warning: If you specify this option - for an interface then the interface must be up prior to starting the - firewall.

    + (anti-spoofing) facility on this interface. The kernel will reject + any packets incoming on this interface that have a source address + that would be routed outbound through another interface on the +firewall. Warning: If you specify this +option for an interface then the interface must be up prior to starting +the firewall.

    - +

    multi - The interface has multiple addresses and - you want to be able to route between them. Example: you have two - addresses on your single local interface eth1, one each in subnets - 192.168.1.0/24 and 192.168.2.0/24 and you want to route between these - subnets. Because you only have one interface in the local zone, Shorewall - won't normally create a rule to forward packets from eth1 to eth1. - Adding "multi" to the entry for eth1 will cause Shorewall to create - the loc2loc chain and the appropriate forwarding rule.

    - + you want to be able to route between them. Example: you have two + addresses on your single local interface eth1, one each in subnets + 192.168.1.0/24 and 192.168.2.0/24 and you want to route between + these subnets. Because you only have one interface in the local +zone, Shorewall won't normally create a rule to forward packets from + eth1 to eth1. Adding "multi" to the entry for eth1 will cause + Shorewall to create the loc2loc chain and the appropriate forwarding + rule.

    + +

    dropunclean - Packets from this interface that are selected by the 'unclean' match target in iptables will be optionally logged and then dropped. - Warning: This feature -requires that UNCLEAN match support be configured in your - kernel, either in the kernel itself or as a module. UNCLEAN - support is broken in some versions of the kernel but appears - to work ok in 2.4.17-rc1.
    -
    - Update 12/17/2001:     The unclean match - patch from 2.4.17-rc1 is Warning: This feature + requires that UNCLEAN match support be configured in your + kernel, either in the kernel itself or as a module. UNCLEAN + support is broken in some versions of the kernel but appears + to work ok in 2.4.17-rc1.
    +
    + Update 12/17/2001:     The unclean +match patch from 2.4.17-rc1 is     available - for download. I am currently running this patch - applied to kernel 2.4.16.

    - -

    Update 12/20/2001: I've - seen a number of tcp connection requests with OPT -(020405B40000080A...) being dropped in the - badpkt chain. This appears to be a bug in -the remote TCP stack whereby it is 8-byte aligning -a timestamp (TCP option 8) but rather than padding with 0x01 - it is padding with 0x00. It's a tough call whether to deny - people access to your servers because of this rather minor - bug in their networking software. If you wish to disable -the check that causes these connections to be dropped, - here's - a kernel patch against 2.4.17-rc2.

    - + for download. I am currently running this patch + applied to kernel 2.4.16.

    + + +

    Update 12/20/2001: I've + seen a number of tcp connection requests with OPT + (020405B40000080A...) being dropped in the + badpkt chain. This appears to be a bug +in the remote TCP stack whereby it is 8-byte aligning + a timestamp (TCP option 8) but rather than padding with 0x01 + it is padding with 0x00. It's a tough call whether to deny + people access to your servers because of this rather +minor bug in their networking software. If you wish +to disable the check that causes these connections + to be dropped, here's + a kernel patch against 2.4.17-rc2.

    + +

    logunclean - This option works like dropunclean - with the exception that packets selected by the 'unclean' - match target in iptables are logged but not dropped. - The level at which the packets are logged is determined - by the setting of LOGUNCLEAN - and if LOGUNCLEAN has not been set, "info" is assumed.

    - + with the exception that packets selected by the +'unclean' match target in iptables are logged but +not dropped. The level at which the packets +are logged is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN +has not been set, "info" is assumed.

    + +

    proxyarp (Added in version 1.3.5) - This option causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp - and is used when implementing Proxy ARP Sub-netting - as described at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do not set this option if you are implementing Proxy ARP through entries in /etc/shorewall/proxyarp.
    -
    - maclist (Added in version 1.3.10) - If this option is specified, - all connection requests from this interface are subject to + maclist (Added in version 1.3.10) - If this option is specified, + all connection requests from this interface are subject to MAC Verification. May only be specified for - ethernet interfaces.
    -

    + ethernet interfaces.

    • - +
- + +

My recommendations concerning options:
+

+ +
    +
  • External Interface -- tcpflags,blacklist,filterping,norfc1918,routefilter
    • +
  • Internal Interface -- routestopped
    • +
  • Wireless Interface -- maclist,routefilter,tcpflags
    +
    • +
  • Don't use dropunclean -- It's broken in my opinion
    • +
  • Use logunclean only when you are trying to debug a problem
    • +
  • Use dhcp,multi and proxyarp when needed.
    +
    • + +
+ +

+ +

Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local network and -eth0 gets its IP address via DHCP. You want to ignore ping requests from -the internet and you want to check all packets entering -from the internet against the black -list. Your /etc/shorewall/interfaces file would be as follows:

+ to a Cable or DSL modem and eth1 connects to your local network and + eth0 gets its IP address via DHCP. You want to ignore ping requests +from the internet and you want to check all packets +entering from the internet against the black list. Your /etc/shorewall/interfaces file +would be as follows:

- -
+ +
- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + - +
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918,blacklist
loceth1detect 
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918,blacklist
loceth1detect 
-
+
- +

Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:

+ file would be:

- -
+ +
- - - - - - - - - - - - - + + + + + + + + + + + + + - + + - +
ZONE INTERFACE BROADCAST OPTIONS
netppp0  
ZONE INTERFACE BROADCAST OPTIONS
netppp0  
-
+
- +

Example 3: You have local interface eth1 with two IP addresses - 192.168.1.1/24 and 192.168.12.1/24

- -
+ +
- - - - - - - - - - - - - + + + + + + + + + + + + + - - + +
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255 
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255 
-
+
- +

/etc/shorewall/hosts - Configuration

- + Configuration +

For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.

- +

WARNING: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.

- +

Columns in this file are:

- + +
    -
  • ZONE - A zone defined in the /etc/shorewall/zones - file.
    • -
  • HOST(S) - The name of a network interface followed - by a colon (":") followed by either:
    • - +
  • ZONE - A zone defined in the /etc/shorewall/zones file.
    • +
  • HOST(S) - The name of a network interface followed + by a colon (":") followed by either:
    • +
- +
- +
    -
  1. An IP address (example - eth1:192.168.1.3)
    2. +
  2. An IP address (example - eth1:192.168.1.3)
    3. -
  3. A subnet in CIDR notation - (example - eth2:192.168.2.0/24)
    4. +
  4. A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
    5. - +
- +

The interface name much match an entry in /etc/shorewall/interfaces.

-
- + + +
    -
  • OPTIONS - A comma-separated list of options.
    • - +
  • OPTIONS - A comma-separated list of options.
    • +
- +
- +

routestopped - Beginning with Shorewall 1.3.4, this option is deprecated in favor of the /etc/shorewall/routestopped file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will occur -between this host and other routestopped interfaces and hosts.
-
- maclist - Added in version 1.3.10. If specified, connection requests - from the hosts specified in this entry are subject to routestopped interfaces and hosts.
+
+ maclist - Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to MAC Verification. This option is only valid - for ethernet interfaces.
-

-
+ for ethernet interfaces.
+

+ - +

If you don't define any hosts for a zone, the hosts in the zone default - to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces - to the zone.

+ to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces + to the zone.

- +

Note 1: You probably DON'T want to specify any hosts for your internet zone since the hosts that you specify will be the only ones that you will be able to access without adding additional rules.

- +

Note 2: The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the host file - is processed. Please read the description of -that variable carefully.

+ in /etc/shorewall/shorewall.conf + has an important effect on how the host file + is processed. Please read the description of + that variable carefully.

- +

Example:

- +

Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:

- + you want to make into separate zones:

+ +
    -
  • 192.168.1.0/25 
    • -
  • 192.168.1.128/25
    • - +
  • 192.168.1.0/25 
    • +
  • 192.168.1.128/25
    • +
- +

Your /etc/shorewall/interfaces file might look like:

- -
- - - - - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918
-eth1detect 
-
- - -

The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces - to multiple zones.

- - -

Your /etc/shorewall/hosts file might look like:

- - -
- - - - - - - - - - - - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25 
loc2eth1:192.168.1.128/25routestopped
-
- - -

Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.

- - -

Nested and Overlapping Zones

- - -

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow -you to define nested or overlapping zones. Such overlapping/nested zones - are allowed and Shorewall processes zones in the order that they appear - in the /etc/shorewall/zones file. So if you have nested zones, you want - the sub-zone to appear before the super-zone and in the case of overlapping - zones, the rules that will apply to hosts that belong to both zones -is determined by which zone appears first in /etc/shorewall/zones.

- - -

Hosts that belong to more than one zone may be managed by the rules - of all of those zones. This is done through use of the special CONTINUE policy described below.

- - -

- /etc/shorewall/policy Configuration.

- - -

This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms of clients - who initiate connections and servers who receive those connection - requests. Policies defined in /etc/shorewall/policy describe which zones - are allowed to establish connections with other zones.

- - -

Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to a particular - connection request then the policy from /etc/shorewall/policy is applied.

- - -

Four policies are defined:

- - -
    -
  • ACCEPT - The connection is allowed.
    • -
  • DROP - The connection request is ignored.
    • -
  • REJECT - The connection request is rejected with -an RST (TCP) or an ICMP destination-unreachable packet being returned - to the client.
    • -
  • CONTINUE - The connection is neither ACCEPTed, -DROPped nor REJECTed. CONTINUE may be used when one or both of the -zones named in the entry are sub-zones of or intersect with another -zone. For more information, see below. 
    • - -
- -

For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time that the policy - is applied.

- - -

Entries in /etc/shorewall/policy have four columns as follows:

- - -
    - -
  1. SOURCE - The name of -a client zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or -"all").
    2. - -
  2. DEST - The name of a -destination zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all"). -Shorewall automatically allows all traffic from the firewall to itself so -the name of the firewall zone cannot appear in both the -SOURCE and DEST columns.
    3. - -
  3. POLICY - The default -policy for connection requests from the SOURCE zone to the DESTINATION -zone.
    4. - -
  4. LOG LEVEL - Optional. -If left empty, no log message is generated when the policy is applied. - Otherwise, this column should contain an integer or name indicating - a syslog level. See the syslog.conf man page for a description of - each log level.
    5. - -
  5. LIMIT:BURST - Optional. -If left empty, TCP connection requests from the SOURCE zone -to the DEST zone will not be rate-limited. Otherwise, this -column specifies the maximum rate at which TCP connection requests will -be accepted followed by a colon (":") followed by the maximum burst size -that will be tolerated. Example: 10/sec:40 specifies that -the maximum rate of TCP connection requests allowed will be 10 per second -and a burst of 40 connections will be tolerated. Connection requests in -excess of these limits will be dropped.
    6. - - -
- - -

In the SOURCE and DEST columns, you can enter "all" to indicate all - zones. 

- - -

The policy file installed by default is as follows:

- - -
- - +
+ - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
-
- - -

This table may be interpreted as follows:

- -
    -
  • All connection requests from the local network to hosts on -the internet are accepted.
    • -
  • All connection requests originating from the internet are -ignored and logged at level KERNEL.INFO.
    • -
  • All other connection requests are rejected and logged.
    • - -
- -

WARNING:

- -

The firewall script processes  the - /etc/shorewall/policy file from top to bottom and uses the first -applicable policy that it finds. For example, in the following -policy file, the policy for (loc, loc) connections would be ACCEPT as - specified in the first entry even though the third entry in the file specifies - REJECT.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT  
netallDROPinfo 
loclocREJECTinfo 
-
- -

- The CONTINUE policy

- -

Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones to be managed - under the rules of all of these zones. Let's look at an example:

- -

/etc/shorewall/zones:

- -
- - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - +
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918
-eth1detect 
-
- -

/etc/shorewall/interfaces:

- -
+
+ + +

The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.

+ + +

Your /etc/shorewall/hosts file might look like:

+ + +
+ + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - - +
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,noping,norfc1918
loceth1detectroutestopped
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25 
loc2eth1:192.168.1.128/25routestopped
-
- -

/etc/shorewall/hosts:

- -
- +
+ + +

Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.

+ + +

Nested and Overlapping Zones

+ + +

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow +you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that they +appear in the /etc/shorewall/zones file. So if you have nested zones, +you want the sub-zone to appear before the super-zone and in the case +of overlapping zones, the rules that will apply to hosts that belong +to both zones is determined by which zone appears first in /etc/shorewall/zones.

+ + +

Hosts that belong to more than one zone may be managed by the rules + of all of those zones. This is done through use of the special CONTINUE policy described below.

+ + +

+ /etc/shorewall/policy Configuration.

+ + +

This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in terms of +clients who initiate connections and servers who receive + those connection requests. Policies defined in /etc/shorewall/policy +describe which zones are allowed to establish connections with other +zones.

+ + +

Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to a particular + connection request then the policy from /etc/shorewall/policy is applied.

+ + +

Four policies are defined:

+ + +
    +
  • ACCEPT - The connection is allowed.
    • +
  • DROP - The connection request is ignored.
    • +
  • REJECT - The connection request is rejected +with an RST (TCP) or an ICMP destination-unreachable packet being +returned to the client.
    • +
  • CONTINUE - The connection is neither ACCEPTed, + DROPped nor REJECTed. CONTINUE may be used when one or both of the + zones named in the entry are sub-zones of or intersect with another + zone. For more information, see below. 
    • + +
+ + +

For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that the + policy is applied.

+ + +

Entries in /etc/shorewall/policy have four columns as follows:

+ + +
    + +
  1. SOURCE - The name +of a client zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or + "all").
    2. + +
  2. DEST - The name of + a destination zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or +"all"). Shorewall automatically allows all traffic from the firewall to +itself so the name of the firewall zone cannot appear +in both the SOURCE and DEST columns.
    3. + +
  3. POLICY - The default + policy for connection requests from the SOURCE zone to the DESTINATION + zone.
    4. + +
  4. LOG LEVEL - Optional. + If left empty, no log message is generated when the policy is applied. + Otherwise, this column should contain an integer or name indicating + a syslog level.
    5. + +
  5. LIMIT:BURST - Optional. + If left empty, TCP connection requests from the SOURCE zone + to the DEST zone will not be rate-limited. Otherwise, this + column specifies the maximum rate at which TCP connection requests + will be accepted followed by a colon (":") followed by the maximum burst + size that will be tolerated. Example: 10/sec:40 specifies +that the maximum rate of TCP connection requests allowed will be 10 per +second and a burst of 40 connections will be tolerated. Connection requests +in excess of these limits will be dropped.
    6. + + +
+ + +

In the SOURCE and DEST columns, you can enter "all" to indicate all + zones. 

+ + +

The policy file installed by default is as follows:

+ + +
+ + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - +
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0 
sameth0:206.191.149.197routestopped
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
-
+
+ + +

This table may be interpreted as follows:

+ +
    +
  • All connection requests from the local network to hosts + on the internet are accepted.
    • +
  • All connection requests originating from the internet +are ignored and logged at level KERNEL.INFO.
    • +
  • All other connection requests are rejected and logged.
    • + +
-

Note that Sam's home system is a member of both the sam zone - and the net zone and as described above , that means that sam must -be listed before net  in /etc/shorewall/zones.

+

WARNING:

-

/etc/shorewall/policy:

+

The firewall script processes  the + /etc/shorewall/policy file from top to bottom and uses the first + applicable policy that it finds. For example, in the following + policy file, the policy for (loc, loc) connections would be ACCEPT as + specified in the first entry even though the third entry in the file +specifies REJECT.

-
- + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - +
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT 
samallCONTINUE 
netallDROPinfo
allallREJECTinfo
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT  
netallDROPinfo 
loclocREJECTinfo 
-
+ -

The second entry above says that when Sam is the client, connection - requests should first be process under rules where the source zone is - sam and if there is no match then the connection request should be - treated under rules where the source zone is net. It is important - that this policy be listed BEFORE the next policy (net to all).

+

+ The CONTINUE policy

-

Partial /etc/shorewall/rules:

+

Where zones are nested or overlapping , the + CONTINUE policy allows hosts that are within multiple zones to be managed + under the rules of all of these zones. Let's look at an example:

-
- +

/etc/shorewall/zones:

+ +
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
...      
DNATsamloc:192.168.1.3tcpssh- 
DNATnetloc:192.168.1.5tcpwww- 
...      
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
+
+ +

/etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,noping,norfc1918
loceth1detectroutestopped
+
+ +

/etc/shorewall/hosts:

+ +
+ + + + + + + + + + + + + + + + + + + + +
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0 
sameth0:206.191.149.197routestopped
-
- -

Given these two rules, Sam can connect to the firewall's internet interface - with ssh and the connection request will be forwarded to 192.168.1.3. - Like all hosts in the net zone, Sam can connect to the firewall's - internet interface on TCP port 80 and the connection request will be forwarded - to 192.168.1.5. The order of the rules is not significant.

- -

Sometimes it is necessary to suppress port forwarding - for a sub-zone. For example, suppose that all hosts can SSH to the firewall - and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the - firewall's external IP, he should be connected to the firewall itself. - Because of the way that Netfilter is constructed, this requires two -rules as follows:

- -
- -

 

- + +

Note that Sam's home system is a member of both the sam zone + and the net zone and + as described above , that means that sam +must be listed before net  in /etc/shorewall/zones.

+ +

/etc/shorewall/policy:

+ +
- + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
       
...      
DNATsamfwtcpssh- 
DNATnet!samloc:192.168.1.3tcpssh- 
...      
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT 
samallCONTINUE 
netallDROPinfo
allallREJECTinfo
-
+ + + + +
+ +

The second entry above says that when Sam is the client, connection + requests should first be process under rules where the source zone +is sam and if there is no match then the connection request should + be treated under rules where the source zone is net. It is important + that this policy be listed BEFORE the next policy (net to all).

+ +

Partial /etc/shorewall/rules:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
...      
DNATsamloc:192.168.1.3tcpssh- 
DNATnetloc:192.168.1.5tcpwww- 
...      
+
+ +

Given these two rules, Sam can connect to the firewall's internet interface + with ssh and the connection request will be forwarded to 192.168.1.3. + Like all hosts in the net zone, Sam can connect to the firewall's + internet interface on TCP port 80 and the connection request will be + forwarded to 192.168.1.5. The order of the rules is not significant.

+ +

Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can SSH to the + firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects + to the firewall's external IP, he should be connected to the firewall + itself. Because of the way that Netfilter is constructed, this requires + two rules as follows:

+ +
+ +

 

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
       
...      
DNATsamfwtcpssh- 
DNATnet!samloc:192.168.1.3tcpssh- 
...      
+
+

The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the @@ -1164,318 +1207,334 @@ rules as follows:

connection port forwarded to 192.168.1.3. If you need to exclude more than one zone in this way, - you can list the zones separated - by commas (e.g., net!sam,joe,fred). - This technique also may be - used when the ACTION is REDIRECT.

+ you can list the zones separated + by commas (e.g., net!sam,joe,fred). + This technique also may +be used when the ACTION is +REDIRECT.

- +

/etc/shorewall/rules

- +

The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules - for each of these rules. 
-

-

Shorewall automatically enables firewall->firewall traffic over the -loopback interface (lo) -- that traffic cannot be regulated using rules and -any rule that tries to regulate such traffic will generate a warning and -will be ignored.
-

- - - -

Entries in the file have the following columns:

- -
    -
  • ACTION -
      -
    • ACCEPT, DROP or REJECT. These have the same meaning here -as in the policy file above.
      • -
    • DNAT -- Causes the connection request to be forwarded to -the system specified in the DEST column (port forwarding). "DNAT" -stands for "Destination Network Address Translation"
      • -
    • REDIRECT -- Causes the connection request to be redirected - to a port on the local (firewall) system.
      • - -
    - -

    The ACTION may optionally be followed by ":" and a syslogd log - level (example: REJECT:info). This causes the packet to be logged at - the specified level prior to being processed according to the specified - ACTION.
    -
    - The use of DNAT or REDIRECT requires that you have NAT enabled.
    -  

    -
    • -
  • SOURCE - Describes the source hosts to which the rule -applies.. The contents of this field must begin with the name of -a zone defined in /etc/shorewall/zones, $FW or "all". If the ACTION -is DNAT or REDIRECT, sub-zones may be excluded from the rule by following -the initial zone name with "!' and a comma-separated list of those -sub-zones to be excluded. There is an example above.
    -
    - If the source is not 'all' then the source may be further restricted -by adding a colon (":") followed by a comma-separated list of qualifiers. -Qualifiers are may include: - -
      -
    • An interface name - refers to any connection requests arriving - on the specified interface (example loc:eth4). Beginning with - Shorwall 1.3.9, the interface name may optionally be followed by a colon -(":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
      • -
    • An IP address - refers to a connection request from the -host with the specified address (example net:155.186.235.151). -If the ACTION is DNAT, this must not be a DNS name.
      • -
    • A MAC Address in Shorewall format.
      • -
    • A subnet - refers to a connection request from any host -in the specified subnet (example net:155.186.235.0/24).
      • - -
    -
    • -
  • DEST - Describes the destination host(s) to which the - rule applies. May take any of the forms described above for SOURCE - plus the following two additional forms: + in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules + for each of these rules. 
    +

    +

    Shorewall automatically enables firewall->firewall traffic over the + loopback interface (lo) -- that traffic cannot be regulated using rules +and any rule that tries to regulate such traffic will generate a warning +and will be ignored.
    +

    + + + +

    Entries in the file have the following columns:

    + +
      +
    • ACTION +
        -
      • An IP address followed by a colon and the port number - that the server is listening on (service names from /etc/services - are not allowed - example loc:192.168.1.3:80).
        -
        • -
      • A single port number (again, service names are not allowed) - -- this form is only allowed if the ACTION is REDIRECT and refers - to a server running on the firewall itself and listening on the - specified port.
        -
        • - +
      • ACCEPT, DROP or REJECT. These have the same meaning +here as in the policy file above.
        • +
      • DNAT -- Causes the connection request to be forwarded + to the system specified in the DEST column (port forwarding). +"DNAT" stands for "Destination Network Address + Translation"
        • +
      • REDIRECT -- Causes the connection request to be redirected + to a port on the local (firewall) system.
        • +
      -
      • -
    • PROTO - Protocol. Must be a protocol name from /etc/protocols, - a number, "all" or "related". Specifies the protocol of the connection - request. "related" should be specified only if you have given ALLOWRELATED="no" - in /etc/shorewall/shorewall.conf and you wish to override that setting - for related connections originating with the client(s) and server(s) - specified in this rule. When "related" is given for the protocol, - the remainder of the columns should be left blank.
      • -
    • DEST PORT(S) - Port or port range (<low port>:<high - port>) being connected to. May only be specified if the protocol - is tcp, udp or icmp. For icmp, this column's contents are interpreted - as an icmp type. If you don't want to specify DEST PORT(S) but need - to include information in one of the columns to the right, enter - "-" in this column. You may give a list of ports and/or port ranges - separated by commas. Port numbers may be either integers or service names - from /etc/services.
      • -
    • SOURCE PORTS(S) - May be used to restrict - the rule to a particular client port or port range (a port range is - specified as <low port number>:<high port number>). If -you don't want to restrict client ports but want to specify something -in the next column, enter "-" in this column. If you wish to specify -a list of port number or ranges, separate the list elements with commas - (with no embedded white space). Port numbers may be either integers -or service names from /etc/services.
      • -
    • ORIGINAL DEST - This column may only be non-empty if - the ACTION is DNAT or REDIRECT.
      -
      - If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column -is left empty, any connection request arriving at the firewall from -the SOURCE that matches the rule will be forwarded or redirected. This - works fine for connection requests arriving from the internet where - the firewall has only a single external IP address. When the firewall - has multiple external IP addresses or when the SOURCE is other than - the internet, there will usually be a desire for the rule to only apply - to those connection requests directed to a particular IP address (see - Example 2 below for another usage). That IP address (or a comma-separated + +

      The ACTION may optionally be followed by ":" and a syslog +level (example: REJECT:info). This causes the packet to be logged + at the specified level prior to being processed according to the specified + ACTION.
      +
      + The use of DNAT or REDIRECT requires that you have NAT enabled.
      +  

      +
      • +
    • SOURCE - Describes the source hosts to which the +rule applies.. The contents of this field must begin with the +name of a zone defined in /etc/shorewall/zones, $FW or "all". If the + ACTION is DNAT or REDIRECT, sub-zones may be excluded from the rule +by following the initial zone name with "!' and a comma-separated +list of those sub-zones to be excluded. There is an example above.
      +
      + If the source is not 'all' then the source may be further +restricted by adding a colon (":") followed by a comma-separated +list of qualifiers. Qualifiers are may include: + +
        +
      • An interface name - refers to any connection requests + arriving on the specified interface (example loc:eth4). Beginning + with Shorwall 1.3.9, the interface name may optionally be followed by +a colon (":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, + net:eth0:192.0.2.0/24).
        • +
      • An IP address - refers to a connection request from +the host with the specified address (example net:155.186.235.151). + If the ACTION is DNAT, this must not be a DNS name.
        • +
      • A MAC Address in Shorewall format.
        • +
      • A subnet - refers to a connection request from any host + in the specified subnet (example net:155.186.235.0/24).
        • + +
      +
      • +
    • DEST - Describes the destination host(s) to which + the rule applies. May take any of the forms described above for + SOURCE plus the following two additional forms: + +
        +
      • An IP address followed by a colon and the port number + that the server is listening on (service names from /etc/services + are not allowed - example loc:192.168.1.3:80).
        +
        • +
      • A single port number (again, service names are not allowed) + -- this form is only allowed if the ACTION is REDIRECT and refers + to a server running on the firewall itself and listening on +the specified port.
        +
        • + +
      +
      • +
    • PROTO - Protocol. Must be a protocol name from + /etc/protocols, a number, "all" or "related". Specifies the protocol + of the connection request. "related" should be specified only +if you have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf +and you wish to override that setting for related connections originating + with the client(s) and server(s) specified in this rule. When "related" + is given for the protocol, the remainder of the columns should +be left blank.
      • +
    • DEST PORT(S) - Port or port range (<low + port>:<high port>) being connected to. May only be specified + if the protocol is tcp, udp or icmp. For icmp, this column's +contents are interpreted as an icmp type. If you don't want to specify + DEST PORT(S) but need to include information in one of the columns +to the right, enter "-" in this column. You may give a list of ports +and/or port ranges separated by commas. Port numbers may be either integers + or service names from /etc/services.
      • +
    • SOURCE PORTS(S) - May be used to restrict + the rule to a particular client port or port range (a port range +is specified as <low port number>:<high port number>). +If you don't want to restrict client ports but want to specify something + in the next column, enter "-" in this column. If you wish to specify + a list of port number or ranges, separate the list elements with +commas (with no embedded white space). Port numbers may be either +integers or service names from /etc/services.
      • +
    • ORIGINAL DEST - This column may only be non-empty + if the ACTION is DNAT or REDIRECT.
      +
      + If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column + is left empty, any connection request arriving at the firewall from + the SOURCE that matches the rule will be forwarded or redirected. +This works fine for connection requests arriving from the internet +where the firewall has only a single external IP address. When the +firewall has multiple external IP addresses or when the SOURCE is other +than the internet, there will usually be a desire for the rule to only +apply to those connection requests directed to a particular IP address +(see Example 2 below for another usage). That IP address (or a comma-separated list of such addresses) is specified in the ORIGINAL DEST column.
      -
      - The IP address may be optionally followed by ":" and a second - IP address. This latter address, if present, is used as the source - address for packets forwarded to the server (This is called "Source NAT" -or SNAT).
      -
      - + The IP address may be optionally followed by ":" and a + second IP address. This latter address, if present, is used as the source + address for packets forwarded to the server (This is called "Source +NAT" or SNAT).
      +
      + Note:  When using SNAT, it is a good idea to qualify the source with an IP address or subnet. Otherwise, it is likely that SNAT will occur on connections other than those described in the rule. The reason for this is that SNAT occurs in the Netfilter POSTROUTING hook where it is not possible to restrict the scope of a rule by incoming interface.
      -
      -       Example: DNAT     loc:192.168.1.0/24    loc:192.168.1.3    - tcp    www    -    206.124.146.179:192.168.1.3
      -
      -       If SNAT is not used (no ":" and second IP address), -the original source address is used. If you want any destination -address to match the rule but want to specify SNAT, simply use a colon -followed by the SNAT address.
      • - +
      +       Example: DNAT     loc:192.168.1.0/24    + loc:192.168.1.3    tcp    www    -    206.124.146.179:192.168.1.3
      +
      +       If SNAT is not used (no ":" and second IP address), + the original source address is used. If you want any destination + address to match the rule but want to specify SNAT, simply use a +colon followed by the SNAT address. +
    - +

    Example 1. You wish to forward all - ssh connection requests from the internet to local system 192.168.1.3. 

    - + ssh connection requests from the internet to local system 192.168.1.3. 

    + +
    - + - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    DNATnetloc:192.168.1.3tcpssh  
    -
    - -

    Example 2. 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. This example shows yet - another use for the ORIGINAL - DEST column; here, connection - requests that were NOT - - (notice the "!") originally - destined to 206.124.146.177 - are redirected to local - port 3128.

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww !206.124.146.177
    ACCEPTfwnettcpwww  
    -
    - - -

    Example 3. You want to run a web server at 155.186.235.222 in -your DMZ and have it accessible remotely and locally. the DMZ is managed - by Proxy ARP or by classical sub-netting.

    - - -
    - - - + - - - - - - - + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + - + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST    		ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTnetdmz:155.186.235.222tcpwww- 
    ACCEPTlocdmz:155.186.235.222tcpwww  
    DNATnetloc:192.168.1.3tcpssh  
    -
    +
- + +

Example 2. 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. This example shows yet + another use for the ORIGINAL + DEST column; here, connection + requests that were NOT + (notice +the "!") originally + destined to 206.124.146.177 are + redirected to local port 3128.

+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
REDIRECTloc3128tcpwww !206.124.146.177
ACCEPTfwnettcpwww  
+
+ + +

Example 3. You want to run a web server at 155.186.235.222 in +your DMZ and have it accessible remotely and locally. the DMZ is managed + by Proxy ARP or by classical sub-netting.

+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
ACCEPTnetdmz:155.186.235.222tcpwww- 
ACCEPTlocdmz:155.186.235.222tcpwww  
+
+ +

Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 and you want - the FTP server to be accessible from the internet in addition to the -local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that since -the server is in the 192.168.2.0/24 subnetwork, we can assume that access - to the server from that subnet will not involve the firewall (but see FAQ 2). Note that unless you - have more than one external - IP address, you can leave + DMZ. Your internet interface address is 155.186.235.151 and you want + the FTP server to be accessible from the internet in addition to the + local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that + since the server is in the 192.168.2.0/24 subnetwork, we can assume +that access to the server from that subnet will not involve the firewall +(but see FAQ 2). Note that unless you + have more than one external + IP address, you can leave the ORIGINAL DEST column blank in the first rule. You cannot @@ -1491,82 +1550,85 @@ leave it blank in the clearly not what you want - .

+ .

- +
- + - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
DNATnetdmz:192.168.2.2tcpftp  
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
DNATnetdmz:192.168.2.2tcpftp  
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
-
+ - +

If you are running wu-ftpd, you should restrict the range of passive in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions - so I use port range 65500-65535. In /etc/ftpaccess, this entry is appropriate:

+ so I use port range 65500-65535. In /etc/ftpaccess, this entry is +appropriate:

- +
- + +

passive ports  0.0.0.0/0 65500 65534

-
+ - +

If you are running pure-ftpd, you would include "-p 65500:65534" on - the pure-ftpd runline.

+ the pure-ftpd runline.

- +

The important point here is to ensure that the port range used for FTP - passive connections is unique and will not overlap with any usage on -the firewall system.

+ passive connections is unique and will not overlap with any usage on + the firewall system.

- +

Example 5. You wish to allow unlimited DMZ access to the host @@ -1574,97 +1636,101 @@ the firewall system.

02:00:08:E3:FA:55.

- +
- + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall   
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall   
-
+ - Example 6. You wish to -allow access to the SMTP server in your DMZ from all zones.
-
+ Example 6. You wish + to allow access to the SMTP server in your DMZ from all zones.
+ +
- - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
-PORTS(S)
- 		SOURCE
-PORT(S)
- 		ORIGINAL
-DEST
-
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORTS(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		all
+ 		dmz
+ 		tcp
+ 		25
+
+
+
-
-Note: When 'all' is used as a source or destination, intra-zone traffic is -not affected. In this example, if there were two DMZ interfaces then the -above rule would NOT enable SMTP traffic between hosts on these interfaces.
+
+ Note: When 'all' is used as a source or destination, intra-zone traffic + is not affected. In this example, if there were two DMZ interfaces then the + above rule would NOT enable SMTP traffic between hosts on these interfaces.
+

Look here for information on other services.

- +

/etc/shorewall/common

- +

Shorewall allows definition of rules that apply between all zones. @@ -1674,163 +1740,167 @@ above rule would NOT enable SMTP traffic between hosts on these interfaces. + than modify + /etc/shorewall/common.def, + you should copy + that file to + /etc/shorewall/common + and modify that + file.

- +

The /etc/shorewall/common - file is expected - to contain iptables - commands; rather - than running iptables - directly, you -should run it -indirectly using the - Shorewall function 'run_iptables'. - That way, if iptables - encounters an error, the - firewall will be safely - stopped.

+ file is expected + to contain iptables + commands; rather + than running + iptables directly, + you should run + it indirectly using the + Shorewall function 'run_iptables'. + That way, if iptables + encounters an error, the + firewall will be safely + stopped.

- +

/etc/shorewall/masq

- +

The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation  (SNAT). There is one entry in -the file for each subnet that you want to masquerade. In order to make -use of this feature, you must have NAT enabled - .

+ and Source Network Address Translation  (SNAT). There is one entry in + the file for each subnet that you want to masquerade. In order to make + use of this feature, you must have NAT enabled + .

- +

Columns are:

- +
    -
  • INTERFACE - The interface that will masquerade the - subnet; this is normally your internet interface. This interface -name can be optionally qualified by adding ":" and a subnet or host -IP. When this qualification is added, only packets addressed to that -host or subnet will be masqueraded.
    • -
  • SUBNET - The subnet that you want to have masqueraded - through the INTERFACE. This may be expressed as a single IP address, - a subnet or an interface name. In the latter instance, the interface - must be configured and started before Shorewall is started as Shorewall - will determine the subnet based on information obtained from the 'ip' - utility.
    -
    - The subnet may be optionally followed by "!' and a comma-separated - list of addresses and/or subnets that are to be excluded from masquerading.
    • -
  • ADDRESS - The source address to be used for outgoing - packets. This column is optional and if left blank, the current primary - IP address of the interface in the first column is used. If you have - a static IP on that interface, listing it here makes processing of output - packets a little less expensive for the firewall.
    • - +
  • INTERFACE - The interface that will masquerade + the subnet; this is normally your internet interface. This interface + name can be optionally qualified by adding ":" and a subnet or host + IP. When this qualification is added, only packets addressed to +that host or subnet will be masqueraded.
    • +
  • SUBNET - The subnet that you want to have masqueraded + through the INTERFACE. This may be expressed as a single IP address, + a subnet or an interface name. In the latter instance, the interface + must be configured and started before Shorewall is started as Shorewall + will determine the subnet based on information obtained from the 'ip' + utility.
    +
    + The subnet may be optionally followed by "!' and a comma-separated + list of addresses and/or subnets that are to be excluded from masquerading.
    • +
  • ADDRESS - The source address to be used for +outgoing packets. This column is optional and if left blank, the current + primary IP address of the interface in the first column is used. If +you have a static IP on that interface, listing it here makes processing +of output packets a little less expensive for the firewall.
    • +
- +

Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq - file would look like:    

+ connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like:    

- +
- + - - - - - - - - - - - + + + + + + + + + + + + - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24 
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24 
-
- - -

Example 2: You have a number of IPSEC tunnels through ipsec0 - and you want to masquerade traffic from your 192.168.9.0/24 subnet to - the remote subnet 10.1.0.0/16 only.

- - -
- - - - - - - - - - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24 
-
- - -

Example 3: You have a DSL line connected on eth0 and a local - network (192.168.10.0/24) - connected to - eth1. You want - all local->net - connections to use - source address - 206.124.146.176.

- -
- - - - - - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
-
- + + + + + + + + +

Example 2: You have a number of IPSEC tunnels through ipsec0 + and you want to masquerade traffic from your 192.168.9.0/24 subnet + to the remote subnet 10.1.0.0/16 only.

+ + +
+ + + + + + + + + + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24 
+
+ + +

Example 3: You have a DSL line connected on eth0 and a local + network (192.168.10.0/24) + connected +to eth1. You + want all local->net + connections to use + source address + 206.124.146.176.

+ +
+ + + + + + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
+
+ +

Example 4: Same as example 3 except that you wish @@ -1840,35 +1910,36 @@ host or subnet will be masqueraded. the SNAT rule.

- +
- + - - - - - - - - - - - + + + + + + + + + + + + - - + +
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
-
+ - +

/etc/shorewall/proxyarp

- +

If you want to use proxy ARP on an entire sub-network, @@ -1877,30 +1948,30 @@ host or subnet will be masqueraded. http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide - to use the - technique described - in that HOWTO, - you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by including -the proxyarp - option in -the interface's - record in - - /etc/shorewall/interfaces. - When using Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp. -

+ If you decide + to use +the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by including + the proxyarp + option in + the interface's + record in + + /etc/shorewall/interfaces. + When using Proxy ARP + sub-netting, you do + NOT include + any entries in + /etc/shorewall/proxyarp. +

- +

The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -1908,47 +1979,48 @@ the interface's on a small set of systems since you need one entry - in this file - for each system - using proxy - ARP. Columns are:

- + in this +file for each + system using proxy + ARP. Columns are:

+
    -
  • ADDRESS - address of the system.
    • -
  • INTERFACE - the interface that connects to the system. - If the interface is obvious from the subnetting, you may enter "-" - in this column.
    • -
  • EXTERNAL - the external interface that you want -to honor ARP requests for the ADDRESS specified in the first column.
    • -
  • HAVEROUTE - If - you already have - a route through - INTERFACE to - ADDRESS, this - column should - contain - "Yes" - or - "yes". - If you want - Shorewall to add - the route, the - column should - contain - "No" - or - "no".
    • - +
  • ADDRESS - address of the system.
    • +
  • INTERFACE - the interface that connects to the + system. If the interface is obvious from the subnetting, you may + enter "-" in this column.
    • +
  • EXTERNAL - the external interface that you want + to honor ARP requests for the ADDRESS specified in the first column.
    • +
  • HAVEROUTE - If + you already have + a route through + INTERFACE to + ADDRESS, this + column should + contain + "Yes" + or + "yes". + If you want + Shorewall to add + the route, the + column should + contain + "No" + or + "no".
    • +
- +

Note: After you have made a change to the /etc/shorewall/proxyarp - file, you may need to flush the ARP cache of all routers on the LAN segment - connected to the interface specified in the EXTERNAL column of the change/added - entry(s). If you are having problems communicating between an individual - host (A) on that segment and a system whose entry has changed, you may - need to flush the ARP cache on host A as well.

+ file, you may need to flush the ARP cache of all routers on the LAN + segment connected to the interface specified in the EXTERNAL column +of the change/added entry(s). If you are having problems communicating + between an individual host (A) on that segment and a system whose entry + has changed, you may need to flush the ARP cache on host A as well.

- + +

ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may take a long @@ -1957,95 +2029,95 @@ to delete a stale entry in order to restore a system to working order after changing my proxy ARP settings.

- +

Example: You have public IP addresses 155.182.235.0/28. You configure your - firewall as follows:

- + firewall as follows:

+
    -
  • eth0 - 155.186.235.1 (internet connection)
    • -
  • eth1 - 192.168.9.0/24 (masqueraded local systems)
    • -
  • eth2 - 192.168.10.1 (interface to your DMZ)
    • - +
  • eth0 - 155.186.235.1 (internet connection)
    • +
  • eth1 - 192.168.9.0/24 (masqueraded local systems)
    • +
  • eth2 - 192.168.10.1 (interface to your DMZ)
    • +
- +

In your DMZ, you want to install a Web/FTP server with public address - 155.186.235.4. On the Web server, you subnet just like the firewall's - eth0 and you configure 155.186.235.1 as the default gateway. In your - /etc/shorewall/proxyarp file, you will have:

+ 155.186.235.4. On the Web server, you subnet just like the firewall's + eth0 and you configure 155.186.235.1 as the default gateway. In your + /etc/shorewall/proxyarp file, you will have:

- +
- + - + - - - - - - - - - - - - + + + + + + + + + + + + - + - +
ADDRESS INTERFACE EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
ADDRESS INTERFACE EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
-
- + +

Note: You may want to configure the servers in your DMZ with a subnet - that is smaller than the subnet of your internet interface. See the -Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) - for details. In this case you will want to place "Yes" in the HAVEROUTE - column.

- + for details. In this case you will want to place "Yes" in the HAVEROUTE + column.

+

To learn how I use Proxy ARP in my DMZ, see my configuration files.

- +

Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. - If you start or restart Shorewall with an IPSEC tunnel active, the proxied - IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) - rather than to the interface that you specify in the INTERFACE column -of /etc/shorewall/proxyarp. I haven't had the time to debug this problem -so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

- + If you start or restart Shorewall with an IPSEC tunnel active, the proxied + IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) + rather than to the interface that you specify in the INTERFACE column + of /etc/shorewall/proxyarp. I haven't had the time to debug this problem + so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

+

You might be able to work around this problem using the following - (I haven't tried it):

- + (I haven't tried it):

+

In /etc/shorewall/init, include:

- +

     qt service ipsec stop

- +

In /etc/shorewall/start, include:

- +

    qt service ipsec start

- +

/etc/shorewall/nat

- +

The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that you wish to -define. In order to make use of this feature, you must have NAT enabled .

- +

IMPORTANT: If @@ -2057,605 +2129,642 @@ define. In order to make use of this feature, you must have - rules file. - Also, in most - cases - - Proxy ARP - provides a - superior solution - to static NAT - because the - internal systems - are accessed using - the same IP - address internally - and externally.

+ with simple + entries in + the + rules file. + Also, in most + cases + + Proxy ARP + provides a + superior solution + to static NAT + because the + internal systems + are accessed using + the same IP + address internally + and externally.

- +

Columns in an entry are:

- +
    -
  • EXTERNAL - External IP address - This should -NOT be the primary IP address of the interface named in the next column.
    • -
  • INTERFACE - Interface that you want the EXTERNAL -IP address to appear on.
    • -
  • INTERNAL - Internal IP address.
    • -
  • ALL - INTERFACES - - If Yes - or yes (or - left - empty), - NAT will - be - effective - from all - hosts. - If - No or no - then NAT - will be - effective - only - through - the - interface - named in - the - INTERFACE - column. Note: - If two or more NATed systems are connected to the same firewall interface - and you want them to be able to communicate using their EXTERNAL IP - addresses, then you will want to specify the multi option in the - /etc/shorewall/interface entry for that interface.
    • -
  • LOCAL - If Yes or yes and the ALL INTERFACES column -contains Yes or yes, NAT will be effective from the firewall system. - Note: For this to work, you must be running kernel 2.4.19 -or later and iptables 1.2.6a or later and you must have enabled  CONFIG_IP_NF_NAT_LOCAL - in your kernel.
    • - +
  • EXTERNAL - External IP address - This should + NOT be the primary IP address of the interface named in the next +column.
    • +
  • INTERFACE - Interface that you want the EXTERNAL + IP address to appear on.
    • +
  • INTERNAL - Internal IP address.
    • +
  • ALL + INTERFACES + - If Yes + or yes (or + left + empty), + NAT will + be + effective + from +all + hosts. If + No or no + then NAT + will be + effective + only + through + the + interface + named in + the + INTERFACE + column. + Note: If two or more NATed systems are connected to the +same firewall interface and you want them to be able to communicate +using their EXTERNAL IP addresses, then you will want to specify the + multi option in the /etc/shorewall/interface +entry for that interface.
    • +
  • LOCAL - If Yes or yes and the ALL INTERFACES column + contains Yes or yes, NAT will be effective from the firewall system. + Note: For this to work, you must be running kernel +2.4.19 or later and iptables 1.2.6a or later and you must have enabled  + CONFIG_IP_NF_NAT_LOCAL in your kernel.
    • +
- +

Look here for additional information and an example. -

+

- +

/etc/shorewall/tunnels

- +

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP - and PPTP tunnels with end-points on your firewall. To use ipsec, you must - install version 1.9, 1.91 or the current FreeS/WAN development snapshot. 

- +

Note: For kernels 2.4.4 and above, you will need to use version 1.91 - or a development snapshot as patching with version 1.9 results in kernel - compilation errors.

+ or a development snapshot as patching with version 1.9 results in +kernel compilation errors.

- +

Instructions for setting up IPSEC tunnels may - be found here, instructions for IPIP and - GRE tunnels are here  and instructions -for PPTP tunnels are here.

- -

/etc/shorewall/shorewall.conf

+ be found here, instructions for IPIP +and GRE tunnels are here  and instructions + for PPTP tunnels are here.

+ +

/etc/shorewall/shorewall.conf

- +

This file is used to set the following firewall parameters:

- +
    -
  • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
    -Determines the disposition of TCP packets that fail the checks enabled by -the tcpflags interface option and must have -a value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP -(ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") -then TCP_FLAGS_DISPOSITION=DROP is assumed.
    • -
  • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
    -Determines the syslogd log level for logging packets that fail the checks -enabled by the tcpflags interface option.The value -must be a valid syslogd log level. If you don't want to log these packets, - set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
    +
  • MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
    +If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes +to cause the marking specified in the tcrules file to occur in that chain +rather than in the PREROUTING chain. This permits you to mark inbound traffic +based on its destination address when SNAT or Masquerading are in use. To +determine if your kernel has a FORWARD chain in the mangle table, use the +"/sbin/shorewall show mangle" command; if a FORWARD chain is displayed then +your kernel will support this option. If this option is not specified or +if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No +is assumed.
    • -
  • MACLIST_DISPOSITION - Added in Version 1.3.10
    - Determines the disposition of connections requests that fail RFC1918_LOG_LEVEL - Added at version 1.3.12
    + This parameter determines the level at which packets logged under the     'norfc1918' +mechanism  are logged. The value must be a valid syslog +level and if no level is given, then info is assumed. Prior to Shorewall +version 1.3.12, these packets are always logged at the info level.
    • +
  • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
    +Determines the disposition of TCP packets that fail the checks enabled by + the tcpflags interface option and must have + a value of ACCEPT (accept the packet), REJECT (send an RST response) or +DROP (ignore the packet). If not set or if set to the empty value (e.g., +TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
    • +
  • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
    + Determines the syslog +level for logging packets that fail the checks enabled by the tcpflags interface option.The value must be a valid +syslogd log level. If you don't want to log these packets, set to the empty +value (e.g., TCP_FLAGS_LOG_LEVEL="").
    +
    • +
  • MACLIST_DISPOSITION - Added in Version 1.3.10
    + Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT (accept the connection request anyway), REJECT (reject the connection request) or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
    • -
  • MACLIST_LOG_LEVEL - Added in Version 1.3.10
    - Determines the syslogd log level for logging connection requests that -fail MAC Verification. The value must -be a valid syslogd log level. If you don't want to log these connection -requests, set to the empty value (e.g., MACLIST_LOG_LEVEL="").
    -
    • -
  • NEWNOTSYN - Added in Version 1.3.8
    - When set to "Yes" or "yes", Shorewall will filter TCP packets that -are not part of an established connention and that are not SYN packets -(SYN flag on - ACK flag off). If set to "No", Shorewall will silently drop -such packets. If not set or set to the empty value (e.g., "NEWNOTSYN="), -NEWNOTSYN=No is assumed.
    -
    - If you have a HA setup with failover to another firewall, you should - have NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes - if you have asymmetric routing.
    -
    • -
  • FORWARDPING - Added in Version 1.3.7
    - When set to "Yes" or "yes", ICMP echo-request (ping) packets from - interfaces that specify "filterping" are ACCEPTed by the firewall. -When set to "No" or "no", such ping requests are silently dropped unless - they are handled by an explicit entry in the rules -file. If not specified, "No" is assumed.
    • -
  • LOGNEWNOTSYN - Added in Version 1.3.6
    - Beginning with version 1.3.6, Shorewall drops non-SYN TCP packets - that are not part of an existing connection. If you would like to -log these packets, set LOGNEWNOTSYN to the syslog level at which you -want the packets logged. Example: LOGNEWNOTSYN=debug|
    -
    - Note: Packets logged under this option are usually the -result of broken remote IP stacks rather than the result of any sort -of attempt to breach your firewall.
    -  
    • -
  • MERGE_HOSTS - Added in Version 1.3.5
    - Prior to 1.3.5, when the /etc/shorewall/hosts - file included an entry for a zone then the entire zone had to be defined - in the /etc/shorewall/hosts file and any associations between the zone - and interfaces in the /etc/shorewall/interfaces - file were ignored. This behavior is preserved if MERGE_HOSTS=No or -if MERGE_HOSTS is not set or is set to the empty value.
    -
    - Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone assignments - in the /etc/shorewall/hosts file are ADDED to those in the /etc/shorewall/interfaces - file.
    -
    - Example:
    -
    - Interfaces File:
    -   +
  • MACLIST_LOG_LEVEL - Added in Version 1.3.10
    + Determines the syslog +level for logging connection requests that fail MAC Verification. The value must be a valid +syslogd log level. If you don't want to log these connection requests, set +to the empty value (e.g., MACLIST_LOG_LEVEL="").
    +
    • +
  • NEWNOTSYN - Added in Version 1.3.8
    + When set to "Yes" or "yes", Shorewall will filter TCP packets that + are not part of an established connention and that are not SYN packets + (SYN flag on - ACK flag off). If set to "No", Shorewall will silently +drop such packets. If not set or set to the empty value (e.g., "NEWNOTSYN="), + NEWNOTSYN=No is assumed.
    +
    + If you have a HA setup with failover to another firewall, you should + have NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes + if you have asymmetric routing.
    +
    • +
  • FORWARDPING - Added in Version 1.3.7
    + When set to "Yes" or "yes", ICMP echo-request (ping) packets + from interfaces that specify "filterping" are ACCEPTed by the firewall. + When set to "No" or "no", such ping requests are silently dropped +unless they are handled by an explicit entry in the rules file. If not specified, "No" is assumed.
    • +
  • LOGNEWNOTSYN - Added in Version 1.3.6
    + Beginning with version 1.3.6, Shorewall drops non-SYN TCP +packets that are not part of an existing connection. If you would +like to log these packets, set LOGNEWNOTSYN to the syslog +level at which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
    +
    + Note: Packets logged under this option are usually +the result of broken remote IP stacks rather than the result of +any sort of attempt to breach your firewall.
    +  
    • +
  • MERGE_HOSTS - Added in Version 1.3.5
    + Prior to 1.3.5, when the /etc/shorewall/hosts + file included an entry for a zone then the entire zone had to be +defined in the /etc/shorewall/hosts file and any associations between +the zone and interfaces in the /etc/shorewall/interfaces + file were ignored. This behavior is preserved if MERGE_HOSTS=No or + if MERGE_HOSTS is not set or is set to the empty value.
    +
    + Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone + assignments in the /etc/shorewall/hosts file are ADDED to those +in the /etc/shorewall/interfaces file.
    +
    + Example:
    +
    + Interfaces File:
    +   - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    ZONEHOSTSBROADCASTOPTIONS
    loceth1-dhcp
    -ppp+  
    ZONEHOSTSBROADCASTOPTIONS
    loceth1-dhcp
    -ppp+  
    - +


    - Hosts File:
    -  

    - + Hosts File:
    +  

    + - - - - - - - - - - - + + + + + + + + + + + +
    ZONEHOSTS
    locppp+:192.168.12.0/24
    ZONEHOSTS
    locppp+:192.168.12.0/24
    - +


    -     With MERGE_HOSTS=No, the loc zone consists of only - ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 - and ppp+:192.168.12.0/24.
    -  

    -
    • -
  • DETECT_DNAT_ADDRS - Added in Version 1.3.4
    - If set to "Yes" or "yes", Shorewall will detect the IP address(es) -of the interface(es) to the source zone and will include this (these) address(es) - in DNAT rules as the original destination IP address. If set to "No" or - "no", Shorewall will not detect this (these) address(es) and any destination - IP address will match the DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" - is assumed.
    -
    • -
  • MULTIPORT - Added in Version 1.3.2
    - If set to "Yes" or "yes", Shorewall will use the Netfilter multiport - facility. In order to use this facility, your kernel must have multiport - support (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, -Shorewall will generate a single rule from each record in the /etc/shorewall/rules - file that meets these criteria:
    -   +     With MERGE_HOSTS=No, the loc zone consists of + only ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 + and ppp+:192.168.12.0/24.
    +  

    +
    • +
  • DETECT_DNAT_ADDRS - Added in Version 1.3.4
    + If set to "Yes" or "yes", Shorewall will detect the IP address(es) + of the interface(es) to the source zone and will include this (these) +address(es) in DNAT rules as the original destination IP address. If set +to "No" or "no", Shorewall will not detect this (these) address(es) and +any destination IP address will match the DNAT rule. If not specified or +empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
    +
    • +
  • MULTIPORT - Added in Version 1.3.2
    + If set to "Yes" or "yes", Shorewall will use the Netfilter +multiport facility. In order to use this facility, your kernel must +have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). When this +support is used, Shorewall will generate a single rule from each record +in the /etc/shorewall/rules file that meets these criteria:
    +  
      -
    • No port range(s) specified
      • -
    • Specifies 15 or fewer ports
      • - +
    • No port range(s) specified
      • +
    • Specifies 15 or fewer ports
      • +
    - +

    Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range.

    -
    • -
  • NAT_BEFORE_RULES
    - If set to "No" or "no", port forwarding rules can override the -contents of the /etc/shorewall/nat file. If set -to "Yes" or "yes", port forwarding rules cannot override static NAT. -If not set or set to an empty value, "Yes" is assumed.
    • -
  • FW
    + rule for each listed port or port range.

    +
    • +
  • NAT_BEFORE_RULES
    + If set to "No" or "no", port forwarding rules can override +the contents of the /etc/shorewall/nat file. If +set to "Yes" or "yes", port forwarding rules cannot override static +NAT. If not set or set to an empty value, "Yes" is assumed.
    • +
  • FW
    -     This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an - empty string, - the value - "fw" - is assumed.
    • -
  • SUBSYSLOCK
    - This parameter should be set to the name of a file that -the firewall should create if it starts successfully and remove -when it stops. Creating and removing this file allows Shorewall -to work with your distribution's initscripts. For RedHat, this -should be set to /var/lock/subsys/shorewall. For Debian, the value -is /var/state/shorewall and in LEAF it is - /var/run/shorwall. - Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
    • -
  • STATEDIR
    - This parameter specifies the name of a directory where Shorewall - stores state information. If the directory doesn't exist when Shorewall - starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.
    -
    - NOTE: If you change the STATEDIR variable while the firewall - is running, create the new directory if necessary then copy the contents - of the old directory to the new directory.
    • -
  • ALLOWRELATED
    - This parameter must be assigned the value "Yes" ("yes") - or "No" ("no") and specifies whether Shorewall allows connection - requests that are related to an already allowed connection. If you - say "No" ("no"), you can still override this setting by including -"related" rules in /etc/shorewall/rules ("related" given as the protocol). -If you specify ALLOWRELATED=No, you will need to include rules in - /etc/shorewall/icmpdef +     This + parameter + specifies the + name of the + firewall zone. + If not set or + if set to an + empty string, + the value + "fw" + is assumed.
    • +
  • SUBSYSLOCK
    + This parameter should be set to the name of a file that + the firewall should create if it starts successfully and remove + when it stops. Creating and removing this file allows Shorewall + to work with your distribution's initscripts. For RedHat, this + should be set to /var/lock/subsys/shorewall. For Debian, the value + is /var/state/shorewall and in LEAF it is + /var/run/shorwall. + Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
    • +
  • STATEDIR
    + This parameter specifies the name of a directory where + Shorewall stores state information. If the directory doesn't +exist when Shorewall starts, it will create the directory. Example: +STATEDIR=/tmp/shorewall.
    +
    + NOTE: If you change the STATEDIR variable while the +firewall is running, create the new directory if necessary then copy +the contents of the old directory to the new directory.
    • +
  • ALLOWRELATED
    + This parameter must be assigned the value "Yes" + ("yes") or "No" ("no") and specifies whether Shorewall allows + connection requests that are related to an already allowed connection. + If you say "No" ("no"), you can still override this setting by +including "related" rules in /etc/shorewall/rules ("related" given +as the protocol). If you specify ALLOWRELATED=No, you will need to +include rules in /etc/shorewall/icmpdef to handle common ICMP packet types.
    • -
  • MODULESDIR
    - This parameter specifies the directory where your kernel -netfilter modules may be found. If you leave the variable empty, -Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
    • -
  • LOGRATE and LOGBURST
    - These parameters set the match rate and initial burst size - for logged packets. Please see the iptables man page for a description - of the behavior of these parameters (the iptables option --limit is - set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters - are set empty, no rate-limiting will occur.
    -
    - Example:
    -     LOGRATE=10/minute
    -     LOGBURST=5
    -  
    • -
  • LOGFILE
    +
  • MODULESDIR
    + This parameter specifies the directory where your kernel + netfilter modules may be found. If you leave the variable empty, + Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
    • +
  • LOGRATE and LOGBURST
    + These parameters set the match rate and initial burst + size for logged packets. Please see the iptables man page for a +description of the behavior of these parameters (the iptables option +--limit is set by LOGRATE and --limit-burst is set by LOGBURST). If +both parameters are set empty, no rate-limiting will occur.
    +
    + Example:
    +     LOGRATE=10/minute
    +     LOGBURST=5
    +  
    • +
  • LOGFILE
    - This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing the - "show - log", - "monitor", - "status" - and - "hits" - commands. If - not assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
    • -
  • NAT_ENABLED
    - This parameter determines whether Shorewall supports NAT -operations. NAT operations include:
    -
    -     Static NAT
    -     Port Forwarding
    -     Port Redirection
    -     Masquerading
    -
    - If the parameter has no value or has a value of "Yes" or - "yes" then NAT is enabled. If the parameter has a value of "no" - or "No" then NAT is disabled.
    + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages when + processing the + "show + log", + "monitor", + "status" + and + "hits" + commands. If + not assigned + or if +assigned + an empty + value, + /var/log/messages + is assumed.
    • +
  • NAT_ENABLED
    + This parameter determines whether Shorewall supports +NAT operations. NAT operations include:
    +
    +     Static NAT
    +     Port Forwarding
    +     Port Redirection
    +     Masquerading
    +
    + If the parameter has no value or has a value of "Yes" + or "yes" then NAT is enabled. If the parameter has a value of + "no" or "No" then NAT is disabled.
    +
    • +
  • MANGLE_ENABLED
    + This parameter determines if packet mangling is enabled. + If the parameter has no value or has a value of "Yes" or "yes" + than packet mangling is enabled. If the parameter has a value of +"no" or "No" then packet mangling is disabled. If packet mangling is + disabled, the /etc/shorewall/tos file is ignored.
    +
    • +
  • IP_FORWARDING
    + This parameter determines whether Shorewall enables +or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). + Possible values are:
    +
    +     On or on - packet forwarding will be enabled.
    +     Off or off - packet forwarding will be disabled.
    +     Keep or keep - Shorewall will neither enable nor + disable packet forwarding.
    +
    + If this variable is not set or is given an empty value + (IP_FORWARD="") then IP_FORWARD=On is assumed.
    • -
  • MANGLE_ENABLED
    - This parameter determines if packet mangling is enabled. -If the parameter has no value or has a value of "Yes" or "yes" than - packet mangling is enabled. If the parameter has a value of "no" - or "No" then packet mangling is disabled. If packet mangling is - disabled, the /etc/shorewall/tos file is ignored.
    -
    • -
  • IP_FORWARDING
    - This parameter determines whether Shorewall enables or disables - IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible - values are:
    -
    -     On or on - packet forwarding will be enabled.
    -     Off or off - packet forwarding will be disabled.
    -     Keep or keep - Shorewall will neither enable nor - disable packet forwarding.
    -
    - If this variable is not set or is given an empty value (IP_FORWARD="") - then IP_FORWARD=On is assumed.
    -
    • -
  • ADD_IP_ALIASES
    - This parameter determines whether Shorewall automatically -adds the - external address(es) in /etc/shorewall/nat - . If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these aliases. If it is set to "No" or "no", you must - add these aliases yourself using your distribution's network configuration - tools.
    -
    - If this variable is not set or is given an empty value (ADD_IP_ALIASES="") - then ADD_IP_ALIASES=Yes is assumed.
    • -
  • ADD_SNAT_ALIASES
    - This parameter determines whether Shorewall automatically adds -the SNAT ADDRESS in /etc/shorewall/masq. - If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these addresses. If it is set to "No" or "no", you must add these - addresses yourself using your distribution's network configuration tools.
    -
    - If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="") - then ADD_SNAT_ALIASES=No is assumed.
    -
    • -
  • LOGUNCLEAN
    +
  • ADD_IP_ALIASES
    + This parameter determines whether Shorewall automatically + adds the + external address(es) in /etc/shorewall/nat + . If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these aliases. If it is set to "No" or "no", you must + add these aliases yourself using your distribution's network configuration + tools.
    +
    + If this variable is not set or is given an empty value + (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
    • +
  • ADD_SNAT_ALIASES
    + This parameter determines whether Shorewall automatically +adds the SNAT ADDRESS in /etc/shorewall/masq. + If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these addresses. If it is set to "No" or "no", you must add these + addresses yourself using your distribution's network configuration + tools.
    +
    + If this variable is not set or is given an empty value + (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
    +
    • +
  • LOGUNCLEAN
    - This parameter - determines the - logging level - of - mangled/invalid - packets - controlled by - the 'dropunclean - and logunclean' - interface - options. - If LOGUNCLEAN - is empty - (LOGUNCLEAN=) - then -packets - selected by - 'dropclean' are - dropped - silently - ('logunclean' - packets are - logged under - the 'info' log - level). - Otherwise, - these packets - are logged -at the -specified - level - (Example: - LOGUNCLEAN=debug).
    • -
  • BLACKLIST_DISPOSITION
    + This parameter + determines the + logging level + of + mangled/invalid + packets + controlled by + the 'dropunclean + and +logunclean' + interface + options. If + LOGUNCLEAN is + empty + (LOGUNCLEAN=) + then packets + selected + by 'dropclean' + are dropped + silently + ('logunclean' + packets + are logged + under + the 'info' log + level). + Otherwise, + these packets + are logged at + the specified + level + (Example: + LOGUNCLEAN=debug).
    • +
  • BLACKLIST_DISPOSITION
    - This parameter - determines the - disposition of - packets from - blacklisted - hosts. It may - have the value - DROP if the - packets are to - be dropped - or REJECT - if the - packets are to - be replied - with an ICMP - port - unreachable - reply or a TCP - RST (tcp - only). If you - do not assign - a value or if - you assign an - empty value - then DROP -is assumed.
    • -
  • BLACKLIST_LOGLEVEL
    + This parameter + determines the + disposition of + packets from + blacklisted + hosts. It may + have the value + DROP if the + packets are + to be +dropped or + REJECT if the + packets are to + be replied + with an ICMP + port + unreachable + reply or a TCP + RST (tcp + only). If you + do not assign + a value or if + you assign +an empty +value then +DROP is +assumed.
    • +
  • BLACKLIST_LOGLEVEL
    - This paremter - determines if - packets from - blacklisted - hosts are - logged and it - determines the - syslog level - that they are - to be logged - at. Its -value is -a syslog - log level - (Example: - BLACKLIST_LOGLEVEL=debug). - If you do not - assign a value - or if you - assign an - empty value - then packets - from - blacklisted - hosts are -not logged.
    • -
  • CLAMPMSS
    + This paremter + determines if + packets from + blacklisted + hosts are + logged and it + determines the + syslog level + that they are + to be logged + at. Its + value + is a syslog +level + (Example: + BLACKLIST_LOGLEVEL=debug). + If you do not + assign a value + or if you + assign an + empty value + then packets + from + blacklisted + hosts +are not + logged.
    • +
  • CLAMPMSS
    - This parameter - enables the - TCP Clamp MSS - to PMTU - feature of - Netfilter and - is usually - required when - your internet - connection is - through PPPoE - or PPTP. -If set to - "Yes" - or - "yes", - the feature - is enabled. - If left - blank or - set to - "No" - or -"no", - the feature is - not enabled. - Note: This - option - requires - CONFIG_IP_NF_TARGET_TCPMSS - in - your kernel.
    • -
  • ROUTE_FILTER
    - If this parameter is given the value "Yes" or "yes" then route -filtering (anti-spoofing) is enabled on all network interfaces. -The default value is "no".
    • - + This parameter + enables the + TCP Clamp MSS + to PMTU + feature of + Netfilter and + is usually + required when + your internet + connection is + through +PPPoE + or PPTP. If + set to + "Yes" + or + "yes", + the feature is + enabled. If + left blank or + set to + "No" + or + "no", + the feature is + not enabled. + Note: This + option + requires + CONFIG_IP_NF_TARGET_TCPMSS + in + your kernel. +
  • ROUTE_FILTER
    + If this parameter is given the value "Yes" or "yes" then route + filtering (anti-spoofing) is enabled on all network interfaces. + The default value is "no".
    • +
- +

/etc/shorewall/modules Configuration

- +

The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall will - source this file during start/restart provided that it exists and that - the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).

- +

The file that is released with Shorewall calls the Shorewall function - "loadmodule" for the set of modules that I load.

+ "loadmodule" for the set of modules that I load.

- +

The loadmodule function is called as follows:

- +
- +

loadmodule <modulename> [ <module parameters> ]

-
+ - + +

where

- + +
- +

<modulename>                

- +
- +

is the name of the modules without the trailing ".o" (example ip_conntrack).

-
+
- +

<module parameters>

- +
- +

Optional parameters to the insmod utility.

-
- + + - +

The function determines if the module named by <modulename> - is already loaded and if not then the function determines if the - ".o" file corresponding to the module exists in the moduledirectory; - if so, then the following command is executed:

+ is already loaded and if not then the function determines if + the ".o" file corresponding to the module exists in the moduledirectory; + if so, then the following command is executed:

- +
- +

insmod moduledirectory/<modulename>.o <module - parameters>

-
+ parameters>

+ - +

If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports compressed @@ -2663,223 +2772,225 @@ it does, the function assumes that the running configuration supports compress - +

- +

insmod moduledirectory/<modulename>.o.gz <module - parameters>

-
+ parameters>

+ - +

/etc/shorewall/tos Configuration

- +

The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, protocol, - source port and destination port. In order for this file to be processed - by Shorewall, you must have mangle support -enabled .

+ in packet headers based on packet source, packet destination, protocol, + source port and destination port. In order for this file to be processed + by Shorewall, you must have mangle support + enabled .

- +

Entries in the file have the following columns:

- +
    -
  • SOURCE -- The source zone. May be qualified by following - the zone name with a colon (":") and either an IP address, an IP -subnet, a MAC address in Shorewall Format or the - name of an interface. This column may also contain the name of - the firewall - zone to indicate packets originating on the -firewall itself or "all" to indicate any source.
    • -
  • DEST -- The destination zone. May be qualified by - following the zone name with a colon (":") and either an IP address - or an IP subnet. Because packets are marked prior to routing, you - may not specify the name of an interface. This column may also +
  • SOURCE -- The source zone. May be qualified +by following the zone name with a colon (":") and either an IP +address, an IP subnet, a MAC address in Shorewall +Format or the name of an interface. This column may also contain +the name of + the firewall + zone to indicate packets originating +on the firewall itself or "all" to indicate any source.
    • +
  • DEST -- The destination zone. May be qualified + by following the zone name with a colon (":") and either an IP address + or an IP subnet. Because packets are marked prior to routing, you + may not specify the name of an interface. This column may also contain  "all" to indicate any destination.
    • -
  • PROTOCOL -- The name of a protocol in /etc/protocols - or the protocol's number.
    • -
  • SOURCE PORT(S) -- The source port or a port range. - For all ports, place a hyphen ("-") in this column.
    • -
  • DEST PORT(S)  -- The destination port or a port -range. To indicate all ports, place a hyphen ("-") in this column.
    • -
  • TOS -- The type of service. Must be one of the following:
    • - +
  • PROTOCOL -- The name of a protocol in /etc/protocols + or the protocol's number.
    • +
  • SOURCE PORT(S) -- The source port or a port +range. For all ports, place a hyphen ("-") in this column.
    • +
  • DEST PORT(S)  -- The destination port or a port + range. To indicate all ports, place a hyphen ("-") in this column.
    • +
  • TOS -- The type of service. Must be one of the + following:
    • +
- +
- +
- +

Minimize-Delay (16)
- Maximize-Throughput (8)
- Maximize-Reliability (4)
- Minimize-Cost (2)
- Normal-Service (0)

-
-
+ Maximize-Throughput (8)
+ Maximize-Reliability (4)
+ Minimize-Cost (2)
+ Normal-Service (0)

+ + - +

The /etc/shorewall/tos file that is included with Shorewall contains - the following entries.

+ the following entries.

- -
+ +
- + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
SOURCEDESTPROTOCOLSOURCE
- PORT(S)		DEST PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
SOURCEDESTPROTOCOLSOURCE
+ PORT(S)		DEST PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
-
+
- +

WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file.

+ adding the ESP and AH protocols to the /etc/shorewall/tos file.

- +

/etc/shorewall/blacklist

- +

Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall - Format - or - subnet - address. - Example:

+ an + IP + address, a MAC address in Shorewall Format + or + subnet + address. - + Example:

+ + 
      130.252.100.69
      206.124.146.0/24
- +

Packets from hosts listed in - the - blacklist - file - will - be + the + blacklist + file + will + be -disposed - of - according - to - the - value + disposed + of + according + to + the + value - assigned - to - the BLACKLIST_DISPOSITION + assigned + to + the BLACKLIST_DISPOSITION - and BLACKLIST_LOGLEVEL variables - in + and BLACKLIST_LOGLEVEL variables + in - /etc/shorewall/shorewall.conf. - Only - packets + /etc/shorewall/shorewall.conf. + Only + packets - arriving - on - interfaces - that - have - the + arriving + on + interfaces + that + have + the 'blacklist' option @@ -2892,174 +3003,170 @@ disposed the blacklist. The black list is designed to prevent listed -hosts/subnets from accessing services on your network.
-

- + hosts/subnets from accessing services on your network.
+

+

Beginning with Shorewall 1.3.8, the blacklist file has three columns:
-

- +

+
    -
  • ADDRESS/SUBNET - As described above.
    • -
  • PROTOCOL - Optional. If specified, only packets specifying - this protocol will be blocked.
    • -
  • PORTS - Optional; may only be given if PROTOCOL is tcp, - udp or icmp. Expressed as a comma-separated list of port numbers or service - names (from /etc/services). If present, only packets destined for the specified - protocol and one of the listed ports are blocked. When the PROTOCOL is -icmp, the PORTS column contains a comma-separated list of ICMP type numbers -or names (see "iptables -h icmp").
    -
    • - +
  • ADDRESS/SUBNET - As described above.
    • +
  • PROTOCOL - Optional. If specified, only packets specifying + this protocol will be blocked.
    • +
  • PORTS - Optional; may only be given if PROTOCOL is +tcp, udp or icmp. Expressed as a comma-separated list of port numbers +or service names (from /etc/services). If present, only packets destined +for the specified protocol and one of the listed ports are blocked. When +the PROTOCOL is icmp, the PORTS column contains a comma-separated list +of ICMP type numbers or names (see "iptables -h icmp").
    +
    • +
- +

Shorewall also has a dynamic blacklist - capability.

+ capability.

- +

IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, I suggest that - you install and configure Squid (http://www.squid-cache.org). -

+ designed to police your users' web browsing -- to do that, I suggest +that you install and configure Squid (http://www.squid-cache.org).

- +

/etc/shorewall/rfc1918 (Added in Version 1.3.1)

- +

This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:

+ interface option. Columns in the file are:

- -
    - -
  • SUBNET - The subnet using VLSM notation (e.g., - 192.168.0.0/16).
    • - -
  • TARGET - What to do with packets to/from - the SUBNET: -
      - -
    • RETURN - Process the packet normally thru the - rules and policies.
      • - -
    • DROP - Silently drop the packet.
      • - -
    • logdrop - Log then drop the packet.
      • - -
    - -
    • - -
- - - - -

/etc/shorewall/routestopped (Added in Version - 1.3.4)

- - - - -

This file defines the hosts that are accessible from the firewall when - the firewall is stopped.  Columns in the file are:

- - - -
    -
  • INTERFACE - The firewall interface through which - the host(s) comminicate with the firewall.
    • +
  • SUBNET - The subnet using VLSM notation (e.g., + 192.168.0.0/16).
    • -
  • HOST(S) - (Optional) - A comma-separated list -of IP/Subnet addresses. If not supplied or supplied as "-" then 0.0.0.0/0 - is assumed.
    • - +
  • TARGET - What to do with packets to/from + the SUBNET: +
      + +
    • RETURN - Process the packet normally thru + the rules and policies.
      • + +
    • DROP - Silently drop the packet.
      • + +
    • logdrop - Log then drop the packet -- see +the RFC1918_LOG_LEVEL parameter above.
      • + + + +
    + +
    • +
- + +

/etc/shorewall/routestopped (Added in Version + 1.3.4)

+ + + + +

This file defines the hosts that are accessible from the firewall when + the firewall is stopped.  Columns in the file are:

+ + + + +
    + +
  • INTERFACE - The firewall interface through + which the host(s) comminicate with the firewall.
    • + +
  • HOST(S) - (Optional) - A comma-separated +list of IP/Subnet addresses. If not supplied or supplied as "-" then +0.0.0.0/0 is assumed.
    • + +
+ + + +

Example: When your firewall is stopped, you want firewall accessibility - from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces -through eth1 and your local hosts through eth2.

+ from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces + through eth1 and your local hosts through eth2.

- +
- + - - + + - + - + - + - + - + - + - + - + - + - + - + - - + + +
INTERFACEINTERFACEHOST(S)HOST(S)
eth2eth2192.168.1.0/24192.168.1.0/24
eth1eth1--
-
+ - +

/etc/shorewall/maclist (Added in Version 1.3.10)

- This file is described in the MAC Validation - Documentation.
-
- -

Updated 11/24/2002 - Tom Eastep -

- - - -

Copyright - © 2001, 2002 Thomas M. Eastep.

- - - - - - -
+ This file is described in the MAC Validation + Documentation.

-
-
-
-
+ +

Updated 12/20/2002 - Tom Eastep +

+ + + +

Copyright + © 2001, 2002 Thomas M. Eastep.
+

+ + + + +


diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index b5ba4057b..10242d846 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,943 +1,1019 @@ - + + - + + - + + - + + Shorewall FAQ - + + - + - - - + + - - - + + + + +
+
+ -

Shorewall FAQs

-
- -

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.

- -

1a. Ok -- I followed those instructions - but it doesn't work.
-

- -

1b. I'm still having problems with - port forwarding

- -

2. I port forward www requests - to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 in my - local network. External clients can browse http://www.mydomain.com - but internal clients can't.

- -

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.

- -

3. I want to use Netmeeting/MSN - Messenger with Shorewall. What do I do?

- -

4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather - than 'blocked'. Why?

- -

4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!

- -

5. I've installed Shorewall and now - I can't ping through the firewall

- -

6. Where are the log messages - written and how do I change the destination?

- -

6a. Are there any log parsers - that work with Shorewall?

- -

7. When I stop Shorewall using -'shorewall stop', I can't connect to anything. Why doesn't that command - work?

- -

8. When I try to start Shorewall - on RedHat 7.x, I get messages about insmod failing -- what's wrong?

- -

9. Why can't Shorewall detect - my interfaces properly?

- -

10. What distributions does - it work with?

- -

11. What features does it -support?

- + +

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.

+ +

1a. Ok -- I followed those instructions + but it doesn't work.
+

+ +

1b. I'm still having problems with + port forwarding

+ +

2. I port forward www requests + to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 +in my local network. External clients can browse http://www.mydomain.com + but internal clients can't.

+ +

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.

+ +

3. I want to use Netmeeting/MSN + Messenger with Shorewall. What do I do?

+ +

4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' +rather than 'blocked'. Why?

+ +

4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!

+ +

5. I've installed Shorewall and now + I can't ping through the firewall

+ +

6. Where are the log messages + written and how do I change the destination?

+ +

6a. Are there any log parsers + that work with Shorewall?

+ +

7. When I stop Shorewall using + 'shorewall stop', I can't connect to anything. Why doesn't that command + work?

+ +

8. When I try to start Shorewall + on RedHat I get messages about insmod failing -- what's +wrong?

+ +

9. Why can't Shorewall detect + my interfaces properly?

+ +

10. What distributions does + it work with?

+ +

11. What features does it + support?

+

12. Why isn't there a GUI

- +

13. Why do you call it "Shorewall"?

- -

14. 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 rfc1918 blocking for my eth0 - interface, it also blocks the cable modems web server.

- -

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.

- -

15. My local systems can't see - out to the net

- -

16. Shorewall is writing log messages - all over my console making it unusable!
-

- 17. How do I find out why - this is getting logged?
-
- 18. Is there any way to use aliased ip - addresses with Shorewall, and maintain separate rulesets for different - IPs?
-
- 19. I have added entries to /etc/shorewall/tcrules - but they don't seem to do anything. Why?
-
- 20. I have just set up a -server. Do I have to change Shorewall to allow access to my server from -the internet?
-
- 21. I see these strange log entries occasionally; - what are they?
-
- -
-

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.

- + +

14. 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 rfc1918 blocking for my +eth0 interface, it also blocks the cable modems web server.

+ +

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.

+ +

15. My local systems can't see + out to the net

+ +

16. Shorewall is writing log messages + all over my console making it unusable!
+

+ 17. How do I find + out why this traffic is getting logged?
+
+ 18. Is there any way to use aliased + ip addresses with Shorewall, and maintain separate rulesets for + different IPs?
+
+ 19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?
+
+ 20. I have just set up a server. Do +I have to change Shorewall to allow access to my server from the internet?
+
+ 21. I see these strange log entries +occasionally; what are they?
+
+ 22. I have some iptables commands that I +want to run when Shorewall starts. Which file do I put them in?
+ +
+

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.

+

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format of a port-forwarding - rule to a local system is as follows:

- -
+ href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding + rule to a local system is as follows:

+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>
-
-
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>
+
+
-
- -

So to forward UDP port 7777 to internal system 192.168.1.5, - the rule is:

- -
+
+ +

So to forward UDP port 7777 to internal system 192.168.1.5, + the rule is:

+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-
-
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
+
+
-
- -
-
     DNAT net loc:192.168.1.5 udp 7777
-
- -

If you want to forward requests directed to a particular -address ( <external IP> ) on your firewall to an internal system:

- -
+
+ +
If + you want to forward requests directed to a particular address ( <external + IP> ) on your firewall to an internal system:
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>-<external IP>
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>-<external IP>
-
- -

1a. Ok -- I followed those instructions - but it doesn't work

- +
+ +

1a. Ok -- I followed those instructions + but it doesn't work

+

Answer: That is usually the result of one of two things:

- +
    -
  • You are trying to test from inside your firewall -(no, that won't work -- see FAQ #2).
    • -
  • 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).
    • - +
  • You are trying to test from inside your firewall + (no, that won't work -- see FAQ #2).
    • +
  • 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).
    • +
- -

1b. I'm still having problems with port - forwarding

- Answer: To further diagnose this problem:
- + +

1b. I'm still having problems with port + forwarding

+ Answer: To further diagnose this problem:
+
    -
  • As root, type "iptables -t nat -Z". This clears the NetFilter - counters in the nat table.
    • -
  • Try to connect to the redirected port from an external host.
    • -
  • As root type "shorewall show nat"
    • -
  • Locate the appropriate DNAT rule. It will be in a chain called - zone_dnat where zone is the zone that includes the  - ('net' in the above examples).
    • -
  • 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).
    • -
  • If the packet count is zero:
    • - +
  • As root, type "iptables -t nat -Z". This clears the +NetFilter counters in the nat table.
    • +
  • Try to connect to the redirected port from an external + host.
    • +
  • As root type "shorewall show nat"
    • +
  • Locate the appropriate DNAT rule. It will be in a chain + called zone_dnat where zone is the zone that includes + the  ('net' in the above examples).
    • +
  • 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).
    • +
  • If the packet count is zero:
    • +
      -
    • the connection request is not reaching your server (possibly - it is being blocked by your ISP); or
      • -
    • 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
      • -
    • 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.
      -
      • - +
    • the connection request is not reaching your server +(possibly it is being blocked by your ISP); or
      • +
    • 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
      • +
    • 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.
      +
      • +
    - +
- -

2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in my local network. External - clients can browse http://www.mydomain.com but internal clients can't.

- + +

2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in my local network. + External clients can browse http://www.mydomain.com but internal + clients can't.

+

Answer: I have two objections to this setup.

- +
    -
  • 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 :-)
    • -
  • The accessibility problem is best solved using - Bind Version 9 "views" -(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.
    • - +
  • 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 :-)
    • +
  • The accessibility problem is best solved using + Bind Version 9 "views" + (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.
    • +
- -

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:

- -

a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1 (No longer required as of Shorewall version 1.3.9).

- -
+ +

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:

+ +

a) In /etc/shorewall/interfaces, specify "multi" as an option + for eth1 (No longer required as of Shorewall version 1.3.9).

+ +

b) In /etc/shorewall/rules, add:

-
- -
-
+
+ +
+
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
-
-
- -
-
     DNAT    loc:192.168.1.0/24    loc:192.168.1.5    tcp    www    -    130.151.100.69:192.168.1.254
-
- -
-

That rule only works of course if you have a static external - IP address. If you have a dynamic IP address and are running Shorewall - 1.3.4 or later then include this in /etc/shorewall/params:

-
- -
+ +
+ + +
+

That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are running + Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

+
+ +
     ETH0_IP=`find_interface_address eth0`
-
- -
+
+ +

and make your DNAT rule:

-
- -
-
+
+ +
+
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
-
-
- -
-

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.

-
- -

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.

- -

Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both external and internal - clients to access a NATed host using the host's DNS name.

- -

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.

- -

If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:

- -

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).
- b) Set the Z->Z policy to ACCEPT.
- c) Masquerade Z to itself.
-
- Example:

- + +
+ +
+

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.

+
+ +

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.

+ +

Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external and internal + clients to access a NATed host using the host's DNS name.

+ +

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.

+ +

If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:

+ +

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).
+ b) Set the Z->Z policy to ACCEPT.
+ c) Masquerade Z to itself.
+
+ Example:

+

Zone: dmz
- Interface: eth2
- Subnet: 192.168.2.0/24

- + Interface: eth2
+ Subnet: 192.168.2.0/24

+

In /etc/shorewall/interfaces:

- -
+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + + +
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255multi
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255multi
-
- +
+

In /etc/shorewall/policy:

- -
+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + + +
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
+
-
- -
+
+ +
     dmz    dmz    ACCEPT
-
- + +

In /etc/shorewall/masq:

- -
+ +
+ - - - - - - - - - - - + + + + + + + + + + + - - + + + +
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
-
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
+
-
- -

3. I want to use Netmeeting/MSN Messenger - with Shorewall. What do I do?

- +
+ +

3. I want to use Netmeeting/MSN Messenger + with Shorewall. What do I do?

+

Answer: There is an H.323 connection - tracking/NAT module that may help. Also check the Netfilter mailing - list archives at http://netfilter.samba.org. -

- -

4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather - than 'blocked'. Why?

- -

Answer: 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 can 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.

- -

If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web server in violation -of your Service Agreement.

- -

4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!

- -

Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing 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->all -policy to REJECT, restart Shorewall and do the nmap UDP scan again.

- -

5. I've installed Shorewall and now I - can't ping through the firewall

- -

Answer: If you want your firewall to be totally open - for "ping":

- + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help. Also check the Netfilter + mailing list archives at http://netfilter.samba.org. +

+ +

4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' rather + than 'blocked'. Why?

+ +

Answer: 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 can 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.

+ +

If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server in violation + of your Service Agreement.

+ +

4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!

+ +

Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing 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->all policy to REJECT, restart Shorewall and do the +nmap UDP scan again.

+ +

5. I've installed Shorewall and now I + can't ping through the firewall

+ +

Answer: If you want your firewall to be totally open + for "ping":

+

a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
- b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
- c) Add the following to /etc/shorewall/icmpdef:

- -
-

run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT

-
- -

6. Where are the log messages written - and how do I change the destination?

- -

Answer: 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 policies and rules. 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").

- -

By default, older versions of Shorewall ratelimited log messages - through settings in /etc/shorewall/shorewall.conf - -- If you want to log all messages, set:

- -
-
     LOGLIMIT=""
     LOGBURST=""
-
- -

6a. Are there any log parsers that work - with Shorewall?

- -

Answer: Here are several links that may be helpful: -

- -
+ b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
+ c) Add the following to /etc/shorewall/icmpdef: +

+ +
+ +

run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
+

+
+ For a complete description of Shorewall 'ping' management, see this page. + +

6. Where are the log messages written + and how do I change the destination?

+ +

Answer: 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 policies + and rules. 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").

+ +

By default, older versions of Shorewall ratelimited log messages + through settings in /etc/shorewall/shorewall.conf + -- If you want to log all messages, set:

+ +
+
     LOGLIMIT=""
     LOGBURST=""

Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
+
+ +

6a. Are there any log parsers that work + with Shorewall?

+ +

Answer: Here are several links that may be helpful: +

+ +
+

http://www.shorewall.net/pub/shorewall/parsefw/
- http://www.fireparse.com
- http://www.fireparse.com
+ http://cert.uni-stuttgart.de/projects/fwlogwatch
- http://www.logwatch.org
-

-
- -

7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't that command work?

- -

The 'stop' command is intended to place your firewall into - a safe state whereby only those interfaces/hosts having the 'routestopped' - option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. - If you want to totally open up your firewall, you must use the 'shorewall - clear' command.

- -

8. When I try to start Shorewall on RedHat - 7.x, I get messages about insmod failing -- what's wrong?

- -

Answer: The output you will see looks something like - this:

- -
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
- -

This is usually cured by the following sequence of commands: + http://www.logwatch.org

- -
+
+ 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.  +

7. When I stop Shorewall using 'shorewall + stop', I can't connect to anything. Why doesn't that command work?

+ +

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.

+ +

8. When I try to start Shorewall on RedHat, +I get messages about insmod failing -- what's wrong?

+ +

Answer: The output you will see looks something like + this:

+ +
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
+ +

This is usually cured by the following sequence of commands: +

+ +
     service ipchains stop
     chkconfig --delete ipchains
     rmmod ipchains
-
- -
-

Also, be sure to check the errata - for problems concerning the version of iptables (v1.2.3) shipped -with RH7.2.

-
- + + +
+

Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped + with RH7.2.

+
+

- -

9. Why can't Shorewall detect my interfaces - properly?

- -

I just installed Shorewall and when I issue the start command, - I see the following:

- -
+ +

9. Why can't Shorewall detect my interfaces + properly?

+ +

I just installed Shorewall and when I issue the start command, + I see the following:

+ +
     Processing /etc/shorewall/shorewall.conf ...
     Processing /etc/shorewall/params ...
     Starting Shorewall...
     Loading Modules...
     Initializing...
     Determining Zones...
     Zones: net loc
     Validating interfaces file...
     Validating hosts file...
     Determining Hosts in Zones...
     Net Zone: eth0:0.0.0.0/0
     Local Zone: eth1:0.0.0.0/0
     Deleting user chains...
     Creating input Chains...
     ...
-
- -
+
+ +

Why can't Shorewall detect my interfaces properly?

-
- -
-

Answer: 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

-
- -

10. What Distributions does it work - with?

- -

Shorewall works with any GNU/Linux distribution that includes - the proper prerequisites.

- +
+ +
+

Answer: 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

+
+ +

10. What Distributions does it work + with?

+ +

Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.

+

11. What Features does it have?

- -

Answer: See the Shorewall - Feature List.

- + +

Answer: See the Shorewall + Feature List.

+

12. Why isn't there a GUI?

- -

Answer: 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.

- + +

Answer: 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.

+

13. Why do you call it "Shorewall"?

- -

Answer: Shorewall is a concatenation of "Shoreline" - (the city where I live) - and "Firewall".

- -

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.

- -

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.

- -

Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:

- -
+ +

Answer: Shorewall is a concatenation of "Shoreline" + (the city where +I live) and "Firewall". The full name of the product +is actually "Shoreline Firewall" but "Shorewall" is must more commonly used.

+ +

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.

+ +

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?

+ +

Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:

+ +
     run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
-
- -
-

If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:

-
- -
-
+
+ +
+

If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:

+
+ +
+
+ - - - - - - - - - + + + + + + + + + - - + + + +
SUBNET TARGET
192.168.100.1RETURN
SUBNET TARGET
192.168.100.1RETURN
-
-
- -
+ +
+ +

Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-

- -

Note: If you add a second IP address to your external firewall - interface to correspond to the modem address, you must also make an - entry in /etc/shorewall/rfc1918 for that address. For example, if you - configure the address 192.168.100.2 on your firewall, then you would - add two entries to /etc/shorewall/rfc1918:
-

- -
+

+ +

Note: If you add a second IP address to your external firewall + interface to correspond to the modem address, you must also make + an entry in /etc/shorewall/rfc1918 for that address. For example, + if you configure the address 192.168.100.2 on your firewall, then +you would add two entries to /etc/shorewall/rfc1918:
+

+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + +
SUBNET
- 		TARGET
-
192.168.100.1
- 		RETURN
-
192.168.100.2
- 		RETURN
-
SUBNET
+ 		TARGET
+
192.168.100.1
+ 		RETURN
+
192.168.100.2
+ 		RETURN
+
-
-
- -
-

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.

-
- -
-

The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.

-
- -

15. My local systems can't see out to - the net

- -

Answer: 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:

- + +
+ +
+

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.

+
+ +
+

The solution is the same as FAQ 14 above. Simply substitute + the IP address of your ISPs DHCP server.

+
+ +

15. My local systems can't see out to + the net

+ +

Answer: 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:

+
    -
  1. - -

    The default gateway on each local system isn't set to - the IP address of the local firewall interface.

    -
    2. -
  2. - -

    The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.

    -
    3. -
  3. - -

    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.

    -
    4. - +
  4. + + +

    The default gateway on each local system isn't set to + the IP address of the local firewall interface.

    +
    5. +
  5. + + +

    The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.

    +
    6. +
  6. + + +

    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.

    +
    7. +
- -

16. Shorewall is writing log messages - all over my console making it unusable!

- -

Answer: "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.
-

- -

17. How do I find out why this is getting logged?

- Answer: Logging occurs out of a number of chains (as -indicated in the log message) in Shorewall:
- + +

16. Shorewall is writing log messages + all over my console making it unusable!

+ +

Answer: "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.
+

+ +

17. How do I find out why this traffic is getting +logged?

+ Answer: Logging occurs out of a number of chains + (as indicated in the log message) in Shorewall:
+
    -
  1. man1918 - The destination address is listed in -/etc/shorewall/rfc1918 with a logdrop target -- see man1918 - The destination address is listed + in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
    2. -
  2. rfc1918 - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 - The source address is listed in + /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
    3. -
  3. all2<zone>, <zone>2all or all2all - - You have a policy 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 rule to that effect.
    -
    4. -
  4. <zone1>2<zone2> - Either you have a policy for <zone1> to - <zone2> that specifies a log level and this packet is being - logged under that policy or this packet matches a rule that includes a log level.
    5. -
  5. <interface>_mac - The packet is being logged under - the maclist interface -option.
    -
    6. -
  6. logpkt - The packet is being logged under the logunclean - interface option.
    7. -
  7. badpkt - The packet is being logged under the dropunclean - interface option as specified - in the LOGUNCLEAN setting in all2<zone>, <zone>2all +or all2all - You have a policy 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 rule + to that effect.
    +
    8. +
  8. <zone1>2<zone2> - Either you +have a policy for <zone1> + to <zone2> that specifies a log level and this +packet is being logged under that policy or this packet matches a + rule that includes a log level.
    9. +
  9. <interface>_mac - The packet is being logged + under the maclist interface option.
    +
    10. +
  10. logpkt - The packet is being logged under + the logunclean interface option.
    11. +
  11. badpkt - The packet is being logged under + the dropunclean interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    12. -
  12. blacklst - The packet is being logged because the - source IP is blacklisted in theblacklst - The packet is being logged because + the source IP is blacklisted in the /etc/shorewall/blacklist file.
    13. -
  13. newnotsyn - 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 - NEWNOTSYN and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
    14. -
  14. INPUT or FORWARD - 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.
    15. -
  15. logflags - The packet is being logged because it failed the - checks implemented by the tcpflags newnotsyn - 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 NEWNOTSYN and LOGNEWNOTSYN in + /etc/shorewall/shorewall.conf.
    16. +
  16. INPUT or FORWARD - 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.
    17. +
  17. logflags - The packet is being logged because it failed + the checks implemented by the tcpflags interface option.
    -
    18. - + +
- -

18. Is there any way to use aliased ip addresses - with Shorewall, and maintain separate rulesets for different IPs?

- Answer: Yes. You simply use the IP address in your rules -(or if you use NAT, use the local IP address in your rules). Note: -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.
-
- Example 1:
-
- /etc/shorewall/rules + +

18. Is there any way to use aliased ip addresses + with Shorewall, and maintain separate rulesets for different IPs?

+ Answer: Yes. You simply use the IP address in your +rules (or if you use NAT, use the local IP address in your rules). +Note: 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.
+
+ Example 1:
+
+ /etc/shorewall/rules 
     # Accept AUTH but only on address 192.0.2.125

     ACCEPT	net	fw:192.0.2.125	tcp	auth
- Example 2 (NAT):
-
- /etc/shorewall/nat
- + Example 2 (NAT):
+
+ /etc/shorewall/nat
+ 
     192.0.2.126	eth0	10.1.1.126
- /etc/shorewall/rules + /etc/shorewall/rules 
     # Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)

     ACCEPT	net	loc:10.1.1.126	tcp	www
- Example 3 (DNAT):
- + Example 3 (DNAT):
+ 
     # Forward SMTP on external address 192.0.2.127 to local system 10.1.1.127

     DNAT	net	loc:10.1.1.127	tcp	smtp	-	192.0.2.127
- -

19. I have added entries to /etc/shorewall/tcrules - but they don't seem to do anything. Why?

- You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf - so the contents of the tcrules file are simply being ignored.
- -

20. I have just set up a server. Do I have - to change Shorewall to allow access to my server from the internet?
-

- Yes. Consult the QuickStart -guide that you used during your initial setup for information about -how to set up rules for your server.
- -

21. I see these strange log entries occasionally; - what are they?
-

- -
+ +

19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?

+ You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf + so the contents of the tcrules file are simply being ignored.
+ +

20. I have just set up a server. Do I have + to change Shorewall to allow access to my server from the internet?
+

+ Yes. Consult the QuickStart + guide that you used during your initial setup for information about + how to set up rules for your server.
+ +

21. I see these strange log entries occasionally; + what are they?
+

+ +
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
     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 
     [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 ]
-
- 192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal LAN
-
- Answer: 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.
-
- Here is my interpretation of what is happening -- to confirm this analysis, -one out have to have packet sniffers placed a both ends of the connection.
+
+ 192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal + LAN
+
+ Answer: 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.
+
+ 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.
+
+ 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.
+ +

22. I have some iptables commands that +I want to run when Shorewall starts. Which file do I put them in?

+ You can place these commands in one of the Shorewall Extension Scripts. 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.

- 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.
-
- +
- Last updated 11/25/2002 - Tom -Eastep -

Copyright - © 2001, 2002 Thomas M. Eastep.
-

+ Last updated 12/13/2002 - Tom Eastep + +

Copyright + © 2001, 2002 Thomas M. Eastep.
+

+
+
+
+
+
+
+
diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html index 19fdb4615..49be690fa 100644 --- a/STABLE/documentation/MAC_Validation.html +++ b/STABLE/documentation/MAC_Validation.html @@ -2,103 +2,109 @@ MAC Verification - + - + - + - - - + + - - - + +
+ + + +
- +
+

MAC Verification
-

-
-
-
- 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. There are four components to this facility.
- +
+ 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.
+
+You must have the iproute package (ip utility) installed to use MAC Verification.
+
+There are four components to this facility.
+
    -
  1. The maclist interface option in /etc/shorewall/interfaces. When this -option is specified, all traffic arriving on the interface is subjet to MAC -verification.
    2. -
  2. The maclist option in /etc/shorewall/hosts. - When this option is specified for a subnet, all traffic from that subnet -is subject to MAC verification.
    3. -
  3. The /etc/shorewall/maclist file. This file is used to associate -MAC addresses with interfaces and to optionally associate IP addresses with -MAC addresses.
    4. -
  4. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables - in /etc/shorewall/shorewall.conf. The - MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and determines - the disposition of connection requests that fail MAC verification. The MACLIST_LOG_LEVEL - variable gives the syslogd level at which connection requests that fail verification - are to be logged. If set the the empty value (e.g., MACLIST_LOG_LEVEL="") - then failing connection requests are not logged.
    -
    5. - +
  5. The maclist interface option in /etc/shorewall/interfaces. When +this option is specified, all traffic arriving on the interface is subjet +to MAC verification.
    6. +
  6. The maclist option in /etc/shorewall/hosts. + When this option is specified for a subnet, all traffic from that subnet + is subject to MAC verification.
    7. +
  7. The /etc/shorewall/maclist file. This file is used to associate +MAC addresses with interfaces and to optionally associate IP addresses with + MAC addresses.
    8. +
  8. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables + in /etc/shorewall/shorewall.conf. +The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and +determines the disposition of connection requests that fail MAC verification. +The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection +requests that fail verification are to be logged. If set the the empty value +(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.
    +
    9. +
- The columns in /etc/shorewall/maclist are:
- + The columns in /etc/shorewall/maclist are:
+
    -
  • INTERFACE - The name of an ethernet interface on the Shorewall system.
    • -
  • 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.
    • -
  • IP Address - An optional comma-separated list of IP addresses for +
  • INTERFACE - The name of an ethernet interface on the Shorewall +system.
    • +
  • 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.
    • +
  • IP Address - An optional comma-separated list of IP addresses for the device whose MAC is listed in the MAC column.
    • - +
- +

Example 1: Here are my files:

- /etc/shorewall/shorewall.conf:
- + /etc/shorewall/shorewall.conf:
+ 
     MACLIST_DISPOSITION=REJECT
     MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
- + /etc/shorewall/interfaces:
+ 
     #ZONE           INTERFACE       BROADCAST       OPTIONS
     net             eth0            206.124.146.255 norfc1918,filterping,dhcp,blacklist
     loc             eth2            192.168.1.255   dhcp,filterping,maclist
     dmz             eth1            192.168.2.255   filterping
     net             eth3            206.124.146.255 filterping,blacklist
     -               texas           192.168.9.255   filterping
     loc             ppp+            -               filterping
- /etc/shorewall/maclist:
- + /etc/shorewall/maclist:
+ 
     #INTERFACE              MAC                     IP ADDRESSES (Optional)
     eth2                    00:A0:CC:63:66:89       192.168.1.3     #Wookie
     eth2                    00:10:B5:EC:FD:0B       192.168.1.4     #Tarry
     eth2                    00:A0:CC:DB:31:C4       192.168.1.5     #Ursa
     eth2                    00:06:25:aa:a8:0f       192.168.1.7     #Eastept1 (Wireless)
     eth2                    00:04:5A:0E:85:B9       192.168.1.250   #Wap
- As shown above, I use MAC Verification on my local - zone.
- + As shown above, I use MAC Verification on my local + zone.
+

Example 2: Router in Local Zone

- 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 - file:
- + 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 + file:
+ 
     eth2                     00:06:43:45:C6:15       192.168.1.253,192.168.2.0/24
- 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 -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. -

Updated 10/23/2002 - Tom Eastep + 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 + 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. +

Updated 12/22/2002 - Tom Eastep

- -

Copyright - © 2001, 2002 Thomas M. Eastep.

-
-
+ +

Copyright + © 2001, 2002 Thomas M. Eastep.

+
+
+



diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 240da2057..72cba3084 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -2,1530 +2,1866 @@ + Shorewall News - + + + - + - - - + + - - -
+
- -

Shorewall News Archive

-
+

Shorewall News Archive

+ + + + + + + +

12/27/2002 - Shorewall 1.3.12 Released

+

Features include:
+

+
    +
  1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
    2. +
  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.
    3. +
  3. "shorewall [re]start" has been speeded up by more than 40% with my + configuration. Your milage may vary.
    4. +
  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"
    5. +
  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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
    6. +
  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_CHAIN=Yes in shorewall.conf. This allows for marking + input packets based on their destination even when you are using Masquerading + or SNAT.
    7. +
  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.
    8. +
  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.
    +
    9. +
+

12/20/2002 - Shorewall 1.3.12 Beta 3
+

+ 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.
+ +

12/20/2002 - Shorewall 1.3.12 Beta 2

+ +

The first public Beta version of Shorewall 1.3.12 is now available (Beta + 1 was made available only to a limited audience).
+

+ Features include:
+ +
    +
  1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
    2. +
  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.
    3. +
  3. "shorewall [re]start" has been speeded up by more than 40% with + my configuration. Your milage may vary.
    4. +
  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"
    5. +
  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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
    6. +
  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_CHAIN=Yes in shorewall.conf. This allows for + marking input packets based on their destination even when you are using + Masquerading or SNAT.
    7. +
  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.
    8. + +
+ You may download the Beta from:
+ +
http://www.shorewall.net/pub/shorewall/Beta
+ ftp://ftp.shorewall.net/pub/shorewall/Beta
+
+ +

12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux +

+ Shorewall is at the center of MandrakeSoft's recently-announced Multi + Network Firewall (MNF) product. Here is the press + release.
+ +

12/7/2002 - Shorewall Support for Mandrake 9.0

+ +

Two months and 3 days after I 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.

+ +

12/6/2002 - Debian 1.3.11a Packages Available
+

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

+

12/3/2002 - Shorewall 1.3.11a

-

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.

+ +

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.

+

11/24/2002 - Shorewall 1.3.11

- +

In this version:

- +
    -
  • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. This option -causes Shorewall to make a set of sanity check on TCP packet header flags.
    • -
  • It is now allowed to use 'all' in the SOURCE or DEST column in a rule. When used, 'all' must appear by -itself (in may not be qualified) and it does not enable intra-zone traffic. -For example, the rule
    -
    -     ACCEPT loc all tcp 80
    -
    - does not enable http traffic from 'loc' to 'loc'.
    • -
  • Shorewall's use of the 'echo' command is now compatible with bash -clones such as ash and dash.
    • -
  • fw->fw policies now generate a startup error. fw->fw rules generate -a warning and are ignored
    • - +
  • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. This +option causes Shorewall to make a set of sanity check on TCP packet header +flags.
    • +
  • It is now allowed to use 'all' in the SOURCE or DEST column + in a rule. When used, 'all' +must appear by itself (in may not be qualified) and it does not enable +intra-zone traffic. For example, the rule
    +
    +     ACCEPT loc all tcp 80
    +
    + does not enable http traffic from 'loc' to 'loc'.
    • +
  • Shorewall's use of the 'echo' command is now compatible +with bash clones such as ash and dash.
    • +
  • fw->fw policies now generate a startup error. fw->fw + rules generate a warning and are ignored
    • +
- +

11/14/2002 - Shorewall Documentation in PDF Format

- -

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. - the PDF may be downloaded from

- + +

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. + the PDF may be downloaded from

+

    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-     http://slovakia.shorewall.net/pub/shorewall/pdf/
-

- -

11/09/2002 - Shorewall is Back at SourceForge -

- +     http://slovakia.shorewall.net/pub/shorewall/pdf/
+

+ +

11/09/2002 - Shorewall is Back at SourceForge +

+

The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
-

- +

+

11/09/2002 - Shorewall 1.3.10

- +

In this version:

- + - +

10/24/2002 - Shorewall is now in Gentoo Linux
-

- Alexandru Hartmann reports that his Shorewall package is now a part -of the Gentoo Linux distribution. Thanks - Alex!
- +

+ Alexandru Hartmann reports that his Shorewall package is +now a part of the Gentoo Linux distribution. + Thanks Alex!
+

10/23/2002 - Shorewall 1.3.10 Beta 1

- In this version:
- - - You may download the Beta from:
- - - -

10/10/2002 -  Debian 1.3.9b Packages Available
-

- -

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

10/9/2002 - Shorewall 1.3.9b

- This release rolls up fixes to the installer and to the firewall script.
- -

10/6/2002 - Shorewall.net now running on RH8.0
-
- The firewall and server here at shorewall.net are now running RedHat - release 8.0.
-
- 9/30/2002 - Shorewall 1.3.9a

- Roles up the fix for broken tunnels.
- -

9/30/2002 - TUNNELS Broken in 1.3.9!!!

- There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
- -

9/28/2002 - Shorewall 1.3.9

- -

In this version:
-

- -
    -
  • DNS -Names are now allowed in Shorewall config files (although I recommend -against using them).
    • -
  • The connection SOURCE may now be qualified by both interface - and IP address in a Shorewall rule.
    • -
  • Shorewall startup is now disabled after initial installation - until the file /etc/shorewall/startup_disabled is removed. This avoids - nasty surprises during reboot for users who install Shorewall but don't - configure it.
    • -
  • The 'functions' and 'version' files and the 'firewall' symbolic - link have been moved from /var/lib/shorewall to /usr/lib/shorewall -to appease the LFS police at Debian.
    -
    • - -
- -

9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
-

- Brown Paper Bag - A couple of recent configuration changes at www.shorewall.net - broke the Search facility:
- -
-
    -
  1. Mailing List Archive Search was not available.
    2. -
  2. The Site Search index was incomplete
    3. -
  3. Only one page of matches was presented.
    4. + In this version:
    -
-
- Hopefully these problems are now corrected. - -

9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
-

- A couple of recent configuration changes at www.shorewall.net - had the negative effect of breaking the Search facility:
- -
    -
  1. Mailing List Archive Search was not available.
    2. -
  2. The Site Search index was incomplete
    3. -
  3. Only one page of matches was presented.
    4. - -
- Hopefully these problems are now corrected.
- -

9/18/2002 -  Debian 1.3.8 Packages Available
-

- -

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

9/16/2002 - Shorewall 1.3.8

- -

In this version:
-

-
    -
  • A NEWNOTSYN -option has been added to shorewall.conf. This option determines whether -Shorewall accepts TCP packets which are not part of an established -connection and that are not 'SYN' packets (SYN flag on and ACK flag -off).
    • -
  • The need for the 'multi' option to communicate between - zones za and zb on the same interface is removed in the case where - the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
    • - -
      -
    • There is a policy for za to zb; or
      • -
    • There is at least one rule for za to zb.
      • - -
    - +
  • You may now define the +contents of a zone dynamically with the "shorewall add" and "shorewall + delete" commands. These commands are expected to be used primarily + within FreeS/Wan + updown scripts.
    • +
  • Shorewall can now do +MAC verification on ethernet segments. You can specify the set +of allowed MAC addresses on the segment and you can optionally tie +each MAC address to one or more IP addresses.
    • +
  • PPTP Servers and Clients running on the firewall system + may now be defined in the /etc/shorewall/tunnels + file.
    • +
  • A new 'ipsecnat' tunnel type is supported for use when + the remote IPSEC endpoint is behind a NAT + gateway.
    • +
  • The PATH used by Shorewall may now be specified in + /etc/shorewall/shorewall.conf.
    • +
  • The main firewall script is now /usr/lib/shorewall/firewall. + The script in /etc/init.d/shorewall is very small and uses /sbin/shorewall + to do the real work. This change makes custom distributions such as + for Debian and for Gentoo easier to manage since it is /etc/init.d/shorewall + that tends to have distribution-dependent code.
    • +
+ You may download the Beta from:
+ +

10/10/2002 -  Debian 1.3.9b Packages Available
+

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

+ +

10/9/2002 - Shorewall 1.3.9b

+ This release rolls up fixes to the installer and to the +firewall script.
-

9/11/2002 - Debian 1.3.7c Packages Available

+

10/6/2002 - Shorewall.net now running on RH8.0
+
+ The firewall and server here at shorewall.net are now +running RedHat release 8.0.
+
+ 9/30/2002 - Shorewall 1.3.9a

+ Roles up the fix for broken tunnels.
+ +

9/30/2002 - TUNNELS Broken in 1.3.9!!!

+ There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall.
+ +

9/28/2002 - Shorewall 1.3.9

+ +

In this version:
+

+ +
    +
  • DNS Names are + now allowed in Shorewall config files (although I recommend against + using them).
    • +
  • The connection SOURCE may now be qualified +by both interface and IP address in a Shorewall rule.
    • +
  • Shorewall startup is now disabled after initial + installation until the file /etc/shorewall/startup_disabled is + removed. This avoids nasty surprises during reboot for users who +install Shorewall but don't configure it.
    • +
  • The 'functions' and 'version' files and the 'firewall' + symbolic link have been moved from /var/lib/shorewall to /usr/lib/shorewall + to appease the LFS police at Debian.
    +
    • + +
+ +

9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
+

+ Brown Paper Bag + A couple of recent configuration changes at www.shorewall.net + broke the Search facility:
+ + +
+ +
    +
  1. Mailing List Archive Search was not available.
    2. +
  2. The Site Search index was incomplete
    3. +
  3. Only one page of matches was presented.
    4. + + +
+
+ Hopefully these problems are now corrected. + +

9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
+

+ A couple of recent configuration changes at www.shorewall.net + had the negative effect of breaking the Search facility:
+ +
    +
  1. Mailing List Archive Search was not available.
    2. +
  2. The Site Search index was incomplete
    3. +
  3. Only one page of matches was presented.
    4. + +
+ Hopefully these problems are now corrected.
+ +

9/18/2002 -  Debian 1.3.8 Packages Available
+

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

+ +

9/16/2002 - Shorewall 1.3.8

+ +

In this version:
+

+ +
    +
  • A NEWNOTSYN + option has been added to shorewall.conf. This option determines + whether Shorewall accepts TCP packets which are not part of an + established connection and that are not 'SYN' packets (SYN flag + on and ACK flag off).
    • +
  • The need for the 'multi' option to communicate + between zones za and zb on the same interface is removed in the + case where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will + exist if:
    • + + +
      +
    • There is a policy for za to zb; + or
      • +
    • There is at least one rule for za +to zb.
      • + + +
    + +
+
    +
  • The /etc/shorewall/blacklist file now +contains three columns. In addition to the SUBNET/ADDRESS column, +there are optional PROTOCOL and PORT columns to block only certain +applications from the blacklisted addresses.
    +
    • + +
+ +

9/11/2002 - Debian 1.3.7c Packages Available

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- + +

9/2/2002 - Shorewall 1.3.7c

- -

This is a role up of a fix for "DNAT" rules where the source zone is $FW - (fw).

- + + +

This is a role up of a fix for "DNAT" rules where the source zone is $FW + (fw).

+ +

8/31/2002 - I'm not available

- -

I'm currently on vacation  -- please respect my need for a couple of -weeks free of Shorewall problem reports.

- + + +

I'm currently on vacation  -- please respect my need for a couple of + weeks free of Shorewall problem reports.

+ +

-Tom

- + +

8/26/2002 - Shorewall 1.3.7b

- -

This is a role up of the "shorewall refresh" bug fix and the change which - reverses the order of "dhcp" and "norfc1918" checking.

- + + +

This is a role up of the "shorewall refresh" bug fix and the change which + reverses the order of "dhcp" and "norfc1918" checking.

+ +

8/26/2002 - French FTP Mirror is Operational

- + +

ftp://france.shorewall.net/pub/mirrors/shorewall - is now available.

- + href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall + is now available.

+ +

8/25/2002 - Shorewall Mirror in France

- -

Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored - at http://france.shorewall.net.

- + + +

Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored + at http://france.shorewall.net.

+ +

8/25/2002 - Shorewall 1.3.7a Debian Packages Available

- -

Lorenzo Martignoni reports that the packages for version 1.3.7a are available - at Lorenzo Martignoni reports that the packages for version 1.3.7a are available + at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author - -- Shorewall 1.3.7a released8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author + -- Shorewall 1.3.7a released -

- -

1.3.7a corrects problems occurring in rules file processing when starting - Shorewall 1.3.7.

- +

+ + +

1.3.7a corrects problems occurring in rules file processing when starting + Shorewall 1.3.7.

+ +

8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

- + +

Features in this release include:

- + +
    -
  • The 'icmp.def' file is now empty! The rules in -that file were required in ipchains firewalls but are not required -in Shorewall. Users who have ALLOWRELATED=No in shorewall.conf should see the Upgrade Issues.
    • -
  • A 'FORWARDPING' option has been added to shorewall.conf. The effect of setting - this variable to Yes is the same as the effect of adding an -ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef. Users - who have such a rule in icmpdef are encouraged to switch to FORWARDPING=Yes.
    • -
  • The loopback CLASS A Network (127.0.0.0/8) has -been added to the rfc1918 file.
    • -
  • Shorewall now works with iptables 1.2.7
    • -
  • The documentation and web site no longer uses FrontPage - themes.
    • - +
  • The 'icmp.def' file is now empty! The + rules in that file were required in ipchains firewalls but + are not required in Shorewall. Users who have ALLOWRELATED=No + in shorewall.conf should see +the Upgrade Issues.
    • +
  • A 'FORWARDPING' option has been added + to shorewall.conf. The effect + of setting this variable to Yes is the same as the effect + of adding an ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef. Users + who have such a rule in icmpdef are encouraged to switch to + FORWARDPING=Yes.
    • +
  • The loopback CLASS A Network (127.0.0.0/8) + has been added to the rfc1918 file.
    • +
  • Shorewall now works with iptables 1.2.7
    • +
  • The documentation and web site no longer + uses FrontPage themes.
    • +
- -

I would like to thank John Distler for his valuable input regarding TCP - SYN and ICMP treatment in Shorewall. That input has led to marked - improvement in Shorewall in the last two releases.

- + + +

I would like to thank John Distler for his valuable input regarding TCP + SYN and ICMP treatment in Shorewall. That input has led to + marked improvement in Shorewall in the last two releases.

+ +

8/13/2002 - Documentation in the CVS Repository

- -

The Shorewall-docs project now contains just the HTML and image files -- the Frontpage files have been removed.

- + + +

The Shorewall-docs project now contains just the HTML and image files - +the Frontpage files have been removed.

+ +

8/7/2002 - STABLE branch added to CVS Repository

- -

This branch will only be updated after I release a new version of Shorewall - so you can always update from this branch to get the latest stable - tree.

- -

8/7/2002 - Upgrade Issues section -added to the Errata Page

- -

Now there is one place to go to look for issues involved with upgrading - to recent versions of Shorewall.

- + + +

This branch will only be updated after I release a new version of Shorewall + so you can always update from this branch to get the latest + stable tree.

+ + +

8/7/2002 - Upgrade Issues section added + to the Errata Page

+ + +

Now there is one place to go to look for issues involved with upgrading + to recent versions of Shorewall.

+ +

8/7/2002 - Shorewall 1.3.6

- + +

This is primarily a bug-fix rollup with a couple of new features:

- + + - +

7/30/2002 - Shorewall 1.3.5b Released

- + +

This interim release:

- + + - +

7/29/2002 - New Shorewall Setup Guide Available

- + +

The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. - The guide is intended for use by people who are setting up Shorewall - to manage multiple public IP addresses and by people who want to - learn more about Shorewall than is described in the single-address - guides. Feedback on the new guide is welcome.

- + href="http://www.shorewall.net/shorewall_setup_guide.htm"> http://www.shorewall.net/shorewall_setup_guide.htm. + The guide is intended for use by people who are setting up + Shorewall to manage multiple public IP addresses and by people + who want to learn more about Shorewall than is described in the + single-address guides. Feedback on the new guide is welcome.

+ +

7/28/2002 - Shorewall 1.3.5 Debian Package Available

- -

Lorenzo Martignoni reports that the packages are version 1.3.5a and are - available at Lorenzo Martignoni reports that the packages are version 1.3.5a and are + available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- + +

7/27/2002 - Shorewall 1.3.5a Released

- + +

This interim release restores correct handling of REDIRECT rules.

- + +

7/26/2002 - Shorewall 1.3.5 Released

- -

This will be the last Shorewall release for a while. I'm going to be -focusing on rewriting a lot of the documentation.

- + + +

This will be the last Shorewall release for a while. I'm going to be + focusing on rewriting a lot of the documentation.

+ +

 In this version:

- + +
    -
  • Empty and invalid source and destination qualifiers - are now detected in the rules file. It is a good idea to use the - 'shorewall check' command before you issue a 'shorewall restart' - command be be sure that you don't have any configuration problems - that will prevent a successful restart.
    • -
  • Added MERGE_HOSTS variable in shorewall.conf to provide saner behavior - of the /etc/shorewall/hosts file.
    • -
  • The time that the counters were last reset is now - displayed in the heading of the 'status' and 'show' commands.
    • -
  • A proxyarp option has been added for entries - in /etc/shorewall/interfaces. - This option facilitates Proxy ARP sub-netting as described in the - Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). - Specifying the proxyarp option for an interface causes Shorewall - to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • -
  • The Samples have been updated to reflect the new - capabilities in this release.
    • - +
  • Empty and invalid source and destination + qualifiers are now detected in the rules file. It is a good + idea to use the 'shorewall check' command before you issue + a 'shorewall restart' command be be sure that you don't have any + configuration problems that will prevent a successful restart.
    • +
  • Added MERGE_HOSTS variable in + shorewall.conf to provide saner +behavior of the /etc/shorewall/hosts file.
    • +
  • The time that the counters were last +reset is now displayed in the heading of the 'status' and +'show' commands.
    • +
  • A proxyarp option has been added + for entries in /etc/shorewall/interfaces. + This option facilitates Proxy ARP sub-netting as described +in the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). + Specifying the proxyarp option for an interface causes Shorewall + to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • +
  • The Samples have been updated to reflect + the new capabilities in this release.
    • +
- +

7/16/2002 - New Mirror in Argentina

- -

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in - Argentina. Thanks Buanzo!!!

- + + +

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in + Argentina. Thanks Buanzo!!!

+ +

7/16/2002 - Shorewall 1.3.4 Released

- + +

In this version:

- + +
    -
  • A new - /etc/shorewall/routestopped file has been added. This file is - intended to eventually replace the routestopped option - in the /etc/shorewall/interface and /etc/shorewall/hosts files. - This new file makes remote firewall administration easier by allowing - any IP or subnet to be enabled while Shorewall is stopped.
    • -
  • An /etc/shorewall/stopped extension script has been added. - This script is invoked after Shorewall has stopped.
    • -
  • A DETECT_DNAT_ADDRS option has been added - to /etc/shoreall/shorewall.conf. - When this option is selected, DNAT rules only apply when the -destination address is the external interface's primary IP address.
    • -
  • The QuickStart - Guide has been broken into three guides and has been almost - entirely rewritten.
    • -
  • The Samples have been updated to reflect the new - capabilities in this release.
    • - +
  • A new /etc/shorewall/routestopped + file has been added. This file is intended to eventually +replace the routestopped option in the /etc/shorewall/interface + and /etc/shorewall/hosts files. This new file makes remote +firewall administration easier by allowing any IP or subnet to be + enabled while Shorewall is stopped.
    • +
  • An /etc/shorewall/stopped extension script has been added. + This script is invoked after Shorewall has stopped.
    • +
  • A DETECT_DNAT_ADDRS option has + been added to /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only apply when + the destination address is the external interface's primary + IP address.
    • +
  • The QuickStart Guide has + been broken into three guides and has been almost entirely rewritten.
    • +
  • The Samples have been updated to reflect + the new capabilities in this release.
    • +
- +

7/8/2002 - Shorewall 1.3.3 Debian Package Available

- + +

Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- + +

7/6/2002 - Shorewall 1.3.3 Released

- + +

In this version:

- + +
    -
  • Entries in /etc/shorewall/interface that use the - wildcard character ("+") now have the "multi" option assumed.
    • -
  • The 'rfc1918' chain in the mangle table has been - renamed 'man1918' to make log messages generated from that chain - distinguishable from those generated by the 'rfc1918' chain in - the filter table.
    • -
  • Interface names appearing in the hosts file are -now validated against the interfaces file.
    • -
  • The TARGET column in the rfc1918 file is now checked - for correctness.
    • -
  • The chain structure in the nat table has been changed - to reduce the number of rules that a packet must traverse and to - correct problems with NAT_BEFORE_RULES=No
    • -
  • The "hits" command has been enhanced.
    • - +
  • Entries in /etc/shorewall/interface +that use the wildcard character ("+") now have the "multi" +option assumed.
    • +
  • The 'rfc1918' chain in the mangle table + has been renamed 'man1918' to make log messages generated + from that chain distinguishable from those generated by the + 'rfc1918' chain in the filter table.
    • +
  • Interface names appearing in the hosts + file are now validated against the interfaces file.
    • +
  • The TARGET column in the rfc1918 file + is now checked for correctness.
    • +
  • The chain structure in the nat table +has been changed to reduce the number of rules that a packet +must traverse and to correct problems with NAT_BEFORE_RULES=No
    • +
  • The "hits" command has been enhanced.
    • +
- +

6/25/2002 - Samples Updated for 1.3.2

- -

The comments in the sample configuration files have been updated to reflect - new features introduced in Shorewall 1.3.2.

- + + +

The comments in the sample configuration files have been updated to reflect + new features introduced in Shorewall 1.3.2.

+ +

6/25/2002 - Shorewall 1.3.1 Debian Package Available

- + +

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- + +

6/19/2002 - Documentation Available in PDF Format

- -

Thanks to Mike Martinez, the Shorewall Documentation is now available -for download in Adobe PDF format.

- + + +

Thanks to Mike Martinez, the Shorewall Documentation is now available for + download in Adobe + PDF format.

+ +

6/16/2002 - Shorewall 1.3.2 Released

- + +

In this version:

- + + - +

6/6/2002 - Why CVS Web access is Password Protected

- -

Last weekend, I installed the CVS Web package to provide brower-based -access to the Shorewall CVS repository. Since then, I have had several -instances where my server was almost unusable due to the high load generated -by website copying tools like HTTrack and WebStripper. These mindless tools:

- + + +

Last weekend, I installed the CVS Web package to provide brower-based access + to the Shorewall CVS repository. Since then, I have had several instances +where my server was almost unusable due to the high load generated by website +copying tools like HTTrack and WebStripper. These mindless tools:

+ +
    -
  • Ignore robot.txt files.
    • -
  • Recursively copy everything that they find.
    • -
  • Should be classified as weapons rather than tools.
    • - +
  • Ignore robot.txt files.
    • +
  • Recursively copy everything that they + find.
    • +
  • Should be classified as weapons rather + than tools.
    • +
- -

These tools/weapons are particularly damaging when combined with CVS Web - because they doggedly follow every link in the cgi-generated HTML - resulting in 1000s of executions of the cvsweb.cgi script. Yesterday, - I spend several hours implementing measures to block these tools -but unfortunately, these measures resulted in my server OOM-ing under - even moderate load.

- -

Until I have the time to understand the cause of the OOM (or until I buy - more RAM if that is what is required), CVS Web access will remain - Password Protected.

- + +

These tools/weapons are particularly damaging when combined with CVS Web + because they doggedly follow every link in the cgi-generated + HTML resulting in 1000s of executions of the cvsweb.cgi script. + Yesterday, I spend several hours implementing measures to block + these tools but unfortunately, these measures resulted in my server + OOM-ing under even moderate load.

+ + +

Until I have the time to understand the cause of the OOM (or until I buy + more RAM if that is what is required), CVS Web access will + remain Password Protected.

+ +

6/5/2002 - Shorewall 1.3.1 Debian Package Available

- + +

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- + +

6/2/2002 - Samples Corrected

- -

The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These problems have been corrected - in the 1.3.1 samples.

- + + +

The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These problems have been + corrected in the 1.3.1 + samples.

+ +

6/1/2002 - Shorewall 1.3.1 Released

- + +

Hot on the heels of 1.3.0, this release:

- + + - +

5/29/2002 - Shorewall 1.3.0 Released

- -

In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 - includes:

- + + +

In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 + includes:

+ +
    -
  • A 'filterping' interface option that allows ICMP - echo-request (ping) requests addressed to the firewall to be -handled by entries in /etc/shorewall/rules and /etc/shorewall/policy.
    • - +
  • A 'filterping' interface option that +allows ICMP echo-request (ping) requests addressed to the +firewall to be handled by entries in /etc/shorewall/rules and +/etc/shorewall/policy.
    • +
- +

5/23/2002 - Shorewall 1.3 RC1 Available

- -

In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) - incorporates the following:

- + + +

In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) + incorporates the following:

+ + - + +

5/19/2002 - Shorewall 1.3 Beta 2 Available

- -

In addition to the changes in Beta 1, this release which carries the -designation 1.2.91 adds:

- + + +

In addition to the changes in Beta 1, this release which carries the + designation 1.2.91 adds:

+ +
    -
  • The structure of the firewall is changed markedly. - There is now an INPUT and a FORWARD chain for each interface; -this reduces the number of rules that a packet must traverse, -especially in complicated setups.
    • -
  • Sub-zones may - now be excluded from DNAT and REDIRECT rules.
    • -
  • The names of the columns in a number of the configuration - files have been changed to be more consistent and self-explanatory - and the documentation has been updated accordingly.
    • -
  • The sample configurations have been updated for -1.3.
    • - +
  • The structure of the firewall is changed + markedly. There is now an INPUT and a FORWARD chain for each + interface; this reduces the number of rules that a packet +must traverse, especially in complicated setups.
    • +
  • Sub-zones + may now be excluded from DNAT and REDIRECT rules.
    • +
  • The names of the columns in a number +of the configuration files have been changed to be more consistent + and self-explanatory and the documentation has been updated + accordingly.
    • +
  • The sample configurations have been +updated for 1.3.
    • +
- + +

5/17/2002 - Shorewall 1.3 Beta 1 Available

- -

Beta 1 carries the version designation 1.2.90 and implements the following - features:

- + + +

Beta 1 carries the version designation 1.2.90 and implements the following + features:

+ +
    -
  • Simplified rule syntax which makes the intent of - each rule clearer and hopefully makes Shorewall easier to learn.
    • -
  • Upward compatibility with 1.2 configuration files - has been maintained so that current users can migrate to the new - syntax at their convenience.
    • -
  • WARNING:  Compatibility - with the old parameterized sample configurations has NOT been -maintained. Users still running those configurations should migrate -to the new sample configurations before upgrading to 1.3 Beta -1.
    • - +
  • Simplified rule syntax which makes the + intent of each rule clearer and hopefully makes Shorewall +easier to learn.
    • +
  • Upward compatibility with 1.2 configuration + files has been maintained so that current users can migrate + to the new syntax at their convenience.
    • +
  • WARNING:  Compatibility + with the old parameterized sample configurations has NOT been + maintained. Users still running those configurations should + migrate to the new sample configurations before upgrading to + 1.3 Beta 1.
    • +
- +

5/4/2002 - Shorewall 1.2.13 is Available

- + +

In this version:

- + + - +

4/30/2002 - Shorewall Debian News

- -

Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the -Debian - Testing Branch and the Debian - Unstable Branch.

- -

4/20/2002 - Shorewall 1.2.12 is Available

- -
    -
  • The 'try' command works again
    • -
  • There is now a single RPM that also works with -SuSE.
    • - -
- -

4/17/2002 - Shorewall Debian News

- -

Lorenzo Marignoni reports that:

- - + +

For more about our network see my Shorewall Configuration.

+

All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs.

- +

- - - -

- -

Last updated 11/24/2002 - -Tom Eastep

- + Powered by Mandrake + Protected by Shorewall +

+ +

Last updated 12/7/2002 - Tom Eastep

+ Copyright © 2001, 2002 Thomas M. Eastep.
-
-
-
-
-
+

diff --git a/STABLE/documentation/shorewall_extension_scripts.htm b/STABLE/documentation/shorewall_extension_scripts.htm index c8689cdbe..650be5874 100644 --- a/STABLE/documentation/shorewall_extension_scripts.htm +++ b/STABLE/documentation/shorewall_extension_scripts.htm @@ -1,113 +1,133 @@ + - - - - - -Shorewall Extension Scripts + + + + + + + + + Shorewall Extension Scripts - - - - - - - -
-

Extension Scripts

-
- -

- Extension scripts are user-provided - scripts that are invoked at various points during firewall start, restart, - stop and clear. The scripts are placed in /etc/shorewall and are processed - using the Bourne shell "source" mechanism. The following scripts can be - supplied:

-
    -
  • init -- invoked early in "shorewall start" and "shorewall restart"
    • -
  • start -- invoked after the firewall has been started or restarted.
    • -
  • stop -- invoked as a first step when the firewall is being stopped.
    • -
  • stopped -- invoked after the firewall has been stopped.
    • -
  • clear -- invoked after the firewall has been cleared.
    • -
  • refresh -- invoked while the firewall is being refreshed but before the - common and/or blacklst chains have been rebuilt.
    • -
  • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' chain - has been created but before any rules have been added to it.
    • + + + + + + + + + + + + + + +
    + +

    Extension Scripts

    + +
    + + +

    Extension scripts are user-provided scripts that are invoked at various +points during firewall start, restart, stop and clear. The scripts are +placed in /etc/shorewall and are processed using the Bourne shell "source" +mechanism. The following scripts can be supplied:

    + +
      +
    • init -- invoked early in "shorewall start" and "shorewall restart"
      • +
    • start -- invoked after the firewall has been started or restarted.
      • +
    • stop -- invoked as a first step when the firewall is being stopped.
      • +
    • stopped -- invoked after the firewall has been stopped.
      • +
    • clear -- invoked after the firewall has been cleared.
      • +
    • refresh -- invoked while the firewall is being refreshed but before +the common and/or blacklst chains have been rebuilt.
      • +
    • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' +chain has been created but before any rules have been added to it.
      • +
    - -

    - You can also supply a script with the same name as any of the filter -chains in the firewall and the script will be invoked after the /etc/shorewall/rules - file has been processed but before the /etc/shorewall/policy file has -been processed.

    + + +

    If your version of Shorewall doesn't have the file that you want +to use from the above list, you can simply create the file yourself.

    +

    You can also supply a script with the same name as any of the filter + chains in the firewall and the script will be invoked after the /etc/shorewall/rules + file has been processed but before the /etc/shorewall/policy file has been + processed.

    - -

    The /etc/shorewall/common file receives special treatment. If this file is present, the rules that it - defines will totally replace the default rules in the common chain. These - default rules are contained in the file /etc/shorewall/common.def which - may be used as a starting point for making your own customized file.

    + + +

    The /etc/shorewall/common file receives special treatment. If this file +is present, the rules that it defines will totally replace the default +rules in the common chain. These default rules are contained in the +file /etc/shorewall/common.def which may be used as a starting point +for making your own customized file.

    - -

    - Rather than running iptables directly, you should run it using the function - run_iptables. Similarly, rather than running "ip" directly, you should -use run_ip. These functions accept the same arguments as the underlying -command but cause the firewall to be stopped if an error occurs during -processing of the command.

    + + +

    Rather than running iptables directly, you should run it using the + function run_iptables. Similarly, rather than running "ip" directly, + you should use run_ip. These functions accept the same arguments as the + underlying command but cause the firewall to be stopped if an error occurs + during processing of the command.

    + + +

    If you decide to create /etc/shorewall/common it is a good idea to +use the following technique

    + + + + +

    /etc/shorewall/common:

    + + + + +
    -

    - If you decide to create /etc/shorewall/common it is a good idea to use the - following technique

    + 
    . /etc/shorewall/common.def
    <add your rules here>
    +
    + +

    If you need to supercede a rule in the released common.def file, you can +add the superceding rule before the '.' command. Using this technique allows + you to add new rules while still getting the benefit of the latest common.def + file.

    - -

    - /etc/shorewall/common:

    + +

    Remember that /etc/shorewall/common defines rules that are only applied +if the applicable policy is DROP or REJECT. These rules are NOT applied +if the policy is ACCEPT or CONTINUE.

    - -
    - 
    . /etc/shorewall/common.def
-<add your rules here>
    -
    -

    If you need to supercede a rule in the released common.def file, you can add - the superceding rule before the '.' command. Using this technique allows - you to add new rules while still getting the benefit of the latest common.def - file.

    + +

    If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will +be rejected by the firewall. It is recommended with this setting that you +create the file /etc/shorewall/icmpdef and in it place the following commands:

    - -

    Remember that /etc/shorewall/common defines rules - that are only applied if the applicable policy is DROP or REJECT. These rules - are NOT applied if the policy is ACCEPT or CONTINUE.

    + +
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will be - rejected by the firewall. It is recommended with this setting that you create - the file /etc/shorewall/icmpdef and in it place the following commands:

    - - - - 
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
-
    -

    Last updated -8/22/2002 - Tom -Eastep

    - -

    Copyright 2002 Thomas M. Eastep

    - + +

    Last updated 12/22/2002 - Tom Eastep

    + +

    Copyright 2002 Thomas +M. Eastep

    +
    - - \ No newline at end of file + diff --git a/STABLE/documentation/shorewall_quickstart_guide.htm b/STABLE/documentation/shorewall_quickstart_guide.htm index 1b5b7144b..564fbaf64 100644 --- a/STABLE/documentation/shorewall_quickstart_guide.htm +++ b/STABLE/documentation/shorewall_quickstart_guide.htm @@ -1,231 +1,269 @@ - + - + - + - + Shorewall QuickStart Guide - + + - + - - - + + - - - + Version 3.1 + + + +
    - +
    +

    Shorewall QuickStart Guides
    - Version 3.1

    -
    - +

    With thanks to Richard who reminded me once again that we must all first walk before we can run.

    - +

    The Guides

    - +

    These guides provide step-by-step instructions for configuring Shorewall - in common firewall setups.

    - + in common firewall setups.

    +

    The following guides are for users who have a single public IP address:

    - +
      -
    • Standalone Linux System
      • -
    • Two-interface Linux System -acting as a firewall/router for a small local network
      • -
    • Three-interface Linux System - acting as a firewall/router for a small local network and a DMZ.
      • - +
    • Standalone Linux System
      • +
    • Two-interface Linux System + acting as a firewall/router for a small local network
      • +
    • Three-interface Linux + System acting as a firewall/router for a small local network and +a DMZ.
      • +
    - +

    The above guides are designed to get your first firewall up and running - quickly in the three most common Shorewall configurations.

    - + quickly in the three most common Shorewall configurations.

    +

    The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple -public IP addresses involved or if you want to learn more about Shorewall -than is explained in the single-address guides above.

    - + the steps necessary to set up a firewall where there are multiple + public IP addresses involved or if you want to learn more about Shorewall + than is explained in the single-address guides above.

    +
      -
    • 1.0 Introduction
      • -
    • 2.0 Shorewall -Concepts
      • -
    • 3.0 Network -Interfaces
      • -
    • 4.0 Addressing, - Subnets and Routing +
    • 1.0 Introduction
      • +
    • 2.0 Shorewall + Concepts
      • +
    • 3.0 Network + Interfaces
      • +
    • 4.0 Addressing, + Subnets and Routing + - - -
      • -
    • 5.0 Setting up -your Network - - - - +

      Documentation Index

      - +

      The following documentation covers a variety of topics and supplements - the QuickStart Guides described - above. Please review the appropriate guide before trying to use this - documentation directly.

      - + the QuickStart Guides +described above. Please review the appropriate guide before trying +to use this documentation directly.

      + - +

      If you use one of these guides and have a suggestion for improvement please let me know.

      - -

      Last modified 11/19/2002 - Tom Eastep

      - + +

      Last modified 12/13/2002 - Tom Eastep

      +

      Copyright 2002 Thomas M. Eastep
      -

      +

      +
      +
      +
      +

      diff --git a/STABLE/documentation/shorewall_setup_guide.htm b/STABLE/documentation/shorewall_setup_guide.htm index c73ff0c9e..9a72e16e0 100644 --- a/STABLE/documentation/shorewall_setup_guide.htm +++ b/STABLE/documentation/shorewall_setup_guide.htm @@ -1,418 +1,206 @@ - + - + - + - + Shorewall Setup Guide - + - +

      Shorewall Setup Guide

      - +

      1.0 Introduction
      - 2.0 Shorewall Concepts
      - 3.0 Network Interfaces
      - 4.0 Addressing, Subnets and Routing

      - -
      + 2.0 Shorewall Concepts
      + 3.0 Network Interfaces
      + 4.0 Addressing, Subnets and Routing

      + +

      4.1 IP Addresses
      - 4.2 Subnets
      - 4.3 Routing
      - 4.4 Address Resolution Protocol
      - 4.5 RFC 1918

      -
      - -

      5.0 Setting up your Network

      - -
      -

      5.1 Routed
      - 5.2 Non-routed

      - -
      -

      5.2.1 SNAT
      - 5.2.2 DNAT
      - 5.2.3 Proxy ARP
      - 5.2.4 Static NAT

      + 4.2 Subnets
      + 4.3 Routing
      + 4.4 Address Resolution Protocol
      + 4.5 RFC 1918

      - + +

      5.0 Setting up your Network

      + +
      +

      5.1 Routed
      + 5.2 Non-routed

      + +
      +

      5.2.1 SNAT
      + 5.2.2 DNAT
      + 5.2.3 Proxy ARP
      + 5.2.4 Static NAT

      +
      +

      5.3 Rules
      - 5.4 Odds and Ends

      -
      - + 5.4 Odds and Ends

      +
      +

      6.0 DNS
      - 7.0 Starting and Stopping the Firewall

      - + 7.0 Starting and Stopping the Firewall

      +

      1.0 Introduction

      - +

      This guide is intended for users who are setting up Shorewall in an environment -where a set of public IP addresses must be managed or who want to know more -about Shorewall than is contained in the single-address guides. Because -the range of possible applications is so broad, the Guide will give you + the range of possible applications is so broad, the Guide will give you general guidelines and will point you to other resources as necessary.

      - +

      -    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.

      - +     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.

      +

      This guide assumes that you have the iproute/iproute2 package installed -(on RedHat, the package is called iproute). You can tell if -this package is installed by the presence of an ip program on your -firewall system. As root, you can use the 'which' command to check for this -program:

      - + (on RedHat, the package is called iproute). You can tell +if this package is installed by the presence of an ip program on +your firewall system. As root, you can use the 'which' command to check +for this program:

      + 
           [root@gateway root]# which ip
           /sbin/ip
           [root@gateway root]#
      +

      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 -.

      - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with + .

      +

      -    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.

      - +     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.

      + - +

      2.0 Shorewall Concepts

      - +

      The configuration files for Shorewall are contained in the directory /etc/shorewall -- for most setups, you will only need to deal with a few of these as described in this guide. Skeleton files are created during the Shorewall Installation Process.

      - +

      As each file is introduced, I suggest that you look through the actual -file on your system -- each file contains detailed configuration instructions -and some contain default entries.

      - + file on your system -- each file contains detailed configuration instructions + and some contain default entries.

      +

      Shorewall views the network where it is running as being composed of a -set of zones. In the default installation, the following zone names -are used:

      - + set of zones. In the default installation, the following zone names + are used:

      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      NameDescription
      netThe Internet
      locYour Local Network
      dmzDemilitarized Zone
      NameDescription
      netThe Internet
      locYour Local Network
      dmzDemilitarized Zone
      - +

      Zones are defined in the /etc/shorewall/zones -file.

      - + file.

      +

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed in the -/etc/shorewall/shorewall.conf file. -In this guide, the default name (fw) will be used.

      - + the firewall itself is known as fw but that may be changed in the + /etc/shorewall/shorewall.conf file. + In this guide, the default name (fw) will be used.

      +

      With the exception of fw, 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".

      - + 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".

      +

      -    Edit the /etc/shorewall/zones file and make any changes necessary.

      - +     Edit the /etc/shorewall/zones file and make any changes necessary.

      +

      Rules about what traffic to allow and what traffic to deny are expressed -in terms of zones.

      - + in terms of zones.

      + - +

      Shorewall is built on top of the Netfilter -kernel facility. Netfilter implements a connection -tracking function that allows what is often referred to as stateful -inspection of packets. This stateful property allows firewall rules -to be defined in terms of connections rather than in terms of packets. -With Shorewall, you:

      - + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms of +packets. With Shorewall, you:

      +
        -
      1. Identify the source zone.
        2. -
      2. Identify the destination zone.
        3. -
      3. 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.
        4. -
      4. 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.
        5. - +
      5. Identify the source zone.
        6. +
      6. Identify the destination zone.
        7. +
      7. 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.
        8. +
      8. 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.
        9. +
      - +

      Just because connections of a particular type are allowed from zone A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed -from zone A to zone B. It rather means that you can have -a proxy running on the firewall that accepts a connection from zone A and -then establishes its own separate connection from the firewall to zone -B.

      - + from zone A to zone B      . It rather means that you can have + a proxy running on the firewall that accepts a connection from zone A +and then establishes its own separate connection from the firewall to +zone B.

      +

      For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file matches - the connection request then the first policy in /etc/shorewall/policy that - matches the request is applied. If that policy is REJECT or DROP  the request -is first checked against the rules in /etc/shorewall/common.def.

      - + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common.def.

      +

      The default /etc/shorewall/policy file has the following policies:

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      -
      - -

      The above policy will:

      - -
        -
      1. allow all connection requests from your local network to the internet
        2. -
      2. drop (ignore) all connection requests from the internet to your firewall - or local network and log a message at the info level (see "man -syslog").
        3. -
      3. reject all other connection requests and log a message at the info - 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.
        4. - -
      - -

      -    At this point, edit your /etc/shorewall/policy and make any changes that -you wish.

      - -

      3.0 Network Interfaces

      - -

      For the remainder of this guide, we'll refer to the following - diagram. While it may not look like your own network, it can be used to - illustrate the important aspects of Shorewall configuration.

      - -

      In this diagram:

      - -
        -
      • 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 that -if one of those servers is compromised, you still have the firewall between -the compromised system and your local systems.
        • -
      • The Local Zone consists of systems Local 1, Local 2 and Local 3.
        • -
      • All systems from the ISP outward comprise the Internet Zone.
        • - -
      - -

      -

      - -

      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 /etc/shorewall/interfaces - file.

      - -

      The firewall illustrated above has three network interfaces. - Where Internet connectivity is through a cable or DSL "Modem", the External - Interface will be the Ethernet adapter that is connected to that "Modem" - (e.g., eth0)  unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the External Interface -will be a ppp interface (e.g., ppp0). If you connect via a regular -modem, your External Interface will also be ppp0. If you connect -using ISDN, you external interface will be ippp0.

      - -

      -    If your external interface is ppp0 or ippp0 then you will -want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

      - -

      Your Local Interface 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 cross-over - cable).

      - -

      Your DMZ Interface 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 cross-over cable).

      - -

      -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 -all.

      - -

      For the remainder of this Guide, we will assume that:

      - -
        -
      • -

        The external interface is eth0.

        -
        • -
      • -

        The Local interface is eth1.

        -
        • -
      • -

        The DMZ interface is eth2.

        -
        • - -
      - -

      The Shorewall default configuration does not define the contents - of any zone. To define the above configuration using the /etc/shorewall/interfaces -file, that file would might contain:

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918
      loceth1detect 
      dmzeth2detect 
      -
      - -

      -    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.

      - -

      Example:

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918
      loceth1detect 
      loceth2detectdhcp
      -
      - -
      -

      When you have more than one interface to a zone, you will - usually want a policy that permits intra-zone traffic:

      -
      - -
      -
      + +
      - + @@ -421,80 +209,297 @@ one entry for each interface and repeat the zone name as many times as necessar - + - - + + + + + + + + + + + + + + + +
      Source Zone Destination Zone Policy
      loclocnet ACCEPT    
      netallDROPinfo 
      allallREJECTinfo 
      -
      - + +

      The above policy will:

      + +
        +
      1. allow all connection requests from your local network to the internet
        2. +
      2. drop (ignore) all connection requests from the internet to your +firewall or local network and log a message at the info level +(here is a description +of log levels).
        3. +
      3. reject all other connection requests and log a message at the info + 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.
        4. + +
      + +

      +     At this point, edit your /etc/shorewall/policy and make any changes +that you wish.

      + +

      3.0 Network Interfaces

      + +

      For the remainder of this guide, we'll refer to the following + diagram. While it may not look like your own network, it can be used to + illustrate the important aspects of Shorewall configuration.

      + +

      In this diagram:

      + +
        +
      • 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 +that if one of those servers is compromised, you still have the firewall +between the compromised system and your local systems.
        • +
      • The Local Zone consists of systems Local 1, Local 2 and Local 3. +
        • +
      • All systems from the ISP outward comprise the Internet Zone.
        • + +
      + +

      +

      + +

      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 /etc/shorewall/interfaces + file.

      + +

      The firewall illustrated above has three network interfaces. + Where Internet connectivity is through a cable or DSL "Modem", the External + Interface will be the Ethernet adapter that is connected to that "Modem" + (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External Interface + will be a ppp interface (e.g., ppp0). If you connect via a regular + modem, your External Interface will also be ppp0. If you connect +using ISDN, you external interface will be ippp0.

      + +

      +     If your external interface is ppp0 or ippp0 then you +will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

      + +

      Your Local Interface 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 cross-over + cable).

      + +

      Your DMZ Interface 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 cross-over cable).

      + +

      + 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 +all.

      + +

      For the remainder of this Guide, we will assume that:

      + +
        +
      • +

        The external interface is eth0.

        +
        • +
      • +

        The Local interface is eth1.

        +
        • +
      • +

        The DMZ interface is eth2.

        +
        • + +
      + +

      The Shorewall default configuration does not define the contents + of any zone. To define the above configuration using the /etc/shorewall/interfaces + file, that file would might contain:

      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918
      loceth1detect 
      dmzeth2detect 
      +
      +

      -    You may define more complicated zones using the + +

      Example:

      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918
      loceth1detect 
      loceth2detectdhcp
      +
      + +
      +

      When you have more than one interface to a zone, you will + usually want a policy that permits intra-zone traffic:

      +
      + +
      +
      + + + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      loclocACCEPT  
      +
      +
      + +

      +     You may define more complicated zones using the /etc/shorewall/hosts file but in most - cases, that isn't necessary.

      - + cases, that isn't necessary.

      +

      4.0 Addressing, Subnets and Routing

      - +

      Normally, your ISP will assign you a set of Public -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 + 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.

      - + though, some background is in order.

      +

      If you are thoroughly familiar with IP addressing and routing, - you may go to the next section.

      - + you may go to the next section.

      +

      The following discussion barely scratches the surface of addressing and routing. If you are interested in learning more about this subject, I highly recommend "IP Fundamentals: What Everyone Needs to Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      - +

      4.1 IP Addresses

      - +

      IP version 4 (IPv4) addresses are 32-bit numbers. -The notation w.x.y.z refers to an address where the high-order byte has value -"w", the next byte has value "x", etc. If we take the address 192.0.2.14 -and express it in hexadecimal, we get:

      - -
      + The notation w.x.y.z refers to an address where the high-order byte has +value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + and express it in hexadecimal, we get:

      + +

      C0.00.02.0E

      -
      - +
      +

      or looking at it as a 32-bit integer

      - -
      + +

      C000020E

      -
      - +
      +

      4.2 Subnets

      - +

      You will still hear the terms "Class A network", "Class B - network" and "Class C network". In the early days of IP, networks only + 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):

      - -
      + +

      Class A - netmask 255.0.0.0, size = 2 ** 24

      - +

      Class B - netmask 255.255.0.0, size = 2 ** 16

      - +

      Class C - netmask 255.255.255.0, size = 256

      -
      - +
      +

      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 netmask. The netmask is + of the high order byte of its address so you could look at an IP address + and immediately determine the associated netmask. The netmask is a number that when logically ANDed with an address isolates the network -number; the remainder of the address is the host number. For + number; the remainder of the address is the host number. For example, in the Class C address 192.0.2.14, the network number is hex C00002 and the host number is hex 0E.

      - +

      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 corporations and universities were assigned their own class A network!). @@ -502,1928 +507,1951 @@ After some false starts, the current technique of subnetting these networks into smaller subnetworks evolved; that technique is referred to as Classless InterDomain Routing (CIDR). Today, any system that you are likely to work with will understand CIDR and Class-based networking -is largely a thing of the past.

      - + is largely a thing of the past.

      +

      A subnetwork (often referred to as a subnet) is - a contiguous set of IP addresses such that:

      - + a contiguous set of IP addresses such that:

      +
        -
      1. +

      2. The number of addresses in the set is a power of 2; and

        -
        3. -
      3. +
        4. +

      4. The first address in the set is a multiple of the set -size.

        -
        5. -
      5. + size.

        +
        6. +

      6. The first address in the subnet is reserved and is referred -to as the subnet address.

        -
        7. -
      7. + to as the subnet address.

        +
        8. +

      8. The last address in the subnet is reserved as the subnet's -broadcast address.

        -
        9. - + broadcast address.

        + +
      - +

      As you can see by this definition, in each subnet of size -n there are (n - 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. -

      - + n there are (n - 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. +

      +

      Since n is a power of two, we can easily calculate -the Natural Logarithm (log2) of n. For the more common -subnet sizes, the size and its natural logarithm are given in the following -table:

      - -
      + the Natural Logarithm (log2) of n. For the more common + subnet sizes, the size and its natural logarithm are given in the following + table:

      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      nlog2 n(32 - log2 n)
      8329
      16428
      32527
      64626
      128725
      256824
      512923
      10241022
      20481121
      40961220
      81921319
      163841418
      327681517
      655361616
      nlog2 n(32 - log2 n)
      8329
      16428
      32527
      64626
      128725
      256824
      512923
      10241022
      20481121
      40961220
      81921319
      163841418
      327681517
      655361616
      -
      - +
      +

      You will notice that the above table also contains a column - for (32 - log2 n). That number is the Variable Length Subnet -Mask for a network of size n. From the above table, we can + for (32 - log2 n). That number is the Variable Length Subnet + Mask for a network of size n. From the above table, we can derive the following one which is a little easier to use.

      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Size of SubnetVLSMSubnet Mask
      8/29255.255.255.248
      16/28255.255.255.240
      32/27255.255.255.224
      64/26255.255.255.192
      128/25255.255.255.128
      256/24255.255.255.0
      512/23255.255.254.0
      1024/22255.255.252.0
      2048/21255.255.248.0
      4096/20255.255.240.0
      8192/19255.255.224.0
      16384/18255.255.192.0
      32768/17255.255.128.0
      65536/16255.255.0.0
      2 ** 24/8255.0.0.0
      Size of SubnetVLSMSubnet Mask
      8/29255.255.255.248
      16/28255.255.255.240
      32/27255.255.255.224
      64/26255.255.255.192
      128/25255.255.255.128
      256/24255.255.255.0
      512/23255.255.254.0
      1024/22255.255.252.0
      2048/21255.255.248.0
      4096/20255.255.240.0
      8192/19255.255.224.0
      16384/18255.255.192.0
      32768/17255.255.128.0
      65536/16255.255.0.0
      2 ** 24/8255.0.0.0
      -
      - +
      +

      Notice that the VLSM is written with a slash ("/") -- you -will often hear a subnet of size 64 referred to as a "slash 26" subnet -and one of size 8 referred to as a "slash 29".

      - + will often hear a subnet of size 64 referred to as a "slash 26" subnet + and one of size 8 referred to as a "slash 29".

      +

      The subnet's mask (also referred to as its netmask) is -simply a 32-bit number with the first "VLSM" bits set to one and the remaining -bits set to zero. For example, for a subnet of size 64, the subnet mask -has 26 leading one bits:

      - -
      + simply a 32-bit number with the first "VLSM" bits set to one and the +remaining bits set to zero. For example, for a subnet of size 64, the +subnet mask has 26 leading one bits:

      + +

      11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 -= 255.255.255.192

      -
      - + = 255.255.255.192

      +
      +

      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 + 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.

      - +

      For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork as + Variable Length Subnet Mask is /v, we denote the subnetwork as "a.b.c.d/v" using CIDR Notation. 

      - +

      Example:

      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
      Subnet:10.10.10.0 - 10.10.10.127
      Subnet Size:128
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.127
      CIDR Notation:10.10.10.0/25
      Subnet:10.10.10.0 - 10.10.10.127
      Subnet Size:128
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.127
      CIDR Notation:10.10.10.0/25
      -
      - +
      +

      There are two degenerate subnets that need mentioning; namely, -the subnet with one member and the subnet with 2 ** 32 members.

      - -
      + the subnet with one member and the subnet with 2 ** 32 members.

      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
      132255.255.255.255a.b.c.d/32
      2 ** 3200.0.0.00.0.0.0/0
      Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
      132255.255.255.255a.b.c.d/32
      2 ** 3200.0.0.00.0.0.0/0
      -
      - -

      So any address a.b.c.d may also be written a.b.c.d/32 -and the set of all possible IP addresses is written 0.0.0.0/0.

      - -

      Later in this guide, you will see the notation a.b.c.d/v - used to describe the ip configuration of a network interface (the 'ip' utility - also uses this syntax). This simply means that the interface is configured -with ip address a.b.c.d and with the netmask that corresponds to -VLSM /v.

      - -

      Example: 192.0.2.65/29

      - -

          The interface is configured with IP address 192.0.2.65 -and netmask 255.255.255.248.

      - -

      4.3 Routing

      - -

      One of the purposes of subnetting is that it forms the basis - for routing. Here's the routing table on my firewall:

      - -
      -
      - 
      [root@gateway root]# netstat -nr
      Kernel IP routing table
      Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
      192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
      206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
      206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
      192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
      192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
      192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
      206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
      192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
      127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
      0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
      [root@gateway root]#
      -
      - + +

      So any address a.b.c.d may also be written a.b.c.d/32 + and the set of all possible IP addresses is written 0.0.0.0/0.

      + +

      Later in this guide, you will see the notation a.b.c.d/v + used to describe the ip configuration of a network interface (the 'ip' +utility also uses this syntax). This simply means that the interface is +configured with ip address a.b.c.d and with the netmask that corresponds +to VLSM /v.

      + +

      Example: 192.0.2.65/29

      + +

          The interface is configured with IP address 192.0.2.65 + and netmask 255.255.255.248.

      + +

      4.3 Routing

      + +

      One of the purposes of subnetting is that it forms the basis + for routing. Here's the routing table on my firewall:

      + +
      +
      + 
      [root@gateway root]# netstat -nr
      Kernel IP routing table
      Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
      192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
      206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
      206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
      192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
      192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
      192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
      206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
      192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
      127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
      0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
      [root@gateway root]#
      +
      +
      +

      The device texas is a GRE tunnel to a peer site in -the Dallas, Texas area.
      -
      - The first three routes are host routes 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 packets to a subnetwork. -The last route is the default route and the gateway mentioned in -that route is called the default gateway.

      - + the Dallas, Texas area.
      +
      + The first three routes are host routes 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 +packets to a subnetwork. The last route is the default route and +the gateway mentioned in that route is called the default gateway.

      +

      When the kernel is trying to send a packet to IP address A, it starts at the top of the routing table and:

      - +
        -
      • +

      • A is logically ANDed with the 'Genmask' value in the table entry.

        -
        • -
      • +
        • +

      • The result is compared with the 'Destination' value in -the table entry.

        -
        • -
      • + the table entry.

        +
        • +

      • If the result and the 'Destination' value are the same, -then:

        - + then:

        +
          -
        • +

        • If the 'Gateway' column is non-zero, the packet is -sent to the gateway over the interface named in the 'Iface' column.

          -
          • -
        • + sent to the gateway over the interface named in the 'Iface' column.

          +
          • +

        • Otherwise, the packet is sent directly to A over -the interface named in the 'iface' column.

          -
          • - + the interface named in the 'iface' column.

          + +
        -
        • -
      • +
        • +

      • Otherwise, the above steps are repeated on the next entry -in the table.

        -
        • - + in the table.

        + +
      - +

      Since the default route matches any IP address (A land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table entries are sent to the default gateway which is usually a router at your ISP.

      - +

      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:

      - -
      -
      + 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:

      + +
      +
      192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
      -
      - +
      +

      So to route a packet to 192.168.1.5, the packet is sent directly over eth2.

      -
      - + +

      One more thing needs to be emphasized -- all outgoing packet -are sent using the routing table and reply packets are not a special case. -There seems to be a common mis-conception whereby people think that request -packets are like salmon and contain a genetic code that is magically transferred -to reply packets so that the replies follow the reverse route taken by the -request. That isn't the case; the replies may take a totally different route -back to the client than was taken by the requests -- they are totally independent.

      - + are sent using the routing table and reply packets are not a special case. + There seems to be a common mis-conception whereby people think that request + packets are like salmon and contain a genetic code that is magically transferred + to reply packets so that the replies follow the reverse route taken by +the request. That isn't the case; the replies may take a totally different +route back to the client than was taken by the requests -- they are totally +independent.

      +

      4.4 Address Resolution Protocol

      - +

      When sending packets over Ethernet, IP addresses aren't used. - Rather Ethernet addressing is based on Media Access Control (MAC) - addresses. Each Ethernet device has it's own unique  MAC address which is - burned into a PROM on the device during manufacture. You can obtain the -MAC of an Ethernet device using the 'ip' utility:

      - -
      -
      + Rather Ethernet addressing is based on Media Access Control (MAC) + addresses. Each Ethernet device has it's own unique  MAC address which +is burned into a PROM on the device during manufacture. You can obtain +the MAC of an Ethernet device using the 'ip' utility:

      + +
      + 
      [root@gateway root]# ip addr show eth0
      2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
      link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
      inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
      inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
      inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
      [root@gateway root]#
      -
      -
      - -
      +
      +
      + +

      As you can see from the above output, the MAC is 6 bytes (48 bits) wide. A card's MAC is usually also printed on a label attached to the card itself.

      -
      - -
      +
      + +

      Because IP uses IP addresses and Ethernet uses MAC addresses, - a mechanism is required to translate an IP address into a MAC address; -that is the purpose of the Address Resolution Protocol (ARP). Here -is ARP in action:

      -
      - -
      -
      -
      + a mechanism is required to translate an IP address into a MAC address; + that is the purpose of the Address Resolution Protocol (ARP). +Here is ARP in action:

      +
      + +
      +
      + 
      [root@gateway root]# tcpdump -nei eth2 arp
      tcpdump: listening on eth2
      09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
      09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

      2 packets received by filter
      0 packets dropped by kernel
      [root@gateway root]#
      +
      +
      +
      + +

      In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants + to know the MAC of the device with IP address 192.168.1.19. The system +having that IP address is responding that the MAC address of the device +with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

      + +

      In order to avoid having to exchange ARP information each + time that an IP packet is to be sent, systems maintain an ARP cache + of IP<->MAC correspondences. You can see the ARP cache on your system + (including your Windows system) using the 'arp' command:

      + +
      +
      + 
      [root@gateway root]# arp -na
      ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
      ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
      ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
      ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
      ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
      -
      - -

      In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants -to know the MAC of the device with IP address 192.168.1.19. The system having -that IP address is responding that the MAC address of the device with IP -address 192.168.1.19 is 0:6:25:aa:8a:f0.

      - -

      In order to avoid having to exchange ARP information each -time that an IP packet is to be sent, systems maintain an ARP cache -of IP<->MAC correspondences. You can see the ARP cache on your system -(including your Windows system) using the 'arp' command:

      - -
      -
      - 
      [root@gateway root]# arp -na
      ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
      ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
      ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
      ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
      ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
      -
      -
      - +

      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->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 + the 'n' option (Windows 'arp' doesn't allow that option) which causes the + 'arp' program to forego IP->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.

      - +

      4.5 RFC 1918

      - +

      IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet + who delegates allocations on a geographic basis to Regional Internet Registries (RIRs). For example, allocation for the Americas and for sub-Sahara Africa is delegated to the American - Registry for Internet Numbers (ARIN). These RIRs may in turn delegate -to national registries. Most of us don't deal with these registrars but + Registry for Internet Numbers (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.

      - +

      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 use of Private IP addresses. RFC 1918 reserves several IP address ranges for this purpose:

      - -
      + +
           10.0.0.0    - 10.255.255.255
           172.16.0.0  - 172.31.255.255
           192.168.0.0 - 192.168.255.255
      -
      - -
      +
      + +

      The addresses reserved by RFC 1918 are sometimes referred -to as non-routable because the Internet backbone routers don't + to as non-routable because the Internet backbone routers don't forward packets which have an RFC-1918 destination address. This is understandable - given that anyone can select any of these addresses for their private + given that anyone can select any of these addresses for their private use.

      -
      - -
      +
      + +

      When selecting addresses from these ranges, there's a couple - of things to keep in mind:

      -
      - -
      + of things to keep in mind:

      +
      + +
        -
      • +

      • As the IPv4 address space becomes depleted, more and more organizations (including ISPs) are beginning to use RFC 1918 addresses -in their infrastructure.

        -
        • -
      • + in their infrastructure.

        +
        • +

      • You don't want to use addresses that are being used by - your ISP or by another organization with whom you want to establish + your ISP or by another organization with whom you want to establish a VPN relationship.

        -
        • + +
      -
      - -
      +
      + +

      So it's a good idea to check with your ISP to see if they -are using (or are planning to use) private addresses before you decide -the addresses that you are going to use.

      -
      - -
      + are using (or are planning to use) private addresses before you decide + the addresses that you are going to use.

      +
      + +

      5.0 Setting up your Network

      -
      - -
      +
      + +

      The choice of how to set up your network depends primarily -on how many Public IP addresses you have vs. how many addressable entities -you have in your network. Regardless of how many addresses you have, your -ISP will handle that set of addresses in one of two ways:

      -
      - -
      + on how many Public IP addresses you have vs. how many addressable entities + you have in your network. Regardless of how many addresses you have, +your ISP will handle that set of addresses in one of two ways:

      +
      + +
        -
      1. +

      2. Routed - Traffic to any of your addresses will -be routed through a single gateway address. 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.

        -
        3. -
      3. + be routed through a single gateway address. 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.

        +
        4. +

      4. Non-routed - Your ISP will send traffic to each -of your addresses directly.

        -
        5. + of your addresses directly.

        + +
      -
      - -
      +
      + +

      In the subsections that follow, we'll look at each of these - separately.

      -
      - -
      + separately.
      +

      +

      Before we begin, there is one thing for you to check:

      +

      +     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:
      +

      +
        +
      • NAT_ENABLED=Yes
        • +
      • IP_FORWARDING=On
        +
        • +
      +
      + +

      5.1 Routed

      -
      - -
      +
      + +

      Let's assume that your ISP has assigned you the subnet 192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses - 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address is - 192.0.2.65. Your ISP has also told you that you should use a netmask of - 255.255.255.0 (so your /28 is part of a larger /24). With this many IP - addresses, you are able to subnet your /28 into two /29's and set up your - network as shown in the following diagram.

      -
      - -
      + 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address +is 192.0.2.65. Your ISP has also told you that you should use a netmask +of 255.255.255.0 (so your /28 is part of a larger /24). With this many +IP addresses, you are able to subnet your /28 into two /29's and set +up your network as shown in the following diagram.

      +
      + +

      -

      -
      - -
      +

      +
      + +

      Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ would be configured to 192.0.2.66 and the default gateway for hosts in the local network would be 192.0.2.73.

      -
      - -
      +
      + +

      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.

      -
      - -
      + 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.

      +
      + +

      The astute reader may have noticed that the Firewall/Router's - external interface is actually part of the DMZ subnet (192.0.2.64/29). -What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The routing -table on DMZ 1 will look like this:

      -
      - -
      -
      + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The +routing table on DMZ 1 will look like this:

      +
      + +
      +
      Kernel IP routing table
      Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
      192.0.2.64 	0.0.0.0 	255.255.255.248 U     40  0         0 eth0
      0.0.0.0 	192.0.2.66	0.0.0.0 	UG    40  0         0 eth0
      -
      -
      - -
      +
      + + +

      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 DMZ Interface!! DMZ 1 can then send Ethernet frames addressed -to that MAC address and the frames will be received (correctly) by the -firewall/router.

      -
      - -
      + 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 DMZ Interface!! DMZ 1 can then send Ethernet frames addressed + to that MAC address and the frames will be received (correctly) by the + firewall/router.

      +
      + +

      It is this rather unexpected ARP behavior on the part of 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.

      -
      - -
      + interfaces that connect to the hub/switch can respond! It is then a race + as to which "here-is" response reaches the sender first.

      +
      + +

      5.2 Non-routed

      -
      - -
      +
      + +

      If you have the above situation but it is non-routed, you can configure your network exactly as described above with one additional -twist; simply specify the "proxyarp" option on all three firewall interfaces -in the /etc/shorewall/interfaces file.

      -
      - -
      + twist; simply specify the "proxyarp" option on all three firewall interfaces + in the /etc/shorewall/interfaces file.

      +
      + +

      Most of us don't have the luxury of having enough public IP addresses to set up our networks as shown in the preceding example (even if the setup is routed).

      -
      - -
      +
      + +

      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 + 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.

      -
      - -
      +
      + +

      Clearly, that set of addresses doesn't comprise a subnetwork - and there aren't enough addresses for all of the network interfaces. There -are four different techniques that can be used to work around this problem.

      -
      - -
      + and there aren't enough addresses for all of the network interfaces. +There are four different techniques that can be used to work around this +problem.

      +
      + +
        -
      • +

      • Source Network Address Translation (SNAT). -

        -
        • -
      • +

        +
        • +

      • Destination Network Address Translation (DNAT) -also known as Port Forwarding.

        -
        • -
      • + also known as Port Forwarding.

        +
        • +

      • Proxy ARP.

        -
        • -
      • +
        • +

      • Network Address Translation (NAT) also referred -to as Static NAT.

        -
        • + to as Static NAT.

        + +
      -
      - -
      +
      + +

      Often a combination of these techniques is used. Each of these will be discussed in the sections that follow.

      -
      - -
      +
      + +

       5.2.1 SNAT

      -
      - -
      +
      + +

      With SNAT, an internal LAN segment is configured using RFC -1918 addresses. When a host A on this internal segment initiates -a connection to host 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 responds and the response is received -by the firewall, the firewall changes the destination address back to + 1918 addresses. When a host A on this internal segment initiates + a connection to host 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 responds and the response is received + by the firewall, the firewall changes the destination address back to the RFC 1918 address of A and forwards the response back to A.

      -
      - -
      +
      + +

      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 + 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.

      -
      - -
      +
      + +

      -

      -
      - + + +
      The local zone has been subnetted as 192.168.201.0/29 -(netmask 255.255.255.248).
      - + (netmask 255.255.255.248). +
       
      - +
      -    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).
      - +     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). +
       
      - +
      -    SNAT is configured in Shorewall using the /etc/shorewall/masq file.
      - -
      -
      + +
      +
      - - - - - - - - - - - - - + + + + + + + + + + + + +
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      -
      -
      - -
      +
      +
      + +

      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 + 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.

      -
      - -
      +
      + +

      5.2.2 DNAT

      -
      - -
      +
      + +

      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.

      -
      - -
      + 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.

      +
      + +

      -     Suppose that your daughter wants to run a web server on her system -"Local 3". You could allow connections to the internet to her server by -adding the following entry in /etc/shorewall/rules:

      -
      - -
      -
      +      Suppose that your daughter wants to run a web server on her system + "Local 3". You could allow connections to the internet to her server +by adding the following entry in /etc/shorewall/rules:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
      DNATnetloc:192.168.201.4tcpwww-192.0.2.176
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
      DNATnetloc:192.168.201.4tcpwww-192.0.2.176
      -
      -
      - -
      +
      + + +

      If one of your daughter's friends at address A wants -to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external -IP address) and the firewall will rewrite the destination IP address to -192.168.201.4 (your daughter's system) and forward the request. When your -daughter's server responds, the firewall will rewrite the source address -back to 192.0.2.176 and send the response back to A.

      -
      - -
      + IP address) and the firewall will rewrite the destination IP address +to 192.168.201.4 (your daughter's system) and forward the request. When +your daughter's server responds, the firewall will rewrite the source +address back to 192.0.2.176 and send the response back to A.

      +
      + +

      This example used the firewall's external IP address for DNAT. You can use another of your public IP addresses but Shorewall will not add that address to the firewall's external interface for you.

      -
      - -
      +
      + +

      5.2.3 Proxy ARP

      -
      - -
      +
      + +

      The idea behind proxy ARP is that:

      -
      - -
      +
      + +
        -
      • +

      • A host H behind your firewall is assigned one of your public IP addresses (A) and is assigned the same netmask (M) as the firewall's external interface.

        -
        • -
      • +
        • +

      • The firewall responds to ARP "who has" requests for A. -

        -
        • -
      • +

        +
        • +

      • When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will respond (with the MAC if the firewall interface to H).

        -
        • + +
      -
      - -
      +
      + +

      Let suppose that we decide to use Proxy ARP on the DMZ in -our example network.

      -
      - -
      + our example network.

      +
      + +

      -

      -
      - +

      + +
      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 + 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.
      - +
       
      - +
      -    The Shorewall configuration of Proxy ARP is done using the /etc/shorewall/proxyarp file.
      - -
      -
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ADDRESSINTERFACEEXTERNALHAVE ROUTE
      192.0.2.177eth2eth0No
      192.0.2.178eth2eth0No
      ADDRESSINTERFACEEXTERNALHAVE ROUTE
      192.0.2.177eth2eth0No
      192.0.2.178eth2eth0No
      -
      -
      - -
      +
      +
      + +

      Because the HAVE ROUTE column contains No, Shorewall will -add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

      -
      - -
      + add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

      +
      + +

      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 + 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:

      -
      - -
      + 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:

      +
      + +
      	tcpdump -nei eth0 icmp
      -
      - -
      +
      + +

      Now from 192.0.2.177, ping the default gateway (which we are assuming is 192.0.2.254):

      -
      - -
      +
      + +
      	ping 192.0.2.254
      -
      - -
      +
      + +

      We can now observe the tcpdump output:

      -
      - -
      +
      + +
      	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
      	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
      -
      - -
      +
      + +

      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 DMZ 1. In other words, the gateway's ARP cache + 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.

      -
      - -
      +
      + +

      5.2.4 Static NAT

      -
      - -
      +
      + +

      With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public -IP addresses. For outgoing connections SNAT occurs and on incoming connections - DNAT occurs. Let's go back to our earlier example involving your daughter's -web server running on system Local 3.

      -
      - -
      + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT occurs and on incoming connections + DNAT occurs. Let's go back to our earlier example involving your daughter's + web server running on system Local 3.

      +
      + +

      -

      -
      - -
      +

      +
      + +

      Recall that in this setup, the local network is using SNAT -and is sharing the firewall external IP (192.0.2.176) for outbound connections. - This is done with the following entry in /etc/shorewall/masq:

      -
      - -
      -
      + and is sharing the firewall external IP (192.0.2.176) for outbound connections. + This is done with the following entry in /etc/shorewall/masq:

      +
      + +
      +
      - - - - - - - - - - - - - + + + + + + + + + + + + +
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      -
      -
      - -
      + +
      + +

      -    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 /etc/shorewall/nat.

      -
      - -
      -
      +     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 /etc/shorewall/nat.

      +
      + +
      +
      - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
      EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
      192.0.2.179eth0192.168.201.4NoNo
      EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
      192.0.2.179eth0192.168.201.4NoNo
      -
      -
      - -
      + +
      + +

      With this entry in place, you daughter has her own IP address - and the other two local systems share the firewall's IP address.

      -
      - -
      + and the other two local systems share the firewall's IP address.

      +
      + +

      -    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:

      -
      - -
      -
      +     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:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
      ACCEPTnetloc:192.168.201.4tcpwww  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
      ACCEPTnetloc:192.168.201.4tcpwww  
      -
      -
      - -
      + +
      + +

      5.3 Rules

      -
      - -
      +
      + +

      -    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 DNAT rules which -cause address translation and allow the translated connection request +     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 DNAT rules 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.

      -
      - -
      + your firewall is to use ACCEPT rules.

      +
      + +

      NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't - used in this section, they won't be shown

      -
      - -
      + used in this section, they won't be shown

      +
      + +

      You probably want to allow ping between your zones:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORT
      ACCEPTnetdmzicmpecho-request
      ACCEPTnetlocicmpecho-request
      ACCEPTdmzlocicmpecho-request
      ACCEPTlocdmzicmpecho-request
      ACTIONSOURCEDESTINATIONPROTOCOLPORT
      ACCEPTnetdmzicmpecho-request
      ACCEPTnetlocicmpecho-request
      ACCEPTdmzlocicmpecho-request
      ACCEPTlocdmzicmpecho-request
      -
      -
      - -
      + +
      + +

      Let's suppose that you run mail and pop3 servers on DMZ 2 -and a Web Server on DMZ 1. The rules that you would need are:

      -
      - -
      -
      + and a Web Server on DMZ 1. The rules that you would need are:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
      ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
      ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
      ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
      ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
      ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
      ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
      ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
      ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
      ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
      ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
      ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
      ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
      ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
      ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
      ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
      ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
      -
      -
      - -
      + +
      + +

      If you run a public DNS server on 192.0.2.177, you would need to add the following rules:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
      ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
      ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
      ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
      ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
      ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
      ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
      ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
      ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
      ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
      ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
      ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
      ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
      ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
      ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
      -
      -
      - -
      + +
      + +

      You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through -its scp utility can also do publishing and software update distribution.

      -
      - -
      -
      + and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTlocdmztcpssh# SSH to the DMZ
      ACCEPTlocfwtcpssh# SSH to the Firewall
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTlocdmztcpssh# SSH to the DMZ
      ACCEPTlocfwtcpssh# SSH to the Firewall
      -
      -
      - -
      + +
      + +

      5.4 Odds and Ends

      -
      - -
      +
      + +

      The above discussion reflects my personal preference for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer to use NAT only in cases where a system that is part of an RFC 1918 subnet needs to have it's own public IP. 

      -
      - -
      +
      + +

      -    If you haven't already, it would be a good idea to browse through - /etc/shorewall/shorewall.conf 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.

      -
      - -
      +     If you haven't already, it would be a good idea to browse through + /etc/shorewall/shorewall.conf 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.

      +
      + +

      In case you haven't been keeping score, here's the final set of configuration files for our sample network. Only those that were modified from the original installation are shown.

      -
      - -
      +
      + +

      /etc/shorewall/interfaces (The "options" will be very site-specific).

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918,routefilter
      loceth1detect 
      dmzeth2detect 
      ZoneInterfaceBroadcastOptions
      neteth0detectnorfc1918,routefilter
      loceth1detect 
      dmzeth2detect 
      -
      -
      - -
      + +
      + +

      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.

      -
      - -
      -
      + 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.

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ZoneInterfaceBroadcastOptions
      neteth0192.0.2.255norfc1918,routefilter
      loceth1192.168.201.7 
      dmzeth2192.168.202.7 
      ZoneInterfaceBroadcastOptions
      neteth0192.0.2.255norfc1918,routefilter
      loceth1192.168.201.7 
      dmzeth2192.168.202.7 
      -
      -
      - -
      + +
      + +

      /etc/shorewall/masq - Local subnet

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - + + + + + + + + + + + + +
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      INTERFACESUBNETADDRESS
      eth0192.168.201.0/29192.0.2.176
      -
      -
      - -
      + +
      + +

      /etc/shorewall/proxyarp - DMZ

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ADDRESSINTERFACEEXTERNALHAVE ROUTE
      192.0.2.177eth2eth0No
      192.0.2.178eth2eth0No
      ADDRESSINTERFACEEXTERNALHAVE ROUTE
      192.0.2.177eth2eth0No
      192.0.2.178eth2eth0No
      -
      -
      - -
      + +
      + +

      /etc/shorewall/nat- Daughter's System

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
      EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
      192.0.2.179eth0192.168.201.4NoNo
      EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
      192.0.2.179eth0192.168.201.4NoNo
      -
      -
      - -
      + +
      + +

      /etc/shorewall/rules

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
      ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
      ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
      ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
      ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
      ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
      ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
      ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
      ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
      ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
      ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
      ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
      ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
      ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
      ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
      ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
      ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
      ACCEPTnetdmzicmpecho-request# Ping
      ACCEPTnetlocicmpecho-request#  "
      ACCEPTdmzlocicmpecho-request# "
      ACCEPTlocdmzicmpecho-request# "
      ACCEPTlocdmztcpssh# SSH to the DMZ
      ACCEPTlocfwtcpssh# SSH to the Firewall
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
      ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
      ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
      ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
      ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
      ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
      ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
      ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
      ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
      ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
      ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
      ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
      ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
      ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
      ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
      ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
      ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
      ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
      ACCEPTnetdmzicmpecho-request# Ping
      ACCEPTnetlocicmpecho-request#  "
      ACCEPTdmzlocicmpecho-request# "
      ACCEPTlocdmzicmpecho-request# "
      ACCEPTlocdmztcpssh# SSH to the DMZ
      ACCEPTlocfwtcpssh# SSH to the Firewall
      -
      -
      - -
      + +
      + +

      6.0 DNS

      -
      - -
      +
      + +

      Given the collection of RFC 1918 and public addresses in this setup, it only makes sense to have separate internal and external DNS servers. You can combine the two into a single BIND 9 server using Views. If you are not interested in Bind 9 views, you can go to the next section.

      -
      - -
      -

      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 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.

      -
      - -
      -

      The /etc/named.conf file would look like this:

      -
      - -
      -
      -
      - 
      options {
      	directory "/var/named";
      	listen-on { 127.0.0.1 ; 192.0.2.177; };
      };

      logging {
      	channel xfer-log {
      		file "/var/log/named/bind-xfer.log";
      		print-category yes;
      		print-severity yes;
      		print-time yes;
      		severity info;
      	};
      	category xfer-in { xfer-log; };
      	category xfer-out { xfer-log; };
      	category notify { xfer-log; };
      };
      -
      +
      -
      +
      +

      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 +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.

      +
      + +
      +

      The /etc/named.conf file would look like this:

      +
      + +
      +
      +
      + 
      options {
      	directory "/var/named";
      	listen-on { 127.0.0.1 ; 192.0.2.177; };
      };

      logging {
      	channel xfer-log {
      		file "/var/log/named/bind-xfer.log";
      		print-category yes;
      		print-severity yes;
      		print-time yes;
      		severity info;
      	};
      	category xfer-in { xfer-log; };
      	category xfer-out { xfer-log; };
      	category notify { xfer-log; };
      };
      +
      + + 
      #
      # This is the view presented to our internal systems
      #

      view "internal" {
      	#
      	# These are the clients that see this view
      	#
      	match-clients { 192.168.201.0/29;
      			192.168.202.0/29;
      			127.0.0/24;
      			192.0.2.176/32; 
      			192.0.2.178/32;
      			192.0.2.179/32;
      			192.0.2.180/32; };
      	#
      	# If this server can't complete the request, it should use outside
      	# servers to do so
      	#
      	recursion yes;

      	zone "." in {
      		type hint;
      		file "int/root.cache";
      	};

      	zone "foobar.net" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "int/db.foobar";
      	};

      	zone "0.0.127.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "int/db.127.0.0";	
      	};

      	zone "201.168.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "int/db.192.168.201";
      	};

      	zone "202.168.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "int/db.192.168.202";
      	};

      	zone "176.2.0.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "db.192.0.2.176";
      	};

      	zone "177.2.0.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "db.192.0.2.177";
      	};

      	zone "178.2.0.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "db.192.0.2.178";
      	};

      	zone "179.2.0.192.in-addr.arpa" in {
      		type master;
      		notify no;
      		allow-update { none; };
      		file "db.206.124.146.179";
      	};

      };
      #
      # This is the view that we present to the outside world
      #
      view "external" {
      	match-clients { any; };
      	#
      	# If we can't answer the query, we tell the client so
      	#
      	recursion no;

      	zone "foobar.net" in {
      		type master;
      		notify yes;
      		allow-update {none; };
      		allow-transfer { <secondary NS IP>; };
      		file "ext/db.foobar";
      	};

      	zone "176.2.0.192.in-addr.arpa" in {
       		type master;
      		notify yes;
      		allow-update { none; };
      		allow-transfer { <secondary NS IP>; };
      		file "db.192.0.2.176";
      	};

      	zone "177.2.0.192.in-addr.arpa" in {
      		type master;
      		notify yes;
      		allow-update { none; };
      		allow-transfer { <secondary NS IP>; };
      		file "db.192.0.2.177";
      	};

      	zone "178.2.0.192.in-addr.arpa" in {
      		type master;
      		notify yes;
      		allow-update { none; };
      		allow-transfer { <secondary NS IP>; };
      		file "db.192.0.2.178";
      	};

      	zone "179.2.0.192.in-addr.arpa" in {
      		type master;
      		notify yes;
      		allow-update { none; };
      		allow-transfer { <secondary NS IP>; };
      		file "db.192.0.2.179";
      	};
      };
      -
      -
      -
      - -
      +
      + +
      + +

      Here are the files in /var/named (those not shown are usually - included in your bind disbribution).

      + included in your bind disbribution).

      +

      db.192.0.2.176 - This is the reverse zone for the firewall's -external interface

      -
      + external interface

      + +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
      ; Filename: db.192.0.2.176
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2001102303 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ) ; minimum (1 day)
      ;
      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800	IN NS	ns1.foobar.net.
      @	604800	IN NS	<name of secondary ns>.
      ;
      ; ############################################################
      ; Iverse Address Arpa Records (PTR's) 
      ; ############################################################
      176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
      -
      -
      - -
      + +
      + +
      db.192.0.2.177 - This is the reverse zone for the www/DNS -server -
      + server +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
      ; Filename: db.192.0.2.177
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2001102303 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ) ; minimum (1 day)
      ;
      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800	IN NS	ns1.foobar.net.
      @	604800	IN NS	<name of secondary ns>.
      ;
      ; ############################################################
      ; Iverse Address Arpa Records (PTR's) 
      ; ############################################################
      177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
      -
      -
      -
      - -
      + +
      + + +
      db.192.0.2.178 - This is the reverse zone for the mail -server -
      + server +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
      ; Filename: db.192.0.2.178
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2001102303 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ) ; minimum (1 day)
      ;
      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800	IN NS	ns1.foobar.net.
      @	604800	IN NS	<name of secondary ns>.
      ;
      ; ############################################################
      ; Iverse Address Arpa Records (PTR's) 
      ; ############################################################
      178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
      -
      -
      -
      - -
      + +
      + + +
      db.192.0.2.179 - This is the reverse zone for daughter's -web server's public IP -
      + web server's public IP +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
      ; Filename: db.192.0.2.179
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2001102303 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ) ; minimum (1 day)
      ;
      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800	IN NS	ns1.foobar.net.
      @	604800	IN NS	<name of secondary ns>.
      ;
      ; ############################################################
      ; Iverse Address Arpa Records (PTR's) 
      ; ############################################################
      179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
      -
      -
      -
      - -
      + +
      + + +

      int/db.127.0.0 - The reverse zone for localhost

      -
      - -
      -
      +
      + +
      +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
      ; Filename: db.127.0.0
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      				2001092901 ; serial
      				10800 ; refresh (3 hour)
      				3600 ; retry (1 hour)
      				604800 ; expire (7 days)
      				86400 ) ; minimum (1 day)
      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800		IN NS	ns1.foobar.net.

      ; ############################################################
      ; Iverse Address Arpa Records (PTR's)
      ; ############################################################
      1	86400		IN PTR	localhost.foobar.net.
      -
      -
      - -
      + +
      + +

      int/db.192.168.201 - Reverse zone for the local net. This -is only shown to internal clients

      -
      - -
      -
      + is only shown to internal clients

      +
      + +
      +
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
      ; Filename: db.192.168.201
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
      				2002032501 ; serial
      				10800 ; refresh (3 hour)
      				3600 ; retry (1 hour)
      				604800 ; expire (7 days)
      				86400 ) ; minimum (1 day)

      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @	604800		IN NS	ns1.foobar.net.

      ; ############################################################
      ; Iverse Address Arpa Records (PTR's)
      ; ############################################################
      1	86400		IN PTR 	gateway.foobar.net.
      2	86400		IN PTR	winken.foobar.net.
      3	86400		IN PTR	blinken.foobar.net.
      4	86400		IN PTR	nod.foobar.net.
      -
      -
      - -
      + +
      + +

      int/db.192.168.202 - Reverse zone for the firewall's DMZ interface

      -
      - -
      -
      -
      +
      + +
      +
      + 
      ; ############################################################
      ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
      ; Filename: db.192.168.202
      ; ############################################################
      @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
      				2002032501 ; serial
      				10800 ; refresh (3 hour)
      				3600 ; retry (1 hour)
      				604800 ; expire (7 days)
      				86400 ) ; minimum (1 day)

      ; ############################################################
      ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
      ; ############################################################
      @		604800	IN NS	ns1.foobar.net.

      ; ############################################################
      ; Iverse Address Arpa Records (PTR's)
      ; ############################################################
      1 		86400 IN PTR	dmz.foobar.net.
      -
      -
      -
      - -
      +
      +
      +
      + +

      int/db.foobar - Forward zone for use by internal clients.

      -
      - -
      -
      +
      + +
      +
      ;##############################################################
      ; Start of Authority for foobar.net.
      ; Filename: db.foobar
      ;##############################################################
      @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2002071501 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ); minimum (1 day)
      ;############################################################
      ; foobar.net Nameserver Records (NS)
      ;############################################################
      @ 		604800	IN NS	ns1.foobar.net.

      ;############################################################
      ; Foobar.net Office Records (ADDRESS)
      ;############################################################
      localhost	86400 	IN A 	127.0.0.1

      firewall	86400	IN A	192.0.2.176
      www		86400	IN A	192.0.2.177
      ns1 		86400	IN A 	192.0.2.177
      www		86400	IN A	192.0.2.177

      gateway		86400	IN A 	192.168.201.1
      winken		86400	IN A 	192.168.201.2
      blinken		86400	IN A	192.168.201.3
      nod		86400	IN A	192.168.201.4
      -
      -
      - -
      + +
      + +

      ext/db.foobar - Forward zone for external clients

      -
      - -
      -
      -
      +
      + +
      +
      + 
      ;##############################################################
      ; Start of Authority for foobar.net.
      ; Filename: db.foobar
      ;##############################################################
      @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
      			2002052901 ; serial
      			10800 ; refresh (3 hour)
      			3600 ; retry (1 hour)
      			604800 ; expire (7 days)
      			86400 ); minimum (1 day)
      ;############################################################
      ; Foobar.net Nameserver Records (NS)
      ;############################################################
      @		86400	IN NS	ns1.foobar.net.
      @		86400	IN NS	<secondary NS>.
      ;############################################################
      ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
      ;############################################################
      localhost	86400	IN A	127.0.0.1
      ;
      ; The firewall itself
      ;
      firewall	86400	IN A	192.0.2.176
      ;
      ; The DMZ
      ;
      ns1		86400	IN A	192.0.2.177
      www		86400	IN A	192.0.2.177
      mail		86400	IN A	192.0.2.178
      ;
      ; The Local Network
      ;
      nod		86400	IN A	192.0.2.179

      ;############################################################
      ; Current Aliases for foobar.net (CNAME)
      ;############################################################

      ;############################################################
      ; foobar.net MX Records (MAIL EXCHANGER)
      ;############################################################
      foobar.net.	86400	IN A	192.0.2.177
      		86400 	IN MX 0 mail.foobar.net.
      		86400	IN MX 1 <backup MX>.
      -
      -
      -
      - -
      +
      +
      +
      + +

      7.0 Starting and Stopping -Your Firewall

      -
      - -
      + Your Firewall +
      + +

      The installation procedure configures -your system to start Shorewall at system boot.

      -
      - -
      + your system to start Shorewall at system boot.

      +
      + +

      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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. -If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

      -
      - -
      + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +

      -    Edit the /etc/shorewall/routestopped file and configure those systems -that you want to be able to access the firewall when it is stopped.

      -
      - -
      +     Edit the /etc/shorewall/routestopped file and configure those systems + that you want to be able to access the firewall when it is stopped.

      +
      + +

      WARNING: If you are connected to your firewall from -the internet, do not issue a "shorewall stop" command unless you have + 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 /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create -an alternate configuration -and test it using the "shorewall + an alternate configuration + and test it using the "shorewall try" command.

      -
      - -

      Last updated 9/19/2002 - + +

      Last updated 12/13/2002 - Tom Eastep

      - +

      Copyright 2002 Thomas -M. Eastep

      -
      + M. Eastep

      +
      +
      +
      diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm new file mode 100644 index 000000000..490cf2c67 --- /dev/null +++ b/STABLE/documentation/sourceforge_index.htm @@ -0,0 +1,454 @@ + + + + + + + + + + Shoreline Firewall (Shorewall) 1.3 + + + + + + + + + + + + + + + + + + + + + + + +
      + + + + + + + +

      Shorwall Logo + + Shorewall 1.3 - + "iptables made easy"

      + + + + + + + + + +
      + + + +
      + +
      + + + + + + + + + + + + + + + + + + + +
      + + + + + + + + +

      What is it?

      + + + + + + + + + +

      The Shoreline Firewall, more commonly known as "Shorewall", is a + Netfilter (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.

      + + + + + + + + + +

      This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the GNU General +Public License as published by the Free Software Foundation.
      + +
      + + 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.
      + +
      + + 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

      + + + + + + + + + +

      Copyright 2001, 2002 Thomas M. Eastep

      + + + + + + + + + + +

      + + Jacques Nilo and Eric Wolzak have + a LEAF (router/firewall/gateway on a floppy, CD or compact + flash) distribution called Bering that + features Shorewall-1.3.10 and Kernel-2.4.18. You + can find their work at: http://leaf.sourceforge.net/devel/jnilo

      + Congratulations to Jacques and Eric on the recent + release of Bering 1.0 Final!!!
      +       + +

      News

      + + + + + + + + + + + + +

      12/20/2002 - Shorewall 1.3.12 Beta 3 (New) +
      +

      + 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.
      + +

      You may download the Beta from:
      +

      +
      http://www.shorewall.net/pub/shorewall/Beta
      + ftp://ftp.shorewall.net/pub/shorewall/Beta
      +
      + +

      12/20/2002 - Shorewall 1.3.12 Beta 2 (New) +

      + The first public Beta version of Shorewall 1.3.12 is now available (Beta +1 was made available only to a limited audience).
      +
      + Features include:
      +
      + +
        +
      1. "shorewall refresh" now reloads the traffic shaping rules +(tcrules and tcstart).
        2. +
      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.
        3. +
      3. "shorewall [re]start" has been speeded up by more than 40% + with my configuration. Your milage may vary.
        4. +
      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"
        5. +
      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 + http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
        6. +
      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_CHAIN=Yes in shorewall.conf. This allows +for marking input packets based on their destination even when you are using +Masquerading or SNAT.
        7. +
      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.
        8. + +
      + You may download the Beta from:
      + +
      http://www.shorewall.net/pub/shorewall/Beta
      + ftp://ftp.shorewall.net/pub/shorewall/Beta
      +
      + +

      12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux +

      + Shorewall is at the center of MandrakeSofts's recently-announced Multi + Network Firewall (MNF) product. Here is the press + release.
      + +

      12/7/2002 - Shorewall Support for Mandrake 9.0 +

      + + +

      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.

      + + +

      12/6/2002 -  Debian 1.3.11a Packages Available
      +

      + + +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      + + +

      12/3/2002 - Shorewall 1.3.11a +

      + + +

      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.

      + + +

      11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format +

      + + +

      Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11 + documenation. the PDF may be downloaded from

      + + +

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      +     http://slovakia.shorewall.net/pub/shorewall/pdf/
      +

      + + +

      11/24/2002 - Shorewall 1.3.11 +

      + + +

      In this version:

      + + +
        +
      • A 'tcpflags' option has been added to entries +in /etc/shorewall/interfaces. + This option causes Shorewall to make a set of sanity check on TCP packet +header flags.
        • +
      • It is now allowed to use 'all' in the SOURCE or + DEST column in a rule. When +used, 'all' must appear by itself (in may not be qualified) and it does + not enable intra-zone traffic. For example, the rule
        +
        +     ACCEPT loc all tcp 80
        +
        + does not enable http traffic from 'loc' to 'loc'.
        • +
      • Shorewall's use of the 'echo' command is now compatible + with bash clones such as ash and dash.
        • +
      • fw->fw policies now generate a startup error. + fw->fw rules generate a warning and are ignored
        • + + +
      + + +

      11/14/2002 - Shorewall Documentation in PDF Format +

      + + +

      Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 + documenation. the PDF may be downloaded from

      + + +

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      +     http://slovakia.shorewall.net/pub/shorewall/pdf/
      +

      + + +

      + +
        + + + + + +
      + + + + + +

      More News

      + + + + + + + + + + +

      + + + +

      SourceForge Logo +

      + + + +

      + + + +

      This site is hosted by the generous folks at SourceForge.net

      + + + +

      Donations

      + +
      +
      + +
      + +
      + + + + + + + + + + + + + + + + + + + +
      + + + + + + + + +

      + +

      + + + + + + + + + +

      Shorewall is free but +if you try it and find it useful, please consider making a donation + to Starlight Children's +Foundation. Thanks!

      + +
      + + + +

      Updated 12/22/2002 - Tom Eastep + +
      +

      + + diff --git a/STABLE/documentation/standalone.htm b/STABLE/documentation/standalone.htm index f514705e2..6aca3a303 100644 --- a/STABLE/documentation/standalone.htm +++ b/STABLE/documentation/standalone.htm @@ -1,427 +1,430 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
      +

      Standalone Firewall

      -
      - +

      Version 2.0.1

      - -

      Setting up Shorewall on a standalone Linux system is very - easy if you understand the basics and follow the documentation.

      - -

      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 -in one of its most common configurations:

      - + +

      Setting up Shorewall on a standalone Linux system is very + easy if you understand the basics and follow the documentation.

      + +

      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 + in one of its most common configurations:

      +
        -
      • Linux system
        • -
      • Single external IP address
        • -
      • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
        • - +
      • Linux system
        • +
      • Single external IP address
        • +
      • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
        • +
      - -

      This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell if - this package is installed by the presence of an ip program on your - firewall system. As root, you can use the 'which' command to check for -this program:

      - + +

      This guide assumes that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell +if this package is installed by the presence of an ip program on +your firewall system. As root, you can use the 'which' command to check +for this program:

      + 
           [root@gateway root]# which ip
           /sbin/ip
           [root@gateway root]#
      - -

      I recommend that you read through the guide first 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 - .

      +

      I recommend that you read through the guide first 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 + .

      +

      -     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.

      - +     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.

      + - +

      Shorewall Concepts

      - -

      The configuration files for Shorewall are contained in the directory -/etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed -Shorewall, download the one-interface sample, -un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall - (they will replace files with the same names that were placed in /etc/shorewall - during Shorewall installation).

      - -

      As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

      - -

      Shorewall views the network where it is running as being composed of a - set of zones. In the one-interface sample configuration, only one - zone is defined:

      - + +

      +    The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you only need to deal with a few of + these as described in this guide. After you have installed +Shorewall, download the one-interface sample, +un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall + during Shorewall installation).

      + +

      As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

      + +

      Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only one + zone is defined:

      + - + + + + + - - - - - - - - - + + + + +
      NameDescription
      NameDescription
      netThe Internet
      netThe Internet
      - +

      Shorewall zones are defined in /etc/shorewall/zones.

      - -

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

      - -

      Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

      - + +

      Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

      + +

      Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

      + - -

      For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file matches - the connection request then the first policy in /etc/shorewall/policy that - matches the request is applied. If that policy is REJECT or DROP  the -request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

      - -

      The /etc/shorewall/policy file included with the one-interface sample has -the following policies:

      - -
      + +

      For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common +(the samples provide that file for you).

      + +

      The /etc/shorewall/policy file included with the one-interface sample +has the following policies:

      + +
      - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
      SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
      SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
      fwnetACCEPT  
      netnetDROPinfo 
      allallREJECTinfo 
      fwnetACCEPT  
      netnetDROPinfo 
      allallREJECTinfo 
      -
      - +
      + 
           fw		net	ACCEPT
           net	all	DROP	info
           all	all	REJECT	info
      - +

      The above policy will:

      - +
        -
      1. allow all connection requests from the firewall to the internet
        2. -
      2. drop (ignore) all connection requests from the internet to your -firewall
        3. -
      3. reject all other connection requests (Shorewall requires this catchall - policy).
        4. - +
      4. allow all connection requests from the firewall to the internet
        5. +
      5. drop (ignore) all connection requests from the internet to your + firewall
        6. +
      6. reject all other connection requests (Shorewall requires this +catchall policy).
        7. +
      - -

      At this point, edit your /etc/shorewall/policy and make any changes that - you wish.

      - + +

      At this point, edit your /etc/shorewall/policy and make any changes that + you wish.

      +

      External Interface

      - -

      The firewall has a single network interface. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter (eth0) that is connected to that "Modem"  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be -a ppp0. If you connect via a regular modem, your External Interface - will also be ppp0. If you connect using ISDN, your external interface - will be ippp0.

      - + +

      The firewall has a single network interface. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter (eth0) that is connected to that "Modem"  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point Tunneling + Protocol (PPTP) in which case the External Interface will be +a ppp0. If you connect via a regular modem, your External Interface + will also be ppp0. If you connect using ISDN, your external interface + will be ippp0.

      +

      -     The Shorewall one-interface sample configuration assumes that the -external interface is eth0. If your configuration is different, you -will have to modify the sample /etc/shorewall/interfaces file accordingly. -While you are there, you may wish to review the list of options that are -specified for the interface. Some hints:

      - +     The Shorewall one-interface sample configuration assumes that the + external interface is eth0. If your configuration is different, +you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that are + specified for the interface. Some hints:

      +
        -
      • -

        If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

        -
        • -
      • -

        If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

        -
        • - +
      • +

        If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

        +
        • +
      • +

        If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option + list.

        +
        • +
      - -
      + +

      IP Addresses

      -
      - -
      -

      RFC 1918 reserves several Private IP address ranges - for use in private networks:

      - -
      +
      + +
      +

      RFC 1918 reserves several Private IP address ranges + for use in private networks:

      + +
           10.0.0.0    - 10.255.255.255
           172.16.0.0  - 172.31.255.255
           192.168.0.0 - 192.168.255.255
      -
      - -

      These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation - to rewrite packet headers when forwarding to/from the internet.

      - +
      + +

      These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs + are assigning these addresses then using Network Address Translation + to rewrite packet headers when forwarding to/from the internet.

      +

      -      Before starting Shorewall, you should look at the IP address of - your external interface and if it is one of the above ranges, you should - remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

      -
      - -
      -

      Enabling other Connections

      +      Before starting Shorewall, you should look at the IP address +of your external interface and if it is one of the above ranges, you +should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

      - -
      -

      If you wish to enable connections from the internet to your - firewall, the general format is:

      -
      - -
      -
      + +
      +

      Enabling other Connections

      +
      + +
      +

      If you wish to enable connections from the internet to your + firewall, the general format is:

      +
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfw<protocol><port>  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfw<protocol><port>  
      -
      +
      +
      + +
      +

      Example - You want to run a Web Server and a POP3 Server +on your firewall system:

      - -
      -

      Example - You want to run a Web Server and a POP3 Server on -your firewall system:

      -
      - -
      -
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80  
      ACCEPTnetfwtcp110  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80  
      ACCEPTnetfwtcp110  
      -
      +
      +
      + +
      +

      If you don't know what port and protocol a particular +application uses, see here.

      - -
      -

      If you don't know what port and protocol a particular application -uses, see here.

      -
      - -
      -

      Important: 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:

      -
      - -
      -
      + +
      +

      Important: 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:

      +
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      -
      -
      - -
      +
      +
      + +
           ACCEPT	net	fw	tcp	22
      -
      - -
      +
      + +

      -     At this point, edit /etc/shorewall/rules to add other connections - as desired.

      -
      - -
      -

      Starting and Stopping Your Firewall

      +     At this point, edit /etc/shorewall/rules to add other connections + as desired.

      - -
      + +
      +

      Starting and Stopping Your Firewall

      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start -Shorewall before configuration is complete. Once you have completed configuration +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start +Shorewall before configuration is complete. Once you have completed configuration of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
      -

      - -

      IMPORTANT: Users of the .deb - package must edit /etc/default/shorewall and set 'startup=1'.
      -

      -
      +

      -
      -

      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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

      -
      - -
      -

      WARNING: 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 /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall -try" command.

      -
      - -

      Last updated 11/21/2002 - IMPORTANT: Users of the .deb + package must edit /etc/default/shorewall and set 'startup=1'.
      +

      +
      + +
      +

      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 /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +
      +

      WARNING: 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 /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall + try" command.

      +
      + +

      Last updated 12/9/2002 - Tom Eastep

      - -

      Copyright 2002 Thomas - M. Eastep

      -
      + +

      Copyright 2002 Thomas + M. Eastep

      +
      +



      diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 9eb6dc0c2..13e6171fc 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,85 +1,122 @@ - + + - + + - + + - + + Support - + + + - + - - - - - - + + + + + + +
      - -

      Shorewall Support

      -
      + + +

      Shorewall Support +

      +
      - -

      "It -is easier to post a problem than to use your own brain" -- Wietse Venema (creator of Postfix)

      - -

      "Any sane computer will tell you how it works -- you -just have to ask it the right questions" -- Tom Eastep

      - -
      - -

      "It irks me when people believe that - free software comes at no cost. The cost is incredibly high." - - Wietse Venem
      -

      - -

      Before Reporting a Problem

      - "Reading the documentation fully is a prerequisite to getting help - for your particular situation. I know it's harsh but you will have to get - so far on your own before you can get reasonable help from a list full of - busy people. A mailing list is not a tool to speed up your day by being -spoon fed". -- Simon White
      - -

      There are also a number of sources for problem solution information.

      - + +


      +

      + +

      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.

      + +

      -Tom

      + +

      Before Reporting a Problem

      + +

      There are a number of sources for problem solution information. Please + try these before you post.

      + +

      + +

      +
        -
      • The FAQ has solutions to common problems.
        • -
      • The Troubleshooting Information - contains a number of tips to help you solve common problems.
        • -
      • The Errata has links to download - updated components.
        • -
      • The Mailing List Archives search facility can locate posts -about similar problems:
        • - +
      • +

        The FAQ has solutions to more than 20 common + problems.

        +
        • +
      + +

      + +
        +
      • +

        The Troubleshooting Information + contains a number of tips to help you solve common problems.

        +
        • + +
      + +

      + +
        +
      • +

        The Errata has links to download + updated components.

        +
        • + +
      + +

      + +
        +
      • +

        The Mailing List Archives search facility can locate posts + about similar problems:

        +
        • + +
      + +

      + +

      Mailing List Archive Search

      + +
      + +

      Match: -

      Mailing List Archive Search

      - - - -

      Match: - Format: + Format: + - Sort by: + Sort by: + -
      - Search:

      - - -

      Problem Reporting Guideline

      - -
        -
      • 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.
        • -
      • 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.
        • -
      • Do you see any "Shorewall" messages in /var/log/messages - when you exercise the function that is giving you problems?
        • -
      • Have you looked at the packet flow with a tool like tcpdump - to try to understand what is going on?
        • -
      • 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.
        • -
      • Please include any of the Shorewall configuration files (especially - the /etc/shorewall/hosts file if you have modified that file) that -you think are relevant. If an error occurs when you try to "shorewall -start", include a trace (See the Troubleshooting - section for instructions).
        • -
      • 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.
        • - -
      - -

      Where to Send your Problem Report or to Ask for Help

      - If you run Shorewall on Mandrake 9.0 -- send your problem - reports and questions to MandrakeSoft. I ordered a Mandrake 9.0 boxed set - on October 3, 2002; MandrakeSoft issued a charge against my credit card on - October 4, 2002 (they are very effecient at that part of the order process) - and I haven't heard a word from them since (although their news letters -boast that 9.0 boxed sets have been shipping for the last two weeks). If -they can't fill my 9.0 order within 6 weeks after they have billed my -credit card then I refuse to spend my free time supporting their product -for them.
      -
      -Mandrake Update - 11/26/2002 - Mandrake have informed me that "Your -order is part of a batch of which was not correctly sent to our shipping -handler, and so unfortunately was not processed". They further assure me -that these mishandled orders will begin shipping on 12/2/2002.
      + Search:

      + + +

      Problem Reporting Guidelines

      + "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?
      +
      + 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."
      +
      + +
         - Russell Mosemann
      +
      +
      + +

      -

      If you run Shorewall under Bering -- please - post your question or problem to the LEAF Users mailing list.

      +
        +
      • +

        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.

        +
        • + +
      + +

      + +
        +
      • +

        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.

        +
        • + +
      + +

      + +
        +
      • +

        Do you see any "Shorewall" messages in /var/log/messages + when you exercise the function that is giving you problems?

        +
        • + +
      + +

      + +
        +
      • +

        Have you looked at the packet flow with a tool like tcpdump + to try to understand what is going on?

        +
        • + +
      + +

      + +
        +
      • +

        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.

        +
        • + +
      + +

      + +
        +
      • +

        Please include any of the Shorewall configuration files (especially + the /etc/shorewall/hosts file if you have modified that file) +that you think are relevant.

        +
        • +
      • +

        If an error occurs when you try to "shorewall start", include +a trace (See the Troubleshooting section +for instructions).

        +
        • + +
      + +

      + +
        +
      • +

        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.

        +
        • + +
      + +

      + +

      Please post in plain text

      +
      +

      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"!!

      +

      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.

      +

      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.

      +

      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.

      +
      +

      Where to Send your Problem Report or to Ask for Help

      -

      Otherwise, please post your question or problem to the Shorewall users mailing list; - there are lots of folks there who are willing to help you. Your question/problem - description and their responses will be placed in the mailing list archives - to help people who have a similar question or problem in the future.

      - -

      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 mailing list.

      - -

      -Tom

      - +

      + +
      +

      If you run Shorewall under Bering -- please post your question or problem + to the LEAF Users mailing + list.

      + +

      Otherwise, please post your question or problem to the Shorewall users mailing list.

      +
      + + + +

      + +

      To Subscribe to the mailing list go to http://www.shorewall.net/mailman/listinfo/shorewall-users - .

      - -

      Last Updated 12/2/2002 - Tom Eastep

      - + href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users + .

      + + +

      Last Updated 12/27/2002 - Tom Eastep

      +

      Copyright © 2001, 2002 Thomas M. Eastep.
      -

      +

      +
      +

      +
      +
      diff --git a/STABLE/documentation/three-interface.htm b/STABLE/documentation/three-interface.htm index 32c0b1c29..2809537a6 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,1113 +1,1138 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
      - +
      +

      Three-Interface Firewall

      -
      - +

      Version 2.0.1

      - -

      Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the basics - and follow the documentation.

      - -

      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 - in one of its more popular configurations:

      - + +

      Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the basics + and follow the documentation.

      + +

      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 + in one of its more popular configurations:

      +
        -
      • Linux system used as a firewall/router for a small local network.
        • -
      • Single public IP address.
        • -
      • DMZ connected to a separate ethernet interface.
        • -
      • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, - ...
        • - +
      • Linux system used as a firewall/router for a small local +network.
        • +
      • Single public IP address.
        • +
      • DMZ connected to a separate ethernet interface.
        • +
      • Connection through DSL, Cable Modem, ISDN, Frame Relay, +dial-up, ...
        • +
      - +

      Here is a schematic of a typical installation.

      - +

      -

      - -

      This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program on - your firewall system. As root, you can use the 'which' command to check - for this program:

      - +

      + +

      This guide assumes that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program +on your firewall system. As root, you can use the 'which' command to +check for this program:

      + 
           [root@gateway root]# which ip
           /sbin/ip
           [root@gateway root]#
      - -

      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 -

      - + +

      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 +

      +

      -     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.

      - +     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.

      + - +

      Shorewall Concepts

      - -

      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 installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the - files to /etc/shorewall (the files will replace files with the same names - that were placed in /etc/shorewall when Shorewall was installed).

      - -

      As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

      - -

      Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, the -following zone names are used:

      - + +

      +     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 installed Shorewall, download the three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy +the files to /etc/shorewall (the files will replace files with the same +names that were placed in /etc/shorewall when Shorewall was installed).

      + +

      As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

      + +

      Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, the + following zone names are used:

      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      NameDescription
      netThe Internet
      locYour Local Network
      dmzDemilitarized Zone
      NameDescription
      netThe Internet
      locYour Local Network
      dmzDemilitarized Zone
      - +

      Zone names are defined in /etc/shorewall/zones.

      - -

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

      - -

      Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

      - + +

      Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

      + +

      Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

      + - -

      For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  - the request is first checked against the rules in /etc/shorewall/common -(the samples provide that file for you).

      - -

      The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

      - -
      + +

      For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

      + +

      The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      -
      - -
      -

      In the three-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.

      - +
      + +
      +

      In the three-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.

      + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      fwnetACCEPT  
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      fwnetACCEPT  
      -
      - +
      +

      The above policy will:

      - +
        -
      1. allow all connection requests from your local network to the - internet
        2. -
      2. drop (ignore) all connection requests from the internet to -your firewall or local network
        3. -
      3. optionally accept all connection requests from the firewall -to the internet (if you uncomment the additional policy)
        4. -
      4. reject all other connection requests.
        5. - +
      5. allow all connection requests from your local network to +the internet
        6. +
      6. drop (ignore) all connection requests from the internet +to your firewall or local network
        7. +
      7. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
        8. +
      8. reject all other connection requests.
        9. +
      - +

      -     At this point, edit your /etc/shorewall/policy file and make -any changes that you wish.

      - +     At this point, edit your /etc/shorewall/policy file and make + any changes that you wish.

      +

      Network Interfaces

      - +

      -

      - -

      The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., -eth0)  unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the External Interface -will be a ppp interface (e.g., ppp0). If you connect via a regular -modem, your External Interface will also be ppp0. If you connect -using ISDN, you external interface will be ippp0.

      - +

      + +

      The firewall has three network interfaces. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter that is connected to that "Modem" (e.g., + eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect via + a regular modem, your External Interface will also be ppp0. If you + connect using ISDN, you external interface will be ippp0.

      +

      -     If your external interface is ppp0 or ippp0 then - you will want to set CLAMPMSS=yes in ppp0 or ippp0 then + you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

      - -

      Your Local Interface 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 cross-over cable).

      - -

      Your DMZ Interface 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 cross-over cable).

      - + +

      Your Local Interface 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 cross-over cable).

      + +

      Your DMZ Interface 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 cross-over cable).

      +

      - Do not connect more than one interface to the same hub or -switch (even for testing). It won't work the way that you expect it to -and you will end up confused and believing that Shorewall doesn't work -at all.

      - + Do not connect more than one interface to the same hub +or switch (even for testing). It won't work the way that you expect it +to and you will end up confused and believing that Shorewall doesn't + work at all.

      +

      -     The Shorewall three-interface sample configuration assumes that - the external interface is eth0, the local interface is eth1 -and the DMZ interface is eth2. If your configuration is different, - you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interfaces. Some hints:

      - +     The Shorewall three-interface sample configuration assumes +that the external interface is eth0, the local interface is eth1 + and the DMZ interface is eth2. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that +are specified for the interfaces. Some hints:

      +
        -
      • -

        If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

        -
        • -
      • -

        If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

        -
        • - +
      • +

        If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

        +
        • +
      • +

        If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the + option list.

        +
        • +
      - +

      IP Addresses

      - -

      Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic - Host Configuration Protocol (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 static IP address; that - means that you configure your firewall's external interface to use that - address permanently. Regardless of how the 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 for your internal network (the -local and DMZ Interfaces on your firewall plus your other computers). RFC -1918 reserves several Private IP address ranges for this purpose:

      - -
      + +

      Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you +a single Public IP address. This address may be assigned via +the Dynamic Host Configuration Protocol (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 static +IP address; that means that you configure your firewall's external interface +to use that address permanently. Regardless of how the 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 for your internal +network (the local and DMZ Interfaces on your firewall plus your other +computers). RFC 1918 reserves several Private IP address ranges for +this purpose:

      + +
           10.0.0.0    - 10.255.255.255
           172.16.0.0  - 172.31.255.255
           192.168.0.0 - 192.168.255.255
      -
      - -
      +
      + +

      -     Before starting Shorewall, you should look at the IP address - of your external interface and if it is one of the above ranges, you - should remove the 'norfc1918' option from the external interface's +     Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you + should remove the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

      -
      - -
      -

      You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another - subnet. For our purposes, we can consider a subnet to consists of a -range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet - Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet - Address and x.y.z.255 is reserved as the Subnet Broadcast -Address. In Shorewall, a subnet is described using Classless InterDomain Routing (CIDR) -notation with consists of the subnet address followed by "/24". The "24" -refers to the number of consecutive "1" bits from the left of the subnet -mask.

      -
      - -
      +
      + +
      +

      You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another + subnet. For our purposes, we can consider a subnet to consists of a +range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet + Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet + Address and x.y.z.255 is reserved as the Subnet Broadcast + Address. In Shorewall, a subnet is described using Classless InterDomain Routing +(CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from +the left of the subnet mask.

      +
      + +

      Example sub-network:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      CIDR Notation:10.10.10.0/24
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      CIDR Notation:10.10.10.0/24
      -
      -
      - -
      -

      It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

      -
      - -
      -

      One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

      -
      - -
      + +
      + +
      +

      It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

      +
      + +
      +

      One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

      +
      + +

      -     Your local computers (Local Computers 1 & 2) should be -configured with their default gateway set to the IP address of -the firewall's internal interface and your DMZ computers ( DMZ Computers -1 & 2) should be configured with their default gateway set to the -IP address of the firewall's DMZ interface.  

      -
      - -

      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 "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      - -

      The remainder of this quide will assume that you have configured - your network as shown here:

      - +     Your local computers (Local Computers 1 & 2) should +be configured with their default gateway set to the IP address + of the firewall's internal interface and your DMZ computers ( DMZ +Computers 1 & 2) should be configured with their default gateway +set to the IP address of the firewall's DMZ interface.  

      +
      + +

      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 "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      + +

      The remainder of this quide will assume that you have configured + your network as shown here:

      +

      -

      - -

      The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.

      - +

      + +

      The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.

      +

      IP Masquerading (SNAT)

      - -

      The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't forward - packets which have an RFC-1918 destination address. When one of your -local systems (let's assume local computer 1) sends a connection request -to an internet host, the firewall must perform Network Address Translation - (NAT). The firewall rewrites the source address in the packet to be - the address of the firewall's external interface; in other words, the firewall - makes it look as if the firewall itself is initiating the connection.  -This is necessary so that the destination host will be able to route return -packets back to the firewall (remember that packets whose destination -address is reserved by RFC 1918 can't be routed accross the internet). -When the firewall receives a return packet, it rewrites the destination -address back to 10.10.10.1 and forwards the packet on to local computer -1.

      - -

      On Linux systems, the above process is often referred to as - IP Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

      - + +

      The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When one +of your local systems (let's assume local computer 1) sends a connection + request to an internet host, the firewall must perform Network Address + Translation (NAT). The firewall rewrites the source address in the + packet to be the address of the firewall's external interface; in other + words, the firewall makes it look as if the firewall itself is initiating + the connection.  This is necessary so that the destination host will be + able to route return packets back to the firewall (remember that packets + whose destination address is reserved by RFC 1918 can't be routed accross + the internet). When the firewall receives a return packet, it rewrites + the destination address back to 10.10.10.1 and forwards the packet on +to local computer 1.

      + +

      On Linux systems, the above process is often referred to +as IP Masquerading and you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

      +
        -
      • -

        Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

        -
        • -
      • -

        SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local network - to use.

        -
        • - +
      • +

        Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

        +
        • +
      • +

        SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local +network to use.

        +
        • +
      - -

      In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

      - + +

      In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

      +

      -     If your external firewall interface is eth0, your local - interface eth1 and your DMZ interface is eth2 then you do - not need to modify the file provided with the sample. Otherwise, edit - /etc/shorewall/masq and change it to match your configuration.

      - +     If your external firewall interface is eth0, your local + interface eth1 and your DMZ interface is eth2 then you +do not need to modify the file provided with the sample. Otherwise, edit + /etc/shorewall/masq and change it to match your configuration.

      +

      -     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. -

      - -

      Port Forwarding (DNAT)

      - -

      One of your goals will be to run one or more servers on your - DMZ 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 your firewall who rewrites the destination address to the address of -your server and forwards the packet to that server. When your server responds, - the firewall automatically performs SNAT to rewrite the source address -in the response.

      - -

      The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure port - forwarding using DNAT rules in the /etc/shorewall/rules file.

      - -

      The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>  
      -
      - -

      If you don't specify the <server port>, it is assumed to be -the same as <port>.

      - -

      Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
      ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
      -
      - -

      A couple of important points to keep in mind:

      - -
        -
      • When you are connecting to your server from your local systems, - you must use the server's internal IP address (10.10.11.2).
        • -
      • Many ISPs block incoming connection requests to port 80. If -you have problems connecting to your web server, try the following rule -and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
        • - -
      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp5000  
      -
      - -

      If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can replace - the loc->dmz rule above with:

      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-<external IP>
      -
      - -

      If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows (assume - that your external interface is eth0):

      - -
        -
      1. Include the following in /etc/shorewall/params:
        -
        - ETH0_IP=`find_interface_address eth0`
        -  
        2. -
      2. Make your loc->dmz rule:
        3. - -
      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATloc
      -       		dmz:10.10.11.2:80tcp80-$ETH0_IP
      -
      - -

      If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

      - -

      -     At this point, add the DNAT and ACCEPT rules for your servers. +     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.

      - -

      Domain Name Server (DNS)

      - -

      Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your - primary and secondary name servers. It is your responsibility to - configure the resolver in your internal systems. You can take one of two - approaches:

      - + +

      +     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:
      +

      +
        -
      • -

        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.

        -
        • -
      • +
      • NAT_ENABLED=Yes
        • +
      • IP_FORWARDING=On
        +
        • + +
      + +

      Port Forwarding (DNAT)

      + +

      One of your goals will be to run one or more servers on your + DMZ 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 your firewall who rewrites the destination address to the +address of your server and forwards the packet to that server. When your +server responds, the firewall automatically performs SNAT to rewrite +the source address in the response.

      + +

      The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

      + +

      The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>  
      +
      + +

      If you don't specify the <server port>, it is assumed to +be the same as <port>.

      + +

      Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
      ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
      +
      + +

      A couple of important points to keep in mind:

      + +
        +
      • When you are connecting to your server from your local systems, + you must use the server's internal IP address (10.10.11.2).
        • +
      • Many ISPs block incoming connection requests to port 80. +If you have problems connecting to your web server, try the following + rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
        • + +
      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp5000  
      +
      + +

      If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you can + replace the loc->dmz rule above with:

      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-<external IP>
      +
      + +

      If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows +(assume that your external interface is eth0):

      + +
        +
      1. Include the following in /etc/shorewall/params:
        +
        + ETH0_IP=`find_interface_address eth0`
        +  
        2. +
      2. Make your loc->dmz rule:
        3. + +
      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATloc
      +       		dmz:10.10.11.2:80tcp80-$ETH0_IP
      +
      + +

      If you want to access your server from the DMZ using your external IP + address, see FAQ 2a.

      + +

      +     At this point, add the DNAT and ACCEPT rules for your servers. +

      + +

      Domain Name Server (DNS)

      + +

      Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as +your primary and secondary name servers. It is your responsibility +to configure the resolver in your internal systems. You can take one +of two approaches:

      + +
        +
      • +

        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. +

        +
        • +

      • -     You can configure a Caching Name Server on your firewall - or in your DMZ. Red Hat has an RPM for a caching name server (which - also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. - If you take this approach, you configure your internal systems to use - the caching name server as their primary (and only) name server. You use - the internal IP address of the firewall (10.10.10.254 in the example above) - for the name server address if you choose to run the name server on -your firewall. To allow your local systems to talk to your caching name - server, you must open port 53 (both UDP and TCP) from the local network -to the server; you do that by adding the rules in /etc/shorewall/rules. -

        -
        • - +     You can configure a Caching Name Server on your firewall + or in your DMZ. Red Hat has an RPM for a caching name server +(which also requires the 'bind' RPM) and for Bering users, there +is dnscache.lrp. If you take this approach, you configure your internal +systems to use the caching name server as their primary (and only) +name server. You use the internal IP address of the firewall (10.10.10.254 +in the example above) for the name server address if you choose to +run the name server on your firewall. To allow your local systems to talk +to your caching name server, you must open port 53 (both UDP and TCP) +from the local network to the server; you do that by adding the rules +in /etc/shorewall/rules.

        + +
      - -
      -

      If you run the name server on the firewall: - + +

      +

      If you run the name server on the firewall: + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      ACCEPTdmzfwtcp53  
      ACCEPTdmzfwudp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      ACCEPTdmzfwtcp53  
      ACCEPTdmzfwudp53  
      -

      -
      - -
      -
      +

      +
      + +
      +

      Run name server on DMZ computer 1

      - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocdmz:10.10.11.1tcp53  
      ACCEPTlocdmz:10.10.11.1udp53  
      ACCEPTfwdmz:10.10.10.1tcp53  
      ACCEPTfwdmz:10.10.10.1udp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocdmz:10.10.11.1tcp53  
      ACCEPTlocdmz:10.10.11.1udp53  
      ACCEPTfwdmz:10.10.10.1tcp53  
      ACCEPTfwdmz:10.10.10.1udp53  
      -
      -
      - -
      +
      +
      + +

      Other Connections

      -
      - -
      +
      + +

      The three-interface sample includes the following rules:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTfwnetudp53  
      ACCEPTfwnettcp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTfwnetudp53  
      ACCEPTfwnettcp53  
      -
      -
      - -
      -

      Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

      -
      - -
      + +
      + +
      +

      Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

      +
      + +

      The sample also includes:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp22  
      ACCEPTlocdmztcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp22  
      ACCEPTlocdmztcp22  
      -
      -
      - -
      -

      That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers from - your local systems.

      -
      - -
      -

      If you wish to enable other connections between your systems, - the general format is:

      -
      - -
      -
      +
      +
      + +
      +

      That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers + from your local systems.

      +
      + +
      +

      If you wish to enable other connections between your systems, + the general format is:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPT<source zone><destination zone><protocol><port>  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPT<source zone><destination zone><protocol><port>  
      -
      -
      - -
      -

      Example - You want to run a publicly-available DNS server - on your firewall system:

      -
      - -
      -
      +
      +
      + +
      +

      Example - You want to run a publicly-available DNS server + on your firewall system:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
      ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
      ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
      -
      -
      - -
      -

      Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

      -
      - -
      -

      If you don't know what port and protocol a particular application -uses, look here.

      -
      - -
      -

      Important: 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:

      -
      - -
      -
      +
      +
      + +
      +

      Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

      +
      + +
      +

      If you don't know what port and protocol a particular +application uses, look here.

      +
      + +
      +

      Important: 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:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      -
      -
      - -
      + +
      + +

      -     Now modify /etc/shorewall/rules to add or remove other connections - as required.

      -
      - -
      +     Now modify /etc/shorewall/rules to add or remove other connections + as required.

      +
      + +

      Starting and Stopping Your Firewall

      -
      - -
      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
      -

      - +

      +

      IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
      -

      -
      - -
      -

      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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

      -
      - -
      + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall + and set 'startup=1'.
      +

      +
      + +
      +

      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 /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +

      -     The three-interface sample assumes that you want to enable -routing to/from eth1 (your local network) and eth2 (DMZ) -when Shorewall is stopped. If these two interfaces don't connect to -your local network and DMZ or if you want to enable a different set -of hosts, modify /etc/shorewall/routestopped accordingly.

      -
      - -
      -

      WARNING: 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 /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect to + your local network and DMZ or if you want to enable a different set + of hosts, modify /etc/shorewall/routestopped accordingly.

      +
      + + - -

      Last updated 11/21/2002 - + +

      Last updated 12/20/2002 - Tom Eastep

      - -

      Copyright 2002 Thomas - M. Eastep

      + +

      Copyright 2002 Thomas + M. Eastep

      +
      +

      +



      diff --git a/STABLE/documentation/traffic_shaping.htm b/STABLE/documentation/traffic_shaping.htm index ddff1c3b7..7b9d95f9b 100644 --- a/STABLE/documentation/traffic_shaping.htm +++ b/STABLE/documentation/traffic_shaping.htm @@ -1,257 +1,293 @@ - + - + - + - + Traffic Shaping - + - - - + + - - - + + + +
      +
      +

      Traffic Shaping/Control

      -
      - +

      Beginning with version 1.2.0, Shorewall has limited support -for traffic shaping/control. In order to use traffic shaping under Shorewall, -it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO, -version 0.3.0 or later. You must also install the iproute (iproute2) package -to provide the "ip" and "tc" utilities.

      - + version 0.3.0 or later. You must also install the iproute (iproute2) package + to provide the "ip" and "tc" utilities.

      +

      Shorewall traffic shaping support consists of the following:

      - +
        -
      • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping -also requires that you enable packet mangling.
        -
        • -
      • /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.
        -
        • -
      • /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 new TC_ENABLED parameter in /etc/shorewall.conf. Traffic + Shaping also requires that you enable packet mangling.
        +
        • +
      • /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.
        +
        • +
      • /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 sample 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 HTB (see below). HTB - support may eventually become an integral part of Shorewall since HTB -is a lot simpler and better-documented than CBQ. HTB is currently not -a standard part of either the kernel or iproute2 so both must be patched -in order to use it.
        + 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.
        +
        + 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.

        - In tcstart, when you want to run the 'tc' utility, use the run_tc function - supplied by shorewall.
        + You can generally use off-the-shelf traffic shaping scripts by simply copying + them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB version) +that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and +modified it according to the Wonder Shaper README). WARNING: 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.
        • -
      • /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.
        • - +
      • /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.
        • +
      - +

      Kernel Configuration

      - +

      This screen shot show how I've configured QoS in my Kernel:

      - +

      -

      - +

      +

      /etc/shorewall/tcrules

      - +

      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.

      - + packets for traffic shaping. The /etc/shorewall/tcrules file provides +a means for specifying these marks in a tabular fashion.
      +

      +

      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 +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 +shorewall.conf.
      +

      +

      Columns in the file are as follows:

      - +
        -
      • MARK - Specifies the mark value is to be assigned in case of -a match. This is an integer in the range 1-255.
        -
        - Example - 5
        -
        • -
      • 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 Shorewall Format and/or Subnets.
        -
        - Examples
        -     eth0
        -     192.168.2.4,192.168.1.0/24
        -
        • -
      • DEST -- Destination of the packet. Comma-separated list of IP -addresses and/or subnets.
        -
        • -
      • PROTO - Protocol - Must be the name of a protocol from /etc/protocol, -a number or "all"
        -
        • -
      • 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).
        -
        • -
      • CLIENT PORT(S) - (Optional) Port(s) used by the client. If omitted, -any source port is acceptable. Specified as a comma-separate list of port -names, port numbers or port ranges.
        • - +
      • MARK - Specifies the mark value is to be assigned in case of + a match. This is an integer in the range 1-255.
        +
        + Example - 5
        +
        • +
      • 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 + Shorewall Format and/or Subnets.
        +
        + Examples
        +     eth0
        +     192.168.2.4,192.168.1.0/24
        +
        • +
      • DEST -- Destination of the packet. Comma-separated list of + IP addresses and/or subnets.
        +
        • +
      • PROTO - Protocol - Must be the name of a protocol from +/etc/protocol, a number or "all"
        +
        • +
      • 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).
        +
        • +
      • CLIENT PORT(S) - (Optional) Port(s) used by the client. If + omitted, any source port is acceptable. Specified as a comma-separate + list of port names, port numbers or port ranges.
        • +
      - +

      Example 1 - All packets arriving on eth1 should be marked -with 1. All packets arriving on eth2 should be marked with 2. All packets -originating on the firewall itself should be marked with 3.

      - + 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.

      + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      1eth10.0.0.0/0all  
      2eth20.0.0.0/0all  
      3fw0.0.0.0/0all  
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      1eth10.0.0.0/0all  
      2eth20.0.0.0/0all  
      2
      +       		eth3
      +       		0.0.0.0/0
      +       		all
      +
      +
      +
      3fw0.0.0.0/0all  
      - +

      Example 2 - All GRE (protocol 47) packets not originating -on the firewall and destined for 155.186.235.151 should be marked with 12.

      - + on the firewall and destined for 155.186.235.151 should be marked with +12.

      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      120.0.0.0/0155.186.235.15147  
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      120.0.0.0/0155.186.235.15147  
      - +

      Example 3 - All SSH packets originating in 192.168.1.0/24 -and destined for 155.186.235.151 should be marked with 22.

      - + and destined for 155.186.235.151 should be marked with 22.

      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      22192.168.1.0/24155.186.235.151tcp22 
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      22192.168.1.0/24155.186.235.151tcp22 
      - -

      Hierarchical Token Bucket

      - -

      I personally use HTB. I have found a couple of things that may be of use -to others.

      - -
        -
      • The gzipped tc binary at the HTB website didn't work -for me -- I had to download the lastest version of the iproute2 sources and patch -them for HTB.
        • -
      • I'm currently running with this set of shaping rules in my tcstart -file. I recently changed from using a ceiling of 10Mbit (interface speed) -to 384kbit (DSP Uplink speed).
        -
        -
        • - -
      + +

      My Setup
      +

      + +

      While I am currently using the HTB version of The Wonder Shaper (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:
      +

      - 
      run_tc qdisc add dev eth0 root handle 1: htb default 30
      run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

      echo "   Added Top Level Class -- rate 384kbit"
      - - 
      run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k
      run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k
      run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500
      - + 
      run_tc qdisc add dev eth0 root handle 1: htb default 30

      run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

      echo "   Added Top Level Class -- rate 384kbit"
      + + 
      run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
      run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
      run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
      + 
      echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
      - - 
      run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
      run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
      run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10
      - - 
      echo "   Enabled SFQ on Second Level Classes"
      - - 
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
      - + + 
      run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
      run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
      run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
      + + 
      echo "   Enabled PFIFO on Second Level Classes"
      + + 
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
      + 
      echo "   Defined fwmark filters"
      - -

      My tcrules file is shown in Example 1 above. You can look at my network configuration to get an idea of why I want -these particular rules.
      -

      -
      - -

      Last Updated 10/25/2002 - Tom Eastep

      - + + +

      My tcrules file that went with this tcstart file is shown in Example 1 + above. You can look at my network configuration + to get an idea of why I wanted these particular rules.
      +

      + +
        +
      1. I wanted to allow up to 140kbits/second for traffic outbound from + my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic +can use all available bandwidth if there is no traffic from the local systems + or from my laptop or firewall).
        2. +
      2. My laptop and local systems could use up to 224kbits/second.
        3. +
      3. My firewall could use up to 20kbits/second.
        +
        4. + +
      + +

      Last Updated 12/20/2002 - Tom Eastep

      +

      Copyright - © 2001, 2002 Thomas M. Eastep.

      -
      -
      + © 2001, 2002 Thomas M. Eastep.
      +

      diff --git a/STABLE/documentation/troubleshoot.htm b/STABLE/documentation/troubleshoot.htm index 431461699..7fc06d028 100644 --- a/STABLE/documentation/troubleshoot.htm +++ b/STABLE/documentation/troubleshoot.htm @@ -1,211 +1,233 @@ - + Shorewall Troubleshooting - + - + - + - - - + + - - - + + + + +
      +
      +

      Shorewall TroubleshootingBeating head on table -

      -
      - +

      Check the Errata

      - +

      Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version -of the firewall.

      - + sure that there isn't an update that you are missing for your version + of the firewall.

      +

      Check the FAQs

      - +

      Check the FAQs for solutions to common - problems.

      - + problems.

      +

      If the firewall fails to start

      - 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: +
        -
      • shorewall debug start 2> /tmp/trace
        • -
      • Look at the /tmp/trace file and see if that helps you determine - what the problem is.
        • -
      • If you still can't determine what's wrong then see the support page.
        • - +
      • Make a note of the error message that you see.
        +
        • +
      • shorewall debug start 2> /tmp/trace
        • +
      • 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.
        • +
      • If you still can't determine what's wrong then see the + support page.
        • +
      - +Here's an example. During startup, a user sees the following:
      +
      + 
      Adding Common Rules
      iptables: No chain/target/match by that name
      Terminated
      +
      +A search through the trace for "No chain/target/match by that name" turned +up the following:  +
      + 
      + echo 'Adding Common Rules'
      + add_common_rules
      + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
      ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
      ++ sed 's/!/! /g'
      + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
      iptables: No chain/target/match by that name
      +
      +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 kernel.htm) +

      Your network environment

      - +

      Many times when people have problems with Shorewall, the problem is actually an ill-conceived network setup. Here are several popular snafus: -

      - +

      +
        -
      • Port Forwarding where client and server are in the -same subnet. See FAQ 2.
        • -
      • 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.
        • -
      • 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.
        • - +
      • Port Forwarding where client and server are in the + same subnet. See FAQ 2.
        • +
      • 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.
        • +
      • 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.
        • +
      - +

      If you are having connection problems:

      - +

      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.

      - + 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.

      +

      I also recommend against setting all of your policies to ACCEPT in an effort to make something work. That robs you of one of - your best diagnostic tools - the "Shorewall" messages that Netfilter - will generate when you try to connect in a way that isn't permitted - by your rule set.

      - + your best diagnostic tools - the "Shorewall" messages that Netfilter + will generate when you try to connect in a way that isn't permitted + by your rule set.

      +

      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 FAQ 17.

      - + 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 FAQ 17.

      +

      While you are troubleshooting, it is a good idea to clear - two variables in /etc/shorewall/shorewall.conf:

      - + two variables in /etc/shorewall/shorewall.conf:

      +

      LOGRATE=""
      - LOGBURST=""

      - + LOGBURST=""

      +

      This way, you will see all of the log messages being generated (be sure to restart shorewall after clearing these variables).

      - +

      Example:

      - + +

      Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 - LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 + LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47

      -       +

      Let's look at the important parts of this message:

      - +
        -
      • all2all:REJECT - This packet was REJECTed out of the all2all -chain -- the packet was rejected under the "all"->"all" REJECT policy -(see FAQ 17).
        • -
      • IN=eth2 - the packet entered the firewall via eth2
        • -
      • OUT=eth1 - if accepted, the packet would be sent on eth1
        • -
      • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
        • -
      • DST=192.168.1.3 - the packet is destined for 192.168.1.3
        • -
      • PROTO=UDP - UDP Protocol
        • -
      • DPT=53 - DNS
        • - +
      • all2all:REJECT - This packet was REJECTed out of the all2all + chain -- the packet was rejected under the "all"->"all" REJECT policy + (see FAQ 17).
        • +
      • IN=eth2 - the packet entered the firewall via eth2
        • +
      • OUT=eth1 - if accepted, the packet would be sent on eth1
        • +
      • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
        • +
      • DST=192.168.1.3 - the packet is destined for 192.168.1.3
        • +
      • PROTO=UDP - UDP Protocol
        • +
      • DPT=53 - DNS
        • +
      - +

      In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 - is in the "loc" zone. I was missing the rule:

      - + is in the "loc" zone. I was missing the rule:

      +

      ACCEPT    dmz    loc    udp    53
      -

      - +

      +

      See FAQ 17 for additional information - about how to interpret the chain name appearing in a Shorewall log message.
      -

      - + about how to interpret the chain name appearing in a Shorewall log message.
      +

      +

      Other Gotchas

      - + - +

      Still Having Problems?

      - +

      See the support page.

      - + +
      -       -

      Last updated 11/24/2002 - Tom Eastep

      - +       +

      Last updated 12/4/2002 - Tom Eastep

      +

      Copyright - © 2001, 2002 Thomas M. Eastep.
      -

      + © 2001, 2002 Thomas M. Eastep.
      +

      +
      +


      diff --git a/STABLE/documentation/two-interface.htm b/STABLE/documentation/two-interface.htm index 9c4b2365b..03faf63fb 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,919 +1,952 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
      +
      +

      Basic Two-Interface Firewall

      -
      - +

      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.

      - + is a fairly straight-forward task if you understand the basics and follow + the documentation.

      +

      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 - in its most common configuration:

      - + Shorewall. It rather focuses on what is required to configure Shorewall + in its most common configuration:

      +
        -
      • Linux system used as a firewall/router for a small local network.
        • -
      • Single public IP address.
        • -
      • Internet connection through cable modem, DSL, ISDN, Frame Relay, - dial-up ...
        • - +
      • Linux system used as a firewall/router for a small local +network.
        • +
      • Single public IP address.
        • +
      • Internet connection through cable modem, DSL, ISDN, Frame +Relay, dial-up ...
        • +
      - +

      Here is a schematic of a typical installation.

      - +

      -

      - +

      + +

      If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing". You should not need to refer to this guide.
      +

      +

      This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell -if this package is installed by the presence of an ip program on -your firewall system. As root, you can use the 'which' command to check -for this program:

      - + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program on + your firewall system. As root, you can use the 'which' command to check + for this program:

      + 
           [root@gateway root]# which ip
           /sbin/ip
           [root@gateway root]#
      - +

      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 - .

      - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with + .

      +

      -     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.

      - +     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.

      + - +

      Shorewall Concepts

      - -

      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 installed Shorewall, download the +     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 installed Shorewall, download the two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall - (these files will replace files with the same name).

      - + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall + (these files will replace files with the same name).

      +

      As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

      - + file on your system -- each file contains detailed configuration instructions + and default entries.

      +

      Shorewall views the network where it is running as being composed of a - set of zones. In the two-interface sample configuration, the following - zone names are used:

      - + set of zones. In the two-interface sample configuration, the following + zone names are used:

      + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
      NameDescription
      netThe Internet
      locYour Local Network
      NameDescription
      netThe Internet
      locYour Local Network
      - +

      Zones are defined in the /etc/shorewall/zones - file.

      - + file.

      +

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

      - + the firewall itself is known as fw.

      +

      Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

      - + in terms of zones.

      + - +

      For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file -matches the connection request then the first policy in /etc/shorewall/policy -that matches the request is applied. If that policy is REJECT or DROP  -the request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

      - + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

      +

      The /etc/shorewall/policy file included with the two-interface sample has the following policies:

      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      -
      - -
      +
      + +

      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.

      - + out. If you want your firewall system to have full access to servers +on the internet, uncomment that line.

      + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      fwnetACCEPT  
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      fwnetACCEPT  
      -
      - +
      +

      The above policy will:

      - +
        -
      1. allow all connection requests from your local network to the -internet
        2. -
      2. drop (ignore) all connection requests from the internet to your - firewall or local network
        3. -
      3. optionally accept all connection requests from the firewall to - the internet (if you uncomment the additional policy)
        4. -
      4. reject all other connection requests.
        5. - +
      5. allow all connection requests from your local network to +the internet
        6. +
      6. drop (ignore) all connection requests from the internet to + your firewall or local network
        7. +
      7. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
        8. +
      8. reject all other connection requests.
        9. +
      - +

      -     At this point, edit your /etc/shorewall/policy and make any changes - that you wish.

      - +     At this point, edit your /etc/shorewall/policy and make any +changes that you wish.

      +

      Network Interfaces

      - +

      -

      - +

      +

      The firewall has two network interfaces. Where Internet connectivity is through a cable or DSL "Modem", the External Interface will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be - a ppp interface (e.g., ppp0). If you connect via a regular modem, - your External Interface will also be ppp0. If you connect via ISDN, - your external interface will be ippp0.

      - + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point Tunneling + Protocol (PPTP) in which case the External Interface will +be a ppp interface (e.g., ppp0). If you connect via a regular modem, + your External Interface will also be ppp0. If you connect via ISDN, + your external interface will be ippp0.

      +

      -     If your external interface is ppp0 or ippp0  then -you will want to set CLAMPMSS=yes in -/etc/shorewall/shorewall.conf.

      - +     If your external interface is ppp0 or ippp0  +then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

      +

      Your Internal Interface 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 cross-over cable).

      - + (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 cross-over cable).

      +

      - 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.

      - + 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.

      +

      -     The Shorewall two-interface sample configuration assumes that the - external interface is eth0 and the internal interface is eth1. - If your configuration is different, you will have to modify the sample - /etc/shorewall/interfaces file - accordingly. While you are there, you may wish to review the list of options - that are specified for the interfaces. Some hints:

      - +     The Shorewall two-interface sample configuration assumes that + the external interface is eth0 and the internal interface is +eth1. If your configuration is different, you will have to modify +the sample /etc/shorewall/interfaces +file accordingly. While you are there, you may wish to review the list +of options that are specified for the interfaces. Some hints:

      +
        -
      • +

      • If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

        -
        • -
      • + you can replace the "detect" in the second column with "-".

        +
        • +

      • If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

        -
        • - + or if you have a static IP address, you can remove "dhcp" from the +option list.

        + +
      - +

      IP Addresses

      - +

      Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic - Host Configuration Protocol (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 static IP address; that -means that you configure your firewall's external interface to use that -address permanently. 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 Private IP address ranges for this purpose:

      - -
      + Protocol (IP) addresses. Normally, your ISP will assign you a +single Public IP address. This address may be assigned via the +Dynamic Host Configuration Protocol (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 static IP address; +that means that you configure your firewall's external interface to use +that address permanently. 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 Private IP address ranges for this purpose:

      + +
           10.0.0.0    - 10.255.255.255
           172.16.0.0  - 172.31.255.255
           192.168.0.0 - 192.168.255.255
      -
      - -
      +
      + +

      -     Before starting Shorewall, you should look at the IP address -of your external interface and if it is one of the above ranges, you -should remove the 'norfc1918' option from the external interface's entry -in /etc/shorewall/interfaces.

      -
      - -
      +     Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you + should remove the 'norfc1918' option from the external interface's +entry in /etc/shorewall/interfaces.

      +
      + +

      You will want to assign your addresses from the same sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet - will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 -is reserved as the Subnet Address and x.y.z.255 is reserved as -the Subnet Broadcast Address. In Shorewall, a subnet is described - using Classless InterDomain Routing (CIDR) - notation 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.

      -
      - -
      + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet + will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 + is reserved as the Subnet Address and x.y.z.255 is reserved as + the Subnet Broadcast Address. In Shorewall, a subnet is + described using Classless +InterDomain Routing (CIDR) notation 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.

      +
      + +

      Example sub-network:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      CIDR Notation:10.10.10.0/24
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      CIDR Notation:10.10.10.0/24
      -
      -
      - -
      + +
      + +

      It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

      -
      - -
      + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

      +
      + +

      One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, -systems send packets through a  gateway  (router).

      -
      - -
      + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

      +
      + +

      -     Your local computers (computer 1 and computer 2 in the above -diagram) should be configured with their default gateway to be -the IP address of the firewall's internal interface.     

      -
      - +     Your local computers (computer 1 and computer 2 in the above + diagram) should be configured with their default gateway to +be the IP address of the firewall's internal interface.      +

      +
      +

      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 "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      - + regarding subnetting and routing. If you are interested in learning more + about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      +

      The remainder of this quide will assume that you have configured - your network as shown here:

      - + your network as shown here:

      +

      -

      - +

      +

      The default gateway for computer's 1 & 2 would be 10.10.10.254.

      - +

      IP Masquerading (SNAT)

      - +

      The addresses reserved by RFC 1918 are sometimes referred - to as non-routable 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 Network Address Translation (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.

      - + to as non-routable 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 Network Address Translation + (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.

      +

      On Linux systems, the above process is often referred to as IP Masquerading but you will also see the term Source Network Address Translation (SNAT) used. Shorewall follows the convention used with Netfilter:

      - +
        -
      • +

      • Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

        -
        • -
      • + firewall system automatically detect the external interface address. +

        +
        • +

      • SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local network - to use.

        -
        • - + the source address that you want outbound packets from your local network + to use.

        + +
      - +

      In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading - if your external IP is dynamic and SNAT if the IP is static.

      - + entries in the /etc/shorewall/masq file. You will normally use Masquerading + if your external IP is dynamic and SNAT if the IP is static.

      +

      -     If your external firewall interface is eth0, 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.

      - +     If your external firewall interface is eth0, 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.

      +

      -     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.

      - -

      Port Forwarding (DNAT)

      - -

      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.

      - -

      The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure port - forwarding using DNAT rules in the /etc/shorewall/rules file.

      - -

      The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:<server local ip address> [:<server - port>]<protocol><port>  
      -
      - -

      Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

      - -
      - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2tcp80  
      -
      - -

      A couple of important points to keep in mind:

      - +     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.
      +
      + +     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:
      +

      +
        -
      • You must test the above rule from a client outside of your local - network (i.e., don't test from a browser running on computers 1 or 2 -or on the firewall). If you want to be able to access your web server -using the IP address of your external interface, see Shorewall FAQ #2.
        • -
      • 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.
        • - +
      • NAT_ENABLED=Yes
        • +
      • IP_FORWARDING=On
        +
        • +
      - -
      + +

      Port Forwarding (DNAT)

      + +

      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.

      + +

      The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

      + +

      The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2:80tcp5000  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:<server local ip address> [:<server + port>]<protocol><port>  
      -
      - -

      -     At this point, modify /etc/shorewall/rules to add any DNAT rules - that you require.

      - -

      Domain Name Server (DNS)

      - -

      Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your -primary and secondary name servers. Regardless of how DNS gets configured -on your firewall, it is your responsibility to configure the resolver -in your internal systems. You can take one of two approaches:

      - +
      + +

      Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2tcp80  
      +
      + +

      A couple of important points to keep in mind:

      +
        -
      • +
      • You must test the above rule from a client outside of your + local network (i.e., don't test from a browser running on computers + 1 or 2 or on the firewall). If you want to be able to access your web + server using the IP address of your external interface, see Shorewall FAQ #2.
        • +
      • 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.
        • + +
      + +
      + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2:80tcp5000  
      +
      + +

      +     At this point, modify /etc/shorewall/rules to add any DNAT +rules that you require.

      + +

      Domain Name Server (DNS)

      + +

      Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your + primary and secondary name servers. Regardless of how DNS gets configured + on your firewall, it is your responsibility to configure the resolver + in your internal systems. You can take one of two approaches:

      + +
        +

      • 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.

        -
        • -
      • + 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.

        +
        • +

      • -     You can configure a Caching Name Server on your firewall. - 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. -

        -
        • - +     You can configure a Caching Name Server on your firewall. + 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.

        + +
      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      -
      - -
      +
      + +

      Other Connections

      -
      - -
      +
      + +

      The two-interface sample includes the following rules:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTfwnettcp53  
      ACCEPTfwnetudp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTfwnettcp53  
      ACCEPTfwnetudp53  
      -
      -
      - -
      + +
      + +

      Those rules allow DNS access from your firewall and may be - removed if you uncommented the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

      -
      - -
      + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

      +
      + +

      The sample also includes:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp22  
      -
      -
      - -
      + +
      + +

      That rule allows you to run an SSH server on your firewall - and connect to that server from your local systems.

      -
      - -
      + and connect to that server from your local systems.

      +
      + +

      If you wish to enable other connections between your firewall - and other systems, the general format is:

      -
      - -
      -
      + and other systems, the general format is:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPT<source zone><destination zone><protocol><port>  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPT<source zone><destination zone><protocol><port>  
      -
      -
      - -
      + +
      + +

      Example - You want to run a Web Server on your firewall system:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80#Allow web accessfrom the internet
      ACCEPTlocfwtcp80#Allow web accessfrom the local network
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80#Allow web accessfrom the internet
      ACCEPTlocfwtcp80#Allow web accessfrom the local network
      -
      -
      - -
      + +
      + +

      Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on your firewall"

      -
      - -
      + listed above under "You can configure a Caching Name Server on your + firewall"

      +
      + +

      If you don't know what port and protocol a particular application uses, look here.

      -
      - -
      +
      + +

      Important: 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:

      -
      - -
      -
      + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      -
      -
      - -
      + +
      + +

      -     Now edit your /etc/shorewall/rules file to add or delete other - connections as required.

      -
      - -
      +     Now edit your /etc/shorewall/rules file to add or delete +other connections as required.

      +
      + +

      Starting and Stopping Your Firewall

      -
      - -
      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start -Shorewall before configuration is complete. Once you have completed configuration -of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
      -

      - +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file +/etc/shorewall/startup_disabled.
      +

      +

      IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
      -

      -
      - -
      + and set 'startup=1'.
      +

      +
      + +

      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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

      -
      - -
      + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +

      -     The two-interface sample assumes that you want to enable routing - to/from eth1 (the local network) when Shorewall is stopped. If - your local network isn't connected to eth1 or if you wish to enable - access to/from other hosts, change /etc/shorewall/routestopped accordingly.

      -
      - -
      +     The two-interface sample assumes that you want to enable +routing to/from eth1 (the local network) when Shorewall is stopped. +If your local network isn't connected to eth1 or if you wish to +enable access to/from other hosts, change /etc/shorewall/routestopped +accordingly.

      +
      + +

      WARNING: 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 /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

      -
      - -

      Last updated 11/21/2002 - alternate configuration + and test it using the "shorewall try" command.

      + + +

      Last updated 12/20/2002 - Tom Eastep

      - +

      Copyright 2002 Thomas - M. Eastep

      + M. Eastep

      +
      +
      +

      +



      diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 0ec037a7d..ca3e10a6b 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.11a +VERSION=1.3.12 usage() # $1 = exit status { @@ -119,6 +119,14 @@ restore_file /etc/shorewall/whitelist restore_file /etc/shorewall/rfc1918 +restore_file /etc/shorewall/init + +restore_file /etc/shorewall/start + +restore_file /etc/shorewall/stop + +restore_file /etc/shorewall/stopped + if [ -f /usr/lib/shorewall/version-${VERSION}.bkout ]; then restore_file /usr/lib/shorewall/version oldversion="`cat /usr/lib/shorewall/version`" diff --git a/STABLE/firewall b/STABLE/firewall index 3ee873ae0..fbbab24f3 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -61,9 +61,11 @@ list_search() # $1 = element to search for , $2-$n = list # Function to count list elements # list_count() { - local temp="`separate_list $1`" - - echo $temp | wc -w + arg_count() { + echo $# + } + + arg_count `separate_list $1` } # @@ -141,15 +143,53 @@ expandv() # $* = list of variable names done } +# +# Replace all leading "!" with "! " in the passed argument list +# + +fix_bang() { + local i; + + for i in $@; do + case $i in + !*) + echo "! ${i#!}" + ;; + *) + echo $i + ;; + esac + done +} + # # Run iptables and if an error occurs, stop the firewall and quit # run_iptables() { - if ! iptables `echo $@ | sed 's/!/! /g'`; then + + if ! iptables $@ ; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } +# +# Version of 'run_iptables' that inserts white space after "!" in the arg list +# +run_iptables2() { + + if [ "x${*%!*}" = "x$*" ]; then + # + # No "!" in the command -- just execute it + # + run_iptables $@ + return + fi + # + # Need to insert white space before each "!" + # + run_iptables `fix_bang $@` +} + # # Run ip and if an error occurs, stop the firewall and quit # @@ -194,7 +234,7 @@ createchain() # $1 = chain name, $2 = If non-null, don't create default rules [ -n "$ALLOWRELATED" ] && state="$state,RELATED" run_iptables -A $1 -m state --state $state -j ACCEPT [ -z "$NEWNOTSYN" ] && \ - run_iptables -A $1 -m state --state NEW -p tcp !--syn -j newnotsyn + run_iptables -A $1 -m state --state NEW -p tcp ! --syn -j newnotsyn fi eval ${1}_exists=Yes @@ -212,6 +252,22 @@ havechain() # $1 = name of chain eval test \"\$${1}_exists\" = Yes } +# +# Query NetFilter about the existence of a filter chain +# +chain_exists() # $1 = chain name +{ + qt iptables -L $1 -n +} + +# +# Query NetFilter about the existence of a mangle chain +# +mangle_chain_exists() # $1 = chain name +{ + qt iptables -t mangle -L $1 -n +} + # # Ensure that a chain exists (create it if it doesn't) # @@ -268,7 +324,7 @@ ensurenatchain() # $1 = chain name addnatrule() # $1 = chain name, remainder of arguments specify the rule { ensurenatchain $1 - run_iptables -t nat -A $@ + run_iptables2 -t nat -A $@ } # @@ -311,21 +367,6 @@ flushnat() # $1 = name of chain run_iptables -t nat -F $1 } -# -# Find interfaces to a given zone -# -# Read the interfaces file and for each record matching the passed ZONE, -# echo the expanded contents of the "INTERFACE" column -# -find_interfaces() # $1 = interface zone -{ - local zne=$1 - - while read z interface subnet options; do - [ "x`expand $z`" = "x$zne" ] && echo `expand $interface` - done < $TMP_DIR/interfaces -} - # # Chain name base for an interface # @@ -336,6 +377,25 @@ chain_base() #$1 = interface echo ${c:=common} } +# +# Find interfaces to a given zone +# +# Search the variables representing the contents of the interfaces file and +# for each record matching the passed ZONE, echo the expanded contents of +# the "INTERFACE" column +# +find_interfaces() # $1 = interface zone +{ + local zne=$1 + local z + local interface + + for interface in $all_interfaces; do + eval z=\$`chain_base ${interface}`_zone + [ "x${z}" = x${zne} ] && echo $interface + done +} + # # Forward Chain for an interface # @@ -352,16 +412,6 @@ input_chain() # $1 = interface echo `chain_base $1`_in } -# -# Input Chains (input and forward) for an interface -# -input_chains() # $1 = interface -{ - local base=`chain_base $1` - - echo ${base}_in ${base}_fwd -} - # # Output Chain for an interface # @@ -526,14 +576,28 @@ validate_interfaces_file() { while read z interface subnet options; do expandv z interface subnet options r="$z $interface $subnet $options" - [ "x$z" = "x-" ] || validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" + + [ "x$z" = "x-" ] && z= + + if [ -n "$z" ]; then + validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" + fi + + [ "x$interface" = "xlo" ] && \ + startup_error "Error: The loopback interface (lo) may not be defined in /etc/shorewall/interfaces" list_search $interface $all_interfaces && \ startup_error "Error: Duplicate Interface $interface" all_interfaces="$all_interfaces $interface" + options=`separate_list $options` + interface=`chain_base $interface` + + eval ${interface}_broadcast="$subnet" + eval ${interface}_zone="$z" + eval ${interface}_options=\"$options\" - for option in `separate_list $options`; do + for option in $options; do case $option in dhcp|noping|filterping|routestopped|norfc1918|multi|tcpflags) ;; @@ -650,7 +714,7 @@ validate_rule() { serv=$server ;; ~*) - fatal_error "Error: Rule \"$rule\" - Server may not be specified by MAC Address" + startup_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" ;; *) dest_interface="-o $server" @@ -913,12 +977,26 @@ validate_rules() # $1 = name of rules file # validate_policy() { + local clientwild + local serverwild + local zone + local zone1 + local pc + local chain + + all_policy_chains= + strip_file policy $policy while read client server policy loglevel synparams; do expandv client server policy loglevel synparams + + clientwild= + serverwild= + case "$client" in all|ALL) + clientwild=Yes ;; *) if ! validate_zone $client; then @@ -928,6 +1006,7 @@ validate_policy() case "$server" in all|ALL) + serverwild=Yes ;; *) if ! validate_zone $server; then @@ -952,7 +1031,45 @@ validate_policy() startup_error "Error: Duplicate policy $policy" fi - eval ${client}2${server}_is_policy=Yes + [ "x$loglevel" = "x-" ] && loglevel= + + chain=${client}2${server} + + all_policy_chains="$all_policy_chains $chain" + + eval ${chain}_is_policy=Yes + eval ${chain}_policy=$policy + eval ${chain}_loglevel=$loglevel + eval ${chain}_synparams=$synparams + + if [ -n "${clientwild}" ]; then + if [ -n "${serverwild}" ]; then + for zone in $zones $FW all; do + for zone1 in $zones $FW all; do + eval pc=\$${zone}2${zone1}_policychain + + [ -n "$pc" ] || \ + eval ${zone}2${zone1}_policychain=$chain + done + done + else + for zone in $zones $FW all; do + eval pc=\$${zone}2${server}_policychain + + [ -n "$pc" ] || \ + eval ${zone}2${server}_policychain=$chain + done + fi + elif [ -n "$serverwild" ]; then + for zone in $zones $FW all; do + eval pc=\$${client}2${zone}_policychain + + [ -n "$pc" ] || \ + eval ${client}2${zone}_policychain=$chain + done + else + eval ${chain}_policychain=${chain} + fi done < $TMP_DIR/policy } @@ -961,8 +1078,9 @@ validate_policy() # Find broadcast addresses # find_broadcasts() { - while read z interface bcast options; do - expandv interface bcast + for interface in $all_interfaces; do + interface=`chain_base $interface` + eval bcast=\$${interface}_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then @@ -973,7 +1091,7 @@ find_broadcasts() { elif [ "x${bcast}" != "x-" ]; then echo `separate_list $bcast` fi - done < $TMP_DIR/interfaces + done } # @@ -981,23 +1099,19 @@ find_broadcasts() { # find_interface_broadcasts() # $1 = Interface name { - while read z interface bcast options; do - expandv interface bcast - if [ "$interface" = "$1" ]; then - if [ "x$bcast" = "xdetect" ]; then - addr="`ip addr show $interface 2> /dev/null`" - if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then - addr="`echo "$addr" | \ + eval bcast=\$${1}_broadcast + + if [ "x$bcast" = "xdetect" ]; then + addr="`ip addr show $interface 2> /dev/null`" + if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then + addr="`echo "$addr" | \ grep "inet " | sed 's/^.* inet.*brd //;s/scope.*//'`" - echo $addr | cut -d' ' -f 1 - fi - elif [ "x${bcast}" != "x-" ]; then - echo `separate_list $bcast` - fi - - return + echo $addr | cut -d' ' -f 1 fi - done < $TMP_DIR/interfaces + elif [ "x${bcast}" != "x-" ]; then + echo `separate_list $bcast` + fi + } # @@ -1026,11 +1140,10 @@ find_interface_address() # $1 = interface # find_interfaces_by_option() # $1 = option { - while read ignore interface subnet options; do - expandv options - list_search $1 `separate_list $options` && \ - echo `expand $interface` - done < $TMP_DIR/interfaces + for interface in $all_interfaces; do + eval options=\$`chain_base ${interface}`_options + list_search $1 $options && echo $interface + done } # @@ -1044,11 +1157,11 @@ find_hosts_by_option() # $1 = option echo `expand $hosts` done < $TMP_DIR/hosts - while read ignore interface ignore1 options; do - expandv options - list_search $1 `separate_list $options` && \ - echo `expand $interface`:0.0.0.0/0 - done < $TMP_DIR/interfaces + for interface in $all_interfaces; do + eval options=\$`chain_base ${interface}`_options + list_search $1 $options && \ + echo ${interface}:0.0.0.0/0 + done } # @@ -1059,12 +1172,17 @@ find_hosts_by_option() # $1 = option have_interfaces_in_zone_with_option() # $1 = zone, $2 = option { local zne=$1 + local z + local interface - while read z interface broadcast options; do - [ "x`expand $z`" = "x$zne" ] && expandv options && \ - list_search $1 `separate_list $options` && \ + for interface in $all_interfaces; do + eval z=\$`chain_base ${interface}`_zone + + [ "x$z" = "x$zne" ] && \ + list_search $1 $options && \ return 0 - done < $TMP_DIR/interfaces + done + return 1 } @@ -1093,6 +1211,17 @@ run_user_exit() # $1 = file name # Stop the Firewall # stop_firewall() { + # + # Turn off trace unless we were tracing "stop" or "clear" + # + case $command in + stop|clear) + ;; + *) + set +x + ;; + esac + stopping="Yes" deletechain shorewall @@ -1139,7 +1268,6 @@ stop_firewall() { iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT - for interface in `find_interfaces_by_option dhcp`; do iptables -A INPUT -p udp -i $interface --dport 67:68 -j ACCEPT iptables -A OUTPUT -p udp -o $interface --dport 67:68 -j ACCEPT @@ -1417,7 +1545,7 @@ setup_mac_lists() { run_iptables -A $chain $macpart -j RETURN else for address in `separate_list $addresses` ; do - run_iptables -A $chain $macpart -s $address -j RETURN + run_iptables2 -A $chain $macpart -s $address -j RETURN done fi done < $TMP_DIR/maclist @@ -1425,7 +1553,11 @@ setup_mac_lists() { # Setup Logging variables # if [ -n "$MACLIST_LOG_LEVEL" ]; then - logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" + if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then + logpart="-j ULOG $LOGPARMS --ulog-prefix" + else + logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" + fi else logpart= fi @@ -1470,7 +1602,7 @@ setup_mac_lists() { for hosts in $maclist_hosts; do interface=${hosts%:*} hosts=${hosts#*:} - for chain in `input_chains $interface` ; do + for chain in `first_chains $interface` ; do run_iptables -A $chain -s $hosts -m state --state NEW \ -j `mac_chain $interface` done @@ -1547,14 +1679,13 @@ setup_nat() { qt ip addr del $external dev $interface fi - if [ -z "$allints" -o "$allints" = "Yes" \ - -o "$allints" = "yes" ] + if [ -z "$allints" -o "$allints" = "Yes" -o "$allints" = "yes" ] then addnatrule nat_in -d $external -j DNAT --to-destination $internal addnatrule nat_out -s $internal -j SNAT --to-source $external if [ "$localnat" = "Yes" -o "$localnat" = "yes" ]; then - run_iptables -t nat -A OUTPUT -d $external \ + run_iptables2 -t nat -A OUTPUT -d $external \ -j DNAT --to-destination $internal fi else @@ -1592,13 +1723,14 @@ delete_nat() { } # -# Process a TC Rule +# Process a TC Rule - $marking_chain is assumed to contain the name of the +# marking chain # process_tc_rule() { add_a_tc_rule() { r= - chain=tcpre + chain=$marking_chain if [ "x$source" != "x-" ]; then case $source in @@ -1625,7 +1757,7 @@ process_tc_rule() [ "x$port" = "x-" ] || r="${r}--dport $port " [ "x$sport" = "x-" ] || r="${r}--sport $sport " - run_iptables -t mangle -A $chain $r -j MARK --set-mark $mark + run_iptables2 -t mangle -A $chain $r -j MARK --set-mark $mark } @@ -1645,14 +1777,12 @@ process_tc_rule() # # Setup queuing and classes # -setup_tc() { - - echo "Setting up Traffic Control Rules..." - +setup_tc1() { # # Create the TC mangle chains # - run_iptables -t mangle -N tcpre + + run_iptables -t mangle -N $marking_chain run_iptables -t mangle -N tcout # # Process the TC Rules File @@ -1667,13 +1797,24 @@ setup_tc() { # # Link to the TC mangle chains from the main chains # - run_iptables -t mangle -A PREROUTING -j tcpre - run_iptables -t mangle -A OUTPUT -j tcout + + if [ $marking_chain = tcfor ]; then + run_iptables -t mangle -A FORWARD -j tcfor + else + run_iptables -t mangle -A PREROUTING -j tcpre + fi run_user_exit tcstart } +setup_tc() { + + echo "Setting up Traffic Control Rules..." + + setup_tc1 +} + # # Clear Traffic Shaping # @@ -1698,6 +1839,42 @@ delete_tc() done } +# +# Refresh queuing and classes +# +refresh_tc() { + + echo "Refreshing Traffic Control Rules..." + + delete_tc + + [ -n "$MARK_IN_FORWARD_CHAIN" ] && chain=tcfor || chain=tcpre + + if mangle_chain_exists $chain; then + # + # Flush the TC mangle chains + # + run_iptables -t mangle -F $chain + + run_iptables -t mangle -F tcout + # + # Process the TC Rules File + # + strip_file tcrules + + while read mark sources dests proto ports sports; do + expandv mark sources dests proto ports sports + rule=`echo "$mark $sources $dests $proto $ports $sports"` + process_tc_rule + done < $TMP_DIR/tcrules + + run_user_exit tcstart + else + setup_tc1 + fi + +} + # # Add a NAT rule - Helper function for the rules file processor # @@ -1770,7 +1947,7 @@ add_nat_rule() { # Generate nat table rules if [ "$source" = "$FW" ]; then - run_iptables -t nat -A OUTPUT $proto $sports -d $addr \ + run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \ $multiport $dports -j $target1 else chain=`dnat_chain $source` @@ -1874,6 +2051,9 @@ add_a_rule() *.*.*) serv=$server ;; + ~*) + fatal_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" + ;; *) dest_interface="-o $server" serv= @@ -1975,27 +2155,45 @@ add_a_rule() if [ $chain != ${FW}2${FW} ]; then serv="${serv:+-d $serv}" - [ -n "$loglevel" ] && run_iptables -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j LOG $LOGPARMS \ - --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel - run_iptables -A $chain $proto $multiport $state $cli $sports \ + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j LOG $LOGPARMS \ + --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + + + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ $serv $dports -j $target fi else - + # Destination is a simple zone [ -n "$addr" ] && fatal_error \ - "Error: An ADDRESS ($addr) is only allowed in" \ + "Error: An ORIGINAL DESTINATION ($addr) is only allowed in" \ " a DNAT or REDIRECT: \"$rule\"" - [ -n "$loglevel" ] && run_iptables -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j LOG \ - $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel - - run_iptables -A $chain $proto $multiport $dest_interface $state \ + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j ULOG \ + $LOGPARMS --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j LOG \ + $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + + run_iptables2 -A $chain $proto $multiport $dest_interface $state \ $cli $sports $dports -j $target fi } @@ -2111,6 +2309,8 @@ process_rule() # $1 = target chain=${source}2${dest} + ensurechain $chain + if [ "x$chain" = x${FW}2${FW} ]; then case $logtarget in REDIRECT) @@ -2344,24 +2544,24 @@ process_tos_rule() { case $srczone in $FW) - run_iptables -t mangle -A outtos \ + run_iptables2 -t mangle -A outtos \ $protocol $dest $dports $sports $tos ;; all|ALL) - run_iptables -t mangle -A outtos \ + run_iptables2 -t mangle -A outtos \ $protocol $dest $dports $sports $tos - run_iptables -t mangle -A pretos \ + run_iptables2 -t mangle -A pretos \ $protocol $dest $dports $sports $tos ;; *) if [ -n "$src" ]; then - run_iptables -t mangle -A pretos $src \ + run_iptables2 -t mangle -A pretos $src \ $protocol $dest $dports $sports $tos else eval interfaces=\$${srczone}_interfaces for interface in $interfaces; do - run_iptables -t mangle -A pretos -i $interface \ + run_iptables2 -t mangle -A pretos -i $interface \ $protocol $dest $dports $sports $tos done fi @@ -2471,8 +2671,16 @@ policy_rules() # $1 = chain to add rules to esac - [ $# -eq 3 ] && [ "x${3}" != "x-" ] && run_iptables -A $1 -j LOG $LOGPARMS \ - --log-prefix "Shorewall:${1}:${2}:" --log-level $3 + if [ $# -eq 3 -a "x${3}" != "x-" ]; then + if [ "$3" = ULOG ]; then + run_iptables -A $1 -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:${1}:${2}:" + else + run_iptables -A $1 -j LOG $LOGPARMS \ + --log-prefix "Shorewall:${1}:${2}:" --log-level $3 + fi + fi + [ -n "$target" ] && run_iptables -A $1 -j $target } @@ -2504,13 +2712,15 @@ default_policy() # $1 = client $2 = server apply_default() { + # + # Generate policy file column values from the policy chain + # + eval policy=\$${chain1}_policy + eval loglevel=\$${chain1}_loglevel + eval synparams=\$${chain1}_synparams # # Add the appropriate rules to the canonical chain ($chain) to enforce # the specified policy - # - # Construct policy chain name - # - chain1=${client}2${server} if [ "$chain" = "$chain1" ]; then # @@ -2564,27 +2774,13 @@ default_policy() # $1 = client $2 = server echo " Policy $policy for $1 to $2 using chain $chain" } - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - case "$client" in - all|ALL) - if [ "$server" = "$2" -o "$server" = "all" ]; then - apply_default $1 $2 - return - fi - ;; - *) - if [ "$client" = "$1" ] && \ - [ "$server" = "all" -o "$server" = "$2" ] - then - apply_default $1 $2 - return - fi - ;; - esac - done < $TMP_DIR/policy + eval chain1=\$${1}2${2}_policychain - fatal_error "Error: No default policy for zone $1 to zone $2" + if [ -n "$chain1" ]; then + apply_default $1 $2 + else + fatal_error "Error: No default policy for zone $1 to zone $2" + fi } # @@ -2600,33 +2796,20 @@ complete_standard_chain() # $1 = chain, $2 = source zone, $3 = destination zone { local policy= local loglevel= + local policychain= run_user_exit $1 + + eval policychain=\$${2}2${3}_policychain - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - - [ "x$loglevel" = "x-" ] && loglevel= + if [ -n "$policychain" ]; then + eval policy=\$${policychain}_policy + eval loglevel=\$${policychain}_loglevel - case "$client" in - all|ALL) - if [ "$server" = "$3" -o "$server" = "all" ]; then - policy_rules $1 $policy $loglevel - return - fi - ;; - *) - if [ "$client" = "$2" ] && \ - [ "$server" = "all" -o "$server" = "$3" ] - then - policy_rules $1 $policy $loglevel - return - fi - ;; - esac - done < $TMP_DIR/policy - - policy_rules $1 DROP INFO + policy_rules $1 $policy $loglevel + else + policy_rules $1 DROP INFO + fi } # @@ -2641,24 +2824,10 @@ rules_chain() # $1 = source zone, $2 = destination zone local chain=${1}2${2} havechain $chain && { echo $chain; return; } + + eval chain=\$${chain}_policychain - while read client server policy loglevel ; do - expandv client server policy loglevel - case "$client" in - all|ALL) - if [ "$server" = "$2" -o "$server" = "all" ]; then - echo all2${server} - return - fi - ;; - *) - if [ "$client" = "$1" -a "$server" = "all" ]; then - echo ${client}2${server} - return - fi - ;; - esac - done < $TMP_DIR/policy + [ -n "$chain" ] && { echo $chain; return; } fatal_error "Error: No appropriate chain for zone $1 to zone $2" } @@ -2790,12 +2959,20 @@ setup_intrazone() # $1 = zone # $dport = destination port selector # add_blacklist_rule() { - [ -n "$BLACKLIST_LOGLEVEL" ] && \ - run_iptables -A blacklst $source $proto $dport -j \ - LOG $LOGPARMS --log-prefix \ - "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" \ - --log-level $BLACKLIST_LOGLEVEL - run_iptables -A blacklst $source $proto $dport -j $disposition + if [ -n "$BLACKLIST_LOGLEVEL" ]; then + if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then + run_iptables2 -A blacklst $source $proto $dport -j \ + ULOG $LOGPARMS --ulog-prefix \ + "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" + else + run_iptables2 -A blacklst $source $proto $dport -j \ + LOG $LOGPARMS --log-prefix \ + "Shorewall:blacklst:$BLACKLIST_DISPOSITION:" \ + --log-level $BLACKLIST_LOGLEVEL + fi + fi + + run_iptables2 -A blacklst $source $proto $dport -j $disposition } # @@ -3088,9 +3265,16 @@ initialize_netfilter () { if [ -z "$NEWNOTSYN" ]; then createchain newnotsyn no run_user_exit newnotsyn - [ -n "$LOGNEWNOTSYN" ] && \ - run_iptables -A newnotsyn -j LOG \ - --log-prefix "Shorewall:newnotsyn:DROP:" --log-level $LOGNEWNOTSYN + if [ -n "$LOGNEWNOTSYN" ]; then + if [ "$LOGNEWNOTSYN" = ULOG ]; then + run_iptables -A newnotsyn -j ULOG \ + --ulog-prefix "Shorewall:newnotsyn:DROP:" + else + run_iptables -A newnotsyn -j LOG \ + --log-prefix "Shorewall:newnotsyn:DROP:" --log-level $LOGNEWNOTSYN + fi + fi + run_iptables -A newnotsyn -j DROP fi @@ -3105,7 +3289,7 @@ initialize_netfilter () { while read target ignore1 ignore2 address rest; do case $target in DROP|reject) - run_iptables -A dynamic -s $address -j $target + run_iptables2 -A dynamic -s $address -j $target ;; *) ;; @@ -3165,7 +3349,11 @@ build_common_chain() { add_common_rules() { logdisp() # $1 = Chain Name { - echo "LOG --log-prefix "Shorewall:${1}:DROP:" --log-level info" + if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then + echo "ULOG --ulog-prefix Shorewall:${1}:DROP:" + else + echo "LOG --log-prefix Shorewall:${1}:DROP: --log-level info" + fi } # # Reject Rules @@ -3181,10 +3369,16 @@ add_common_rules() { createchain badpkt no if [ -n "$LOGUNCLEAN" ]; then - logoptions="$LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - run_iptables -A badpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A badpkt -p ! tcp -j LOG $logoptions + if [ "$LOGUNCLEAN" = ULOG ]; then + logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:badpkt:DROP:" + logoptions="$logoptions --log-ip-options" + else + logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" + logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" + fi + + run_iptables -A badpkt -p tcp $logoptions --log-tcp-options + run_iptables -A badpkt -p ! tcp $logoptions fi run_iptables -A badpkt -j DROP @@ -3206,10 +3400,17 @@ add_common_rules() { createchain logpkt no [ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info - logoptions="$LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - run_iptables -A logpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A logpkt -p ! tcp -j LOG $logoptions + + if [ "$LOGUNCLEAN" = ULOG ]; then + logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:logpkt:LOG:" + logoptions="$logoptions --log-ip-options" + else + logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" + logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" + fi + + run_iptables -A logpkt -p tcp $logoptions --log-tcp-options + run_iptables -A logpkt -p ! tcp $logoptions echo "Mangled/Invalid Packet Logging enabled on:" @@ -3272,13 +3473,13 @@ add_common_rules() { ;; esac - run_iptables -A rfc1918 -s $subnet -j $target + run_iptables2 -A rfc1918 -s $subnet -j $target # # If packet mangling is enabled, trap packets with an # RFC1918 destination # if [ -n "$MANGLE_ENABLED" ]; then - run_iptables -t mangle -A man1918 -d $subnet -j $target + run_iptables2 -t mangle -A man1918 -d $subnet -j $target fi done < $TMP_DIR/rfc1918 @@ -3303,11 +3504,16 @@ add_common_rules() { if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then createchain logflags no - run_iptables -A logflags -j LOG $LOGPARMS \ - --log-level $TCP_FLAGS_LOG_LEVEL \ - --log-prefix "Shorewall:logflags:$TCP_FLAGS_DISPOSITION:" \ - --log-tcp-options --log-ip-options - + if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then + run_iptables -A logflags -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:logflags:$TCP_FLAGS_DISPOSITION:" \ + --log-tcp-options --log-ip-options + else + run_iptables -A logflags -j LOG $LOGPARMS \ + --log-level $TCP_FLAGS_LOG_LEVEL \ + --log-prefix "Shorewall:logflags:$TCP_FLAGS_DISPOSITION:" \ + --log-tcp-options --log-ip-options + fi case $TCP_FLAGS_DISPOSITION in REJECT) run_iptables -A logflags -j REJECT --reject-with tcp-reset @@ -3327,9 +3533,9 @@ add_common_rules() { run_iptables -A tcpflags -p tcp --tcp-flags SYN,RST SYN,RST $disposition run_iptables -A tcpflags -p tcp --tcp-flags SYN,FIN SYN,FIN $disposition # - # A Shorewall user reported seeing outgoing SYN ACK packets with DPT=0 - # That prompted me to add the following which will stop an incoming - # SYN with SPT=0 + # There are a lot of probes to ports 80, 3128 and 8080 that use a source + # port of 0. This catches them even if they are directed at an IP that + # hosts a web server. # run_iptables -A tcpflags -p tcp --syn --sport 0 $disposition @@ -3353,7 +3559,7 @@ add_common_rules() { # # Enable icmp output # - run_iptables -A OUTPUT -m state --state ! INVALID -p icmp -j ACCEPT + run_iptables -A OUTPUT -p icmp -j ACCEPT # # Route Filtering # @@ -3405,10 +3611,10 @@ apply_policy_rules() { # # Create policy chains # - while read client server policy loglevel synparams; do - expandv client server policy loglevel synparams - - chain=${client}2${server} + for chain in $all_policy_chains; do + eval policy=\$${chain}_policy + eval loglevel=\$${chain}_loglevel + eval synparams=\$${chain}_synparams [ -n "$synparams" ] && setup_syn_flood_chain $chain $synparams @@ -3434,15 +3640,18 @@ apply_policy_rules() { # Otherwise, this is a canonical chain which will be handled in # the for loop below # - [ "$client" = "all" -o "$server" = "all" ] && \ - policy_rules $chain $policy $loglevel + case $chain in + all2*|*2all) + policy_rules $chain $policy $loglevel + ;; + esac [ -n "$synparams" ] && \ [ $policy = ACCEPT -o $policy = CONTINUE ] && \ run_iptables -I $chain 2 -p tcp --syn -j @$chain fi - done < $TMP_DIR/policy + done # # Add policy rules to canonical chains # @@ -3767,6 +3976,8 @@ refresh_firewall() determine_zones + validate_interfaces_file + [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" determine_interfaces @@ -3784,19 +3995,16 @@ refresh_firewall() # refresh_blacklist + # + # Refresh Traffic Control + # + [ -n "$TC_ENABLED" ] && refresh_tc + report "Shorewall Refreshed" rm -rf $TMP_DIR } -# -# Query NetFilter about the existence of a filter chain -# -chain_exists() # $1 = chain name -{ - qt iptables -L $1 -n -} - # # Add a host or subnet to a zone # @@ -4222,6 +4430,8 @@ do_initialize() { MACLIST_LOG_LEVEL= TCP_FLAGS_DISPOSITION= TCP_FLAGS_LOG_LEVEL= + RFC1918_LOG_LEVEL= + MARK_IN_FORWARD_CHAIN= stopping= have_mutex= masq_seq=1 @@ -4331,6 +4541,10 @@ do_initialize() { TCP_FLAGS_DISPOSITION=DROP fi + [ -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 + } # diff --git a/STABLE/functions b/STABLE/functions index 340c0d9b2..90ad27b35 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -25,9 +25,22 @@ find_file() # # Replace commas with spaces and echo the result # -separate_list() -{ - echo $1 | sed 's/,/ /g' +separate_list() { + local list + local part + local newlist + + list="$@" + part="${list%%,*}" + newlist="$part" + + while [ "x$part" != "x$list" ]; do + list="${list#*,}"; + part="${list%%,*}"; + newlist="$newlist $part"; + done + + echo "$newlist" } # diff --git a/STABLE/init b/STABLE/init new file mode 100644 index 000000000..d7bee1d0a --- /dev/null +++ b/STABLE/init @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/init +# +# Add commands below that you want to be executed at the beginning of +# a "shorewall start" or "shorewall restart" command. +# diff --git a/STABLE/install.sh b/STABLE/install.sh index 1b57b98e2..166ddc017 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.11a +VERSION=1.3.12 usage() # $1 = exit status { @@ -488,6 +488,46 @@ else echo "RFC 1918 file installed as ${PREFIX}/etc/shorewall/rfc1918" fi # +# Install the init file +# +if [ -f ${PREFIX}/etc/shorewall/init ]; then + backup_file /etc/shorewall/init +else + run_install -o $OWNER -g $GROUP -m 0600 init ${PREFIX}/etc/shorewall/init + echo + echo "Init file installed as ${PREFIX}/etc/shorewall/init" +fi +# +# Install the start file +# +if [ -f ${PREFIX}/etc/shorewall/start ]; then + backup_file /etc/shorewall/start +else + run_install -o $OWNER -g $GROUP -m 0600 start ${PREFIX}/etc/shorewall/start + echo + echo "Start file installed as ${PREFIX}/etc/shorewall/start" +fi +# +# Install the stop file +# +if [ -f ${PREFIX}/etc/shorewall/stop ]; then + backup_file /etc/shorewall/stop +else + run_install -o $OWNER -g $GROUP -m 0600 stop ${PREFIX}/etc/shorewall/stop + echo + echo "Stop file installed as ${PREFIX}/etc/shorewall/stop" +fi +# +# Install the stopped file +# +if [ -f ${PREFIX}/etc/shorewall/stopped ]; then + backup_file /etc/shorewall/stopped +else + run_install -o $OWNER -g $GROUP -m 0600 stopped ${PREFIX}/etc/shorewall/stopped + echo + echo "Stopped file installed as ${PREFIX}/etc/shorewall/stopped" +fi +# # Backup the version file # if [ -z "$PREFIX" ]; then diff --git a/STABLE/policy b/STABLE/policy index 6c6ba0fbe..421d05c78 100644 --- a/STABLE/policy +++ b/STABLE/policy @@ -29,6 +29,12 @@ # log message is generated. See syslog.conf(5) for a # description of log levels. # +# Beginning with Shorewall version 1.3.12, you may +# also specify ULOG (must be in upper case). This will +# log to the ULOG target and sent to a separate log +# through use of ulogd +# (http://www.gnumonks.org/projects/ulogd). +# # If you don't want to log but need to specify the # following column, place "_" here. # diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index 862ded861..ce2580b87 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -2,22 +2,39 @@ This is a minor release of Shorewall that has a couple of new features. New features include: -1) A 'tcpflags' option has been added to entries in - /etc/shorewall/interfaces. This option causes Shorewall to make a - set of sanity check on TCP packet header flags. +1) "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart). -2) It is now allowed to use 'all' in the SOURCE or DEST column in a - rule. When used, 'all' must appear by itself (in may not be - qualified) and it does not enable intra-zone traffic (e.g., the rule - "ACCEPT loc all tcp 80" does not enable http traffic from - 'loc' to 'loc'). +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. -3) Shorewall's use of the 'echo' command is now compatible with bash - clones such as ash and dash. +3) "shorewall [re]start" has been speeded up by more than 40% with + my configuration. Your milage may vary. -4) fw->fw policies now generate a startup error. fw->fw rules generate - a warning and are ignored. +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" +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. +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. +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. +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. diff --git a/STABLE/rules b/STABLE/rules index cff2b3f70..8554645d9 100644 --- a/STABLE/rules +++ b/STABLE/rules @@ -31,6 +31,13 @@ # level (e.g, REJECT:info). This causes the packet to be # logged at the specified level. # +# Beginning with Shorewall version 1.3.12, you may +# also specify ULOG (must be in upper case) as a log level.\ +# This will log to the ULOG target and sent to a separate log +# through use of ulogd +# (http://www.gnumonks.org/projects/ulogd). +# +# # SOURCE Source hosts to which the rule applies. May be a zone # defined in /etc/shorewall/zones, $FW to indicate the # firewall itself, or "all" If the ACTION is DNAT or diff --git a/STABLE/shorewall b/STABLE/shorewall index 1a7253cb6..0245eb4ae 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -58,6 +58,7 @@ # shorewall show nat Display the rules in the nat table # shorewall show {mangle|tos} Display the rules in the mangle table # shorewall show tc Display traffic control info +# shorewall show classifiers Display classifiers # shorewall version Display the installed version id # shorewall check Verify the more heavily-used # configuration files. @@ -258,7 +259,8 @@ packet_log() # $1 = number of messages [ -n "$realtail" ] && options="-n$1" grep 'Shorewall:\|ipt_unclean' $LOGFILE | \ - sed s/" $host kernel: Shorewall:"/" "/ | \ + sed s/" kernel:"// | \ + sed s/" $host Shorewall:"/" "/ | \ sed s/" $host kernel: ipt_unclean: "/" "/ | \ sed 's/MAC=.*SRC=/SRC=/' | \ tail $options @@ -294,6 +296,34 @@ show_tc() { } +# +# Show classifier information +# +show_classifiers() { + + show_one_classifier() { + local device=${1%@*} + qdisc=`tc qdisc list dev $device` + + if [ -n "$qdisc" ]; then + echo Device $device: + tc -s filter ls dev $device + echo + fi + } + + ip link list | \ + while read inx interface details; do + case $inx in + [0-9]*) + show_one_classifier ${interface%:} + ;; + *) + ;; + esac + done + +} # # Monitor the Firewall # @@ -383,6 +413,15 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that echo show_tc timed_read + + clear + echo "$banner `date`" + echo + echo + echo "Packet Classifiers" + echo + show_classifiers + timed_read done } @@ -450,7 +489,7 @@ usage() # $1 = exit status echo "where is one of:" echo " add [:] " echo " delete [:] " - echo " show [|connections|log|nat|tc|tos]" + echo " show [|classifiers|connections|log|nat|tc|tos]" echo " start" echo " stop" echo " reset" @@ -629,6 +668,11 @@ case "$1" in echo show_tc ;; + classifiers) + echo "Shorewall-$version Clasifiers at $HOSTNAME - `date`" + echo + show_classifiers + ;; *) echo "Shorewall-$version Chain $2 at $HOSTNAME - `date`" echo @@ -658,8 +702,12 @@ case "$1" in echo packet_log 20 echo + echo "NAT Table" + echo iptables -t nat -L -n -v echo + echo "Mangle Table" + echo iptables -t mangle -L -n -v echo cat /proc/net/ip_conntrack diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index 5a97918ec..f0981141a 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -9,6 +9,35 @@ # (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) ############################################################################## # +# General note about log levels. Log levels are a method of describing +# to syslog (8) the importance of a message and a number of parameters +# in this file have log levels as their value. +# +# Valid levels are: +# +# 7 debug +# 6 info +# 5 notice +# 4 warning +# 3 err +# 2 crit +# 1 alert +# 0 emerg +# +# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall +# log messages are generated by NetFilter and are logged using facility +# 'kern' and the level that you specifify. If you are unsure of the level +# to choose, 6 (info) is a safe bet. You may specify levels by name or by +# number. +# +# If you have build your kernel with ULOG target support, you may also +# specify a log level of ULOG (must be all caps). Rather than log its +# messages to syslogd, Shorewall will direct netfilter to log the messages +# via the ULOG target which will send them to a process called 'ulogd'. +# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be +# configured to log all Shorewall message to their own log file +################################################################################ +# # PATH - Change this if you want to change the order in which Shorewall # searches directories for executable files. # @@ -96,6 +125,8 @@ LOGBURST= # packets are logged under the 'logunclean' interface option. If the variable # is empty, these packets will still be logged at the 'info' level. # +# See the comment at the top of this file for a description of log levels +# LOGUNCLEAN=info @@ -191,6 +222,8 @@ BLACKLIST_DISPOSITION=DROP # (beward of DOS attacks resulting from such logging). If not set, no logging # of blacklist packets occurs. # +# See the comment at the top of this file for a description of log levels +# BLACKLIST_LOGLEVEL= # @@ -353,6 +386,8 @@ MUTEX_TIMEOUT=60 # it will be rejected by the firewall. If you want these rejects logged, # then set LOGNEWNOTSYN to the syslog log level at which you want them logged. # +# See the comment at the top of this file for a description of log levels +# # Example: LOGNEWNOTSYN=debug @@ -400,6 +435,8 @@ MACLIST_DISPOSITION=REJECT # Specifies the logging level for connection requests that fail MAC # verification. If set to the empty value (MACLIST_LOG_LEVEL="") then # such connection requests will not be logged. +# +# See the comment at the top of this file for a description of log levels # MACLIST_LOG_LEVEL=info @@ -420,8 +457,42 @@ TCP_FLAGS_DISPOSITION=DROP # Specifies the logging level for packets that fail TCP Flags # verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then # such packets will not be logged. +# +# See the comment at the top of this file for a description of log levels # TCP_FLAGS_LOG_LEVEL=info +# +# RFC1918 Log Level +# +# Specifies the logging level for packets that fail RFC 1918 +# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then +# RFC1918_LOG_LEVEL=info is assumed. +# +# See the comment at the top of this file for a description of log levels +# + +RFC1918_LOG_LEVEL=info + +# +# Mark Packets in the forward chain +# +# When processing the tcrules file, Shorewall normally marks packets in the +# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set +# this to "Yes". If not specified or if set to the empty value (e.g., +# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. +# +# Marking packets in the FORWARD chain has the advantage that inbound +# packets destined for Masqueraded/SNATed local hosts have had their destination +# address rewritten so they can be marked based on their destination. When +# packets are marked in the PREROUTING chain, packets destined for +# Masqueraded/SNATed local hosts still have a destination address corresponding +# to the firewall's external interface. +# +# Note: Older kernels do not support marking packets in the FORWARD chain and +# setting this variable to Yes may cause startup problems. + +MARK_IN_FORWARD_CHAIN=No + #LAST LINE -- DO NOT REMOVE diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 8ad1f1ddf..05b8bcaf1 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.11a +%define version 1.3.12 %define release 1 %define prefix /usr @@ -94,6 +94,10 @@ fi %attr(0600,root,root) %config(noreplace) /etc/shorewall/hosts %attr(0600,root,root) %config(noreplace) /etc/shorewall/blacklist %attr(0600,root,root) %config(noreplace) /etc/shorewall/rfc1918 +%attr(0600,root,root) %config(noreplace) /etc/shorewall/init +%attr(0600,root,root) %config(noreplace) /etc/shorewall/start +%attr(0600,root,root) %config(noreplace) /etc/shorewall/stop +%attr(0600,root,root) %config(noreplace) /etc/shorewall/stopped %attr(0544,root,root) /sbin/shorewall %attr(0444,root,root) /usr/lib/shorewall/functions %attr(0544,root,root) /usr/lib/shorewall/firewall @@ -101,6 +105,15 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Fri Dec 27 2002 Tom Eastep +- Changes version to 1.3.12 +* Sun Dec 22 2002 Tom Eastep +- Changes version to 1.3.12-0Beta3 +* Fri Dec 20 2002 Tom Eastep +- Changes version to 1.3.12-0Beta2 +* Wed Dec 18 2002 Tom Eastep +- Changes version to 1.3.12-0Beta1 +- Add init, start, stop and stopped files. * Tue Dec 03 2002 Tom Eastep - Changes version to 1.3.11a * Sun Nov 24 2002 Tom Eastep diff --git a/STABLE/start b/STABLE/start new file mode 100644 index 000000000..bd36e8544 --- /dev/null +++ b/STABLE/start @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/start +# +# Add commands below that you want to be executed after shorewall has +# been started or restarted. +# diff --git a/STABLE/stop b/STABLE/stop new file mode 100644 index 000000000..5f097b037 --- /dev/null +++ b/STABLE/stop @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/stop +# +# Add commands below that you want to be executed at the beginning of a +# "shorewall stop" command. +# diff --git a/STABLE/stopped b/STABLE/stopped new file mode 100644 index 000000000..90afeb3ac --- /dev/null +++ b/STABLE/stopped @@ -0,0 +1,6 @@ +############################################################################ +# Shorewall 1.3 -- /etc/shorewall/stopped +# +# Add commands below that you want to be executed at the completion of a +# "shorewall stop" command. +# diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index 35c77e5d9..6bb0492cc 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -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.11a +VERSION=1.3.12 usage() # $1 = exit status { diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index 82de396d7..26a605911 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -1,1161 +1,1204 @@ - + - + - + Shorewall 1.3 Documentation - + + - + - + - - - + + - - - + + + +
      - +
      +

      Shorewall 1.3 Reference

      -
      - +

      This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall in common setups - may be found in the QuickStart - Guides.

      - + Step-by-step instructions for configuring Shorewall in common +setups may be found in the QuickStart Guides. +

      Components

      - +

      Shorewall consists of the following components:

      - +
        -
      • params -- a parameter file -installed in /etc/shorewall that can be used to establish the values -of shell variables for use in other files.
        • -
      • shorewall.conf -- a parameter - file installed in /etc/shorewall that is used to set several -firewall parameters.
        • -
      • zones - a parameter file installed - in /etc/shorewall that defines a network partitioning into "zones"
        • -
      • policy -- a parameter file - installed in /etc/shorewall/ that establishes overall firewall - policy.
        • -
      • rules -- a parameter file -installed in /etc/shorewall and used to express firewall rules -that are exceptions to the high-level policies established in -/etc/shorewall/policy.
        • -
      • blacklist -- a parameter file - installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC - addresses.
        • -
      • functions -- a set of shell functions used by both - the firewall and shorewall shell programs. Installed in /etc/shorewall - prior to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 -and in /usr/lib/shorewall in later versions.
        • -
      • modules -- a parameter file - installed in /etc/shorewall and that specifies kernel modules -and their parameters. Shorewall will automatically load the modules - specified in this file.
        • -
      • tos -- a parameter file installed - in /etc/shorewall that is used to specify how the Type of Service - (TOS) field in packets is to be set.
        • -
      • icmp.def -- a parameter file - installed in /etc/shorewall and that specifies the default handling - of ICMP packets when the applicable policy is DROP or REJECT.
        • -
      • common.def -- a parameter file - installed in in /etc/shorewall that defines firewall-wide rules that - are applied before a DROP or REJECT policy is applied.
        • -
      • interfaces -- a parameter - file installed in /etc/shorewall/ and used to describe the -interfaces on the firewall system.
        • -
      • hosts -- a parameter file installed - in /etc/shorewall/ and used to describe individual hosts or -subnetworks in zones.
        • -
      • maclist -- a parameter file installed - in /etc/shorewall and used to verify the MAC address (and possibly also -the IP address(es)) of devices.
        -
        • -
      • masq - This file -also describes IP masquerading under Shorewall and is installed in - /etc/shorewall.
        • -
      • firewall - -- a shell program that reads the configuration files in /etc/shorewall - and configures your firewall. This file is installed in your - init.d directory (/etc/rc.d/init.d ) where it is renamed shorewall.  - /etc/shorewall/firewall (/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 - and /usr/lib/shorewall/firewall in 1.3.9 and later) is a symbolic link - to this program.
        • -
      • nat -- a parameter file in /etc/shorewall - used to define static NAT .
        • -
      • proxyarp -- a parameter -file in /etc/shorewall used to define Proxy - Arp .
        • -
      • rfc1918 -- a parameter file -in /etc/shorewall used to define the treatment of packets under the - norfc1918 interface option.
        • -
      • routestopped -- a parameter - file in /etc/shorewall used to define those hosts that can access the - firewall when Shorewall is stopped.
        • -
      • tcrules -- - a parameter file in /etc/shorewall used to define rules for classifying - packets for Traffic Shaping/Control.
        • -
      • tunnels -- a parameter file - in /etc/shorewall used to define IPSec tunnels.
        • -
      • shorewall -- a shell program - (requiring a Bourne shell or derivative) used to control and - monitor the firewall. This should be placed in /sbin or in - /usr/sbin (the install.sh script and the rpm install this file - in /sbin).
        • -
      • version -- a file created in /etc/shorewall/ - (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall - beginning in version 1.3.9) that describes the version of  Shorewall - installed on your system.
        • - +
      • params -- a parameter +file installed in /etc/shorewall that can be used to establish the +values of shell variables for use in other files.
        • +
      • shorewall.conf -- a parameter + file installed in /etc/shorewall that is used to set several + firewall parameters.
        • +
      • zones - a parameter file + installed in /etc/shorewall that defines a network partitioning + into "zones"
        • +
      • policy -- a parameter +file installed in /etc/shorewall/ that establishes overall +firewall policy.
        • +
      • rules -- a parameter +file installed in /etc/shorewall and used to express firewall +rules that are exceptions to the high-level policies established +in /etc/shorewall/policy.
        • +
      • blacklist -- a parameter + file installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC + addresses.
        • +
      • functions -- a set of shell functions used by + both the firewall and shorewall shell programs. Installed in /etc/shorewall + prior to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 + and in /usr/lib/shorewall in later versions.
        • +
      • modules -- a parameter + file installed in /etc/shorewall and that specifies kernel modules + and their parameters. Shorewall will automatically load the +modules specified in this file.
        • +
      • tos -- a parameter file installed + in /etc/shorewall that is used to specify how the Type of Service + (TOS) field in packets is to be set.
        • +
      • icmp.def -- a parameter + file installed in /etc/shorewall and that specifies the default + handling of ICMP packets when the applicable policy is DROP or REJECT.
        • +
      • common.def -- a parameter + file installed in in /etc/shorewall that defines firewall-wide rules + that are applied before a DROP or REJECT policy is applied.
        • +
      • interfaces -- a +parameter file installed in /etc/shorewall/ and used to describe +the interfaces on the firewall system.
        • +
      • hosts -- a parameter file + installed in /etc/shorewall/ and used to describe individual + hosts or subnetworks in zones.
        • +
      • maclist -- a parameter file installed + in /etc/shorewall and used to verify the MAC address (and possibly also + the IP address(es)) of devices.
        +
        • +
      • masq - This file + also describes IP masquerading under Shorewall and is installed in + /etc/shorewall.
        • +
      • firewall + -- a shell program that reads the configuration files in /etc/shorewall + and configures your firewall. This file is installed in +your init.d directory (/etc/rc.d/init.d ) where it is renamed + shorewall.  /etc/shorewall/firewall (/var/lib/shorewall/firewall + in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 and + later) is a symbolic link to this program.
        • +
      • nat -- a parameter file +in /etc/shorewall used to define static +NAT .
        • +
      • proxyarp -- a parameter + file in /etc/shorewall used to define Proxy + Arp .
        • +
      • rfc1918 -- a parameter file + in /etc/shorewall used to define the treatment of packets under the + norfc1918 interface option.
        • +
      • routestopped -- a parameter + file in /etc/shorewall used to define those hosts that can access + the firewall when Shorewall is stopped.
        • +
      • tcrules -- + a parameter file in /etc/shorewall used to define rules for classifying + packets for Traffic Shaping/Control.
        • +
      • tunnels -- a parameter + file in /etc/shorewall used to define IPSec tunnels.
        • +
      • shorewall -- a shell + program (requiring a Bourne shell or derivative) used to + control and monitor the firewall. This should be placed in + /sbin or in /usr/sbin (the install.sh script and the rpm install + this file in /sbin).
        • +
      • version -- a file created in /etc/shorewall/ + (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall + beginning in version 1.3.9) that describes the version of  Shorewall + installed on your system.
        • +
      - +

      /etc/shorewall/params

      - +

      You may use the file /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.

      - + that you can then use in some of the other configuration files.

      +

      It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

      - + within the Shorewall programs

      +

      Example:

      - + 
       	NET_IF=eth0
      	NET_BCAST=130.252.100.255
      	NET_OPTIONS=noping,norfc1918
      - +

      Example (/etc/shorewall/interfaces record):

      - + 
      	net $NET_IF $NET_BCAST $NET_OPTIONS
      - +

      The result will be the same as if the record had been written

      - + 
      	net eth0 130.252.100.255 noping,norfc1918
      - +

      Variables may be used anywhere in the other configuration - files.

      - + files.

      +

      /etc/shorewall/zones

      - +

      This file is used to define the network zones. There is one entry - in /etc/shorewall/zones for each zone; Columns in an entry are:

      - + in /etc/shorewall/zones for each zone; Columns in an entry are:

      +
        -
      • ZONE - short name for the zone. The name should -be 5 characters or less in length and consist of lower-case letters -or numbers. Short names must begin with a letter and the name assigned - to the firewall is reserved for use by Shorewall itself. Note that - the output produced by iptables is much easier to read if you select - short names that are three characters or less in length. The name - "all" may not be used as a zone name nor may the zone name assigned to - the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.
        • -
      • DISPLAY - The name of the zone as displayed during - Shorewall startup.
        • -
      • COMMENTS - Any comments that you want to make about - the zone. Shorewall ignores these comments.
        • - +
      • ZONE - short name for the zone. The name should + be 5 characters or less in length and consist of lower-case letters + or numbers. Short names must begin with a letter and the name assigned + to the firewall is reserved for use by Shorewall itself. Note that + the output produced by iptables is much easier to read if you +select short names that are three characters or less in length. +The name "all" may not be used as a zone name nor may the zone name +assigned to the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.
        • +
      • DISPLAY - The name of the zone as displayed +during Shorewall startup.
        • +
      • COMMENTS - Any comments that you want to make + about the zone. Shorewall ignores these comments.
        • +
      - +

      The /etc/shorewall/zones file released with Shorewall is as follows:

      - + - + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + - + - +
      ZONE DISPLAY COMMENTS
      ZONE DISPLAY COMMENTS
      netNetInternet
      locLocalLocal networks
      dmzDMZDemilitarized zone
      netNetInternet
      locLocalLocal networks
      dmzDMZDemilitarized zone
      - +

      You may add, delete and modify entries in the /etc/shorewall/zones file - as desired so long as you have at least one zone defined.

      - + as desired so long as you have at least one zone defined.

      +

      Warning 1: If you rename or delete a zone, you should perform "shorewall - stop; shorewall start" to install the change rather than "shorewall -restart".

      - + stop; shorewall start" to install the change rather than "shorewall + restart".

      +

      Warning 2: The order of entries in the /etc/shorewall/zones file is - significant in some cases.

      - + significant in some cases.

      +

      /etc/shorewall/interfaces

      - +

      This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There will be one entry in - /etc/shorewall/interfaces for each of your interfaces. Columns in an entry - are:

      - + interfaces are connected to which zone. There will be one entry in + /etc/shorewall/interfaces for each of your interfaces. Columns in an +entry are:

      +
        -
      • ZONE - A zone defined in the /etc/shorewall/zones - file or  "-". If you specify "-", you must use the /etc/shorewall/hosts file to define the zones - accessed via this interface.
        • -
      • INTERFACE - the name of the interface (examples: -eth0, ppp0, ipsec+). DO NOT INCLUDE THE -LOOPBACK INTERFACE (lo) IN THIS FILE!!!
        • -
      • BROADCAST - the broadcast address(es) for the sub-network(s) - attached to the interface. This should be left empty for P-T-P interfaces - (ppp*, ippp*); if you need to specify options for such an interface, - enter "-" in this column. If you supply the special value "detect" in - this column, the firewall will automatically determine the broadcast - address. In order to use "detect": +
      • ZONE - A zone defined in the /etc/shorewall/zones file or  "-". If you +specify "-", you must use the /etc/shorewall/hosts + file to define the zones accessed via this interface.
        • +
      • INTERFACE - the name of the interface (examples: + eth0, ppp0, ipsec+). Each interface can be listed on only one record + in this file. DO NOT INCLUDE THE LOOPBACK + INTERFACE (lo) IN THIS FILE!!!
        • +
      • BROADCAST - the broadcast address(es) for the + sub-network(s) attached to the interface. This should be left +empty for P-T-P interfaces (ppp*, ippp*); if you need to specify +options for such an interface, enter "-" in this column. If you supply +the special value "detect" in this column, the firewall will automatically + determine the broadcast address. In order to use "detect": +
          -
        • you must have iproute installed
          • -
        • the interface must be up before you start your firewall
          • -
        • the interface must only be attached to a single sub-network - (i.e., there must have a single broadcast address). 
          • - +
        • you must have iproute installed
          • +
        • the interface must be up before you start your firewall
          • +
        • the interface must only be attached to a single sub-network + (i.e., there must have a single broadcast address). 
          • +
        -
        • -
      • OPTIONS - a comma-separated list of options. Possible - options include: - +
        • +
      • OPTIONS - a comma-separated list of options. +Possible options include: +

        tcpflags (added in version 1.3.11) - This option causes Shorewall to make sanity checks on the header flags in TCP packets arriving -on this interface. Packets failing these checks are logged according to the -TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf -and are disposed of according to the TCP_FLAGS_DISPOSITION option.
        -
        -blacklist         - This option causes incoming packets on this - interface to be checked against the blacklist.
        -
        - dhcp         - The interface is assigned an IP address via DHCP or -is used by a DHCP server running on the firewall. The firewall -will be configured to allow DHCP traffic to and from the interface -even when the firewall is stopped. You may also wish to use this option -if you have a static IP but you are on a LAN segment that has a lot of -Laptops that use DHCP and you select the norfc1918 option (see -below).

        +on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; +these flag combinations are typically used for "silent" port scans. Packets + failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option + in /etc/shorewall/shorewall.conf and are disposed of +according to the TCP_FLAGS_DISPOSITION option.
        +
        + blacklist         - This option causes incoming packets on this + interface to be checked against the blacklist.
        +
        + dhcp         - The interface is assigned an IP address via DHCP +or is used by a DHCP server running on the firewall. The firewall + will be configured to allow DHCP traffic to and from the interface + even when the firewall is stopped. You may also wish to use this option + if you have a static IP but you are on a LAN segment that has a lot + of Laptops that use DHCP and you select the norfc1918 option +(see below).

        - +

        noping - ICMP echo-request (ping) packets addressed to - the firewall will be ignored by this interface.
        -
        - filterping - ICMP echo-request (ping) packets addressed -to the firewall will be handled according to the /etc/shorewall/rules -and /etc/shorewall/policy file. If the applicable policy is DROP or REJECT - and you have supplied your own /etc/shorewall/icmpdef file then these - 'ping' requests will be passed through the rules in that file before -being dropped or rejected. If neither noping nor filterping -is specified then the firewall will automatically ACCEPT these 'ping' -requests. If both noping and filterping are specified, - filterping takes precedence.

        + the firewall will be ignored by this interface.
        +
        + filterping - ICMP echo-request (ping) packets addressed + to the firewall will be handled according to the /etc/shorewall/rules + and /etc/shorewall/policy file. If the applicable policy is DROP or +REJECT and you have supplied your own /etc/shorewall/icmpdef file then +these 'ping' requests will be passed through the rules in that file +before being dropped or rejected. If neither noping nor filterping + is specified then the firewall will automatically ACCEPT these 'ping' + requests. If both noping and filterping are specified, + filterping takes precedence.

        - +

        routestopped - Beginning with Shorewall 1.3.4, this option - is deprecated in favor of the /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from this interface - will be accepted and routing will occur between this interface and - other routestopped interfaces.

        + is deprecated in favor of the /etc/shorewall/routestopped + file. When the firewall is stopped, traffic to and from this interface + will be accepted and routing will occur between this interface + and other routestopped interfaces.

        - +

        norfc1918 - Packets arriving on this interface and that - have a source address that is reserved in RFC 1918 or in other RFCs -will be dropped after being optionally logged. If packet -mangling is enabled in /etc/shorewall/shorewall.conf , then packets -arriving on this interface that have a destination address that is -reserved by one of these RFCs will also be logged and dropped.
        -
        - Addresses blocked by the standard rfc1918 - file include those addresses reserved by RFC1918 plus other - ranges reserved by the IANA or by other RFCs.

        + have a source address that is reserved in RFC 1918 or in other RFCs + will be dropped after being optionally logged. If packet + mangling is enabled in /etc/shorewall/shorewall.conf , then + packets arriving on this interface that have a destination address + that is reserved by one of these RFCs will also be logged and dropped.
        +
        + Addresses blocked by the standard rfc1918 + file include those addresses reserved by RFC1918 plus +other ranges reserved by the IANA or by other RFCs.

        - +

        Beware that as IPv4 addresses become in increasingly short supply, - ISPs are beginning to use RFC 1918 addresses within their own infrastructure. - Also, many cable and DSL "modems" have an RFC 1918 address that can -be used through a web browser for management and monitoring functions. -If you want to specify norfc1918 on your external interface but -need to allow access to certain addresses from the above list, see FAQ 14.

        + ISPs are beginning to use RFC 1918 addresses within their own infrastructure. + Also, many cable and DSL "modems" have an RFC 1918 address that can + be used through a web browser for management and monitoring functions. + If you want to specify norfc1918 on your external interface but + need to allow access to certain addresses from the above list, see + FAQ 14.

        - +

        routefilter - Invoke the Kernel's route filtering - (anti-spoofing) facility on this interface. The kernel will reject - any packets incoming on this interface that have a source address - that would be routed outbound through another interface on the firewall. - Warning: If you specify this option - for an interface then the interface must be up prior to starting the - firewall.

        + (anti-spoofing) facility on this interface. The kernel will reject + any packets incoming on this interface that have a source address + that would be routed outbound through another interface on the +firewall. Warning: If you specify this +option for an interface then the interface must be up prior to starting +the firewall.

        - +

        multi - The interface has multiple addresses and - you want to be able to route between them. Example: you have two - addresses on your single local interface eth1, one each in subnets - 192.168.1.0/24 and 192.168.2.0/24 and you want to route between these - subnets. Because you only have one interface in the local zone, Shorewall - won't normally create a rule to forward packets from eth1 to eth1. - Adding "multi" to the entry for eth1 will cause Shorewall to create - the loc2loc chain and the appropriate forwarding rule.

        - + you want to be able to route between them. Example: you have two + addresses on your single local interface eth1, one each in subnets + 192.168.1.0/24 and 192.168.2.0/24 and you want to route between + these subnets. Because you only have one interface in the local +zone, Shorewall won't normally create a rule to forward packets from + eth1 to eth1. Adding "multi" to the entry for eth1 will cause + Shorewall to create the loc2loc chain and the appropriate forwarding + rule.

        + +

        dropunclean - Packets from this interface that are selected by the 'unclean' match target in iptables will be optionally logged and then dropped. - Warning: This feature -requires that UNCLEAN match support be configured in your - kernel, either in the kernel itself or as a module. UNCLEAN - support is broken in some versions of the kernel but appears - to work ok in 2.4.17-rc1.
        -
        - Update 12/17/2001:         The unclean match - patch from 2.4.17-rc1 is Warning: This feature + requires that UNCLEAN match support be configured in your + kernel, either in the kernel itself or as a module. UNCLEAN + support is broken in some versions of the kernel but appears + to work ok in 2.4.17-rc1.
        +
        + Update 12/17/2001:         The unclean +match patch from 2.4.17-rc1 is available - for download. I am currently running this patch - applied to kernel 2.4.16.

        - -

        Update 12/20/2001: I've - seen a number of tcp connection requests with OPT -(020405B40000080A...) being dropped in the - badpkt chain. This appears to be a bug in -the remote TCP stack whereby it is 8-byte aligning -a timestamp (TCP option 8) but rather than padding with 0x01 - it is padding with 0x00. It's a tough call whether to deny - people access to your servers because of this rather minor - bug in their networking software. If you wish to disable -the check that causes these connections to be dropped, - here's - a kernel patch against 2.4.17-rc2.

        - + for download. I am currently running this patch + applied to kernel 2.4.16.

        + + +

        Update 12/20/2001: I've + seen a number of tcp connection requests with OPT + (020405B40000080A...) being dropped in the + badpkt chain. This appears to be a bug +in the remote TCP stack whereby it is 8-byte aligning + a timestamp (TCP option 8) but rather than padding with 0x01 + it is padding with 0x00. It's a tough call whether to deny + people access to your servers because of this rather +minor bug in their networking software. If you wish +to disable the check that causes these connections + to be dropped, here's + a kernel patch against 2.4.17-rc2.

        + +

        logunclean - This option works like dropunclean - with the exception that packets selected by the 'unclean' - match target in iptables are logged but not dropped. - The level at which the packets are logged is determined - by the setting of LOGUNCLEAN - and if LOGUNCLEAN has not been set, "info" is assumed.

        - + with the exception that packets selected by the +'unclean' match target in iptables are logged but +not dropped. The level at which the packets +are logged is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN +has not been set, "info" is assumed.

        + +

        proxyarp (Added in version 1.3.5) - This option causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp - and is used when implementing Proxy ARP Sub-netting - as described at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do not set this option if you are implementing Proxy ARP through entries in /etc/shorewall/proxyarp.
        -
        - maclist (Added in version 1.3.10) - If this option is specified, - all connection requests from this interface are subject to + maclist (Added in version 1.3.10) - If this option is specified, + all connection requests from this interface are subject to MAC Verification. May only be specified for - ethernet interfaces.
        -

        + ethernet interfaces.

        • - +
      - + +

      My recommendations concerning options:
      +

      + +
        +
      • External Interface -- tcpflags,blacklist,filterping,norfc1918,routefilter
        • +
      • Internal Interface -- routestopped
        • +
      • Wireless Interface -- maclist,routefilter,tcpflags
        +
        • +
      • Don't use dropunclean -- It's broken in my opinion
        • +
      • Use logunclean only when you are trying to debug a problem
        • +
      • Use dhcp,multi and proxyarp when needed.
        +
        • + +
      + +

      + +

      Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local network and -eth0 gets its IP address via DHCP. You want to ignore ping requests from -the internet and you want to check all packets entering -from the internet against the black -list. Your /etc/shorewall/interfaces file would be as follows:

      + to a Cable or DSL modem and eth1 connects to your local network and + eth0 gets its IP address via DHCP. You want to ignore ping requests +from the internet and you want to check all packets +entering from the internet against the black list. Your /etc/shorewall/interfaces file +would be as follows:

      - -
      + +
      - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + - +
      ZONE INTERFACE BROADCAST OPTIONS
      neteth0detectdhcp,noping,norfc1918,blacklist
      loceth1detect 
      ZONE INTERFACE BROADCAST OPTIONS
      neteth0detectdhcp,noping,norfc1918,blacklist
      loceth1detect 
      -
      +
      - +

      Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:

      + file would be:

      - -
      + +
      - - - - - - - - - - - - - + + + + + + + + + + + + + - + + - +
      ZONE INTERFACE BROADCAST OPTIONS
      netppp0  
      ZONE INTERFACE BROADCAST OPTIONS
      netppp0  
      -
      +
      - +

      Example 3: You have local interface eth1 with two IP addresses - 192.168.1.1/24 and 192.168.12.1/24

      - -
      + +
      - - - - - - - - - - - - - + + + + + + + + + + + + + - - + +
      ZONE INTERFACE BROADCAST OPTIONS
      loceth1192.168.1.255,192.168.12.255 
      ZONE INTERFACE BROADCAST OPTIONS
      loceth1192.168.1.255,192.168.12.255 
      -
      +
      - +

      /etc/shorewall/hosts - Configuration

      - + Configuration +

      For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.

      - +

      WARNING: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.

      - +

      Columns in this file are:

      - + +
        -
      • ZONE - A zone defined in the /etc/shorewall/zones - file.
        • -
      • HOST(S) - The name of a network interface followed - by a colon (":") followed by either:
        • - +
      • ZONE - A zone defined in the /etc/shorewall/zones file.
        • +
      • HOST(S) - The name of a network interface followed + by a colon (":") followed by either:
        • +
      - +
      - +
        -
      1. An IP address (example - eth1:192.168.1.3)
        2. +
      2. An IP address (example - eth1:192.168.1.3)
        3. -
      3. A subnet in CIDR notation - (example - eth2:192.168.2.0/24)
        4. +
      4. A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
        5. - +
      - +

      The interface name much match an entry in /etc/shorewall/interfaces.

      -
      - + + +
        -
      • OPTIONS - A comma-separated list of options.
        • - +
      • OPTIONS - A comma-separated list of options.
        • +
      - +
      - +

      routestopped - Beginning with Shorewall 1.3.4, this option is deprecated in favor of the /etc/shorewall/routestopped file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will occur -between this host and other routestopped interfaces and hosts.
      -
      - maclist - Added in version 1.3.10. If specified, connection requests - from the hosts specified in this entry are subject to routestopped interfaces and hosts.
      +
      + maclist - Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to       MAC Verification. This option is only valid - for ethernet interfaces.
      -

      -
      + for ethernet interfaces.
      +

      + - +

      If you don't define any hosts for a zone, the hosts in the zone default - to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces - to the zone.

      + to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces + to the zone.

      - +

      Note 1: You probably DON'T want to specify any hosts for your internet zone since the hosts that you specify will be the only ones that you will be able to access without adding additional rules.

      - +

      Note 2: The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the host file - is processed. Please read the description of -that variable carefully.

      + in /etc/shorewall/shorewall.conf + has an important effect on how the host file + is processed. Please read the description of + that variable carefully.

      - +

      Example:

      - +

      Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:

      - + you want to make into separate zones:

      + +
        -
      • 192.168.1.0/25 
        • -
      • 192.168.1.128/25
        • - +
      • 192.168.1.0/25 
        • +
      • 192.168.1.128/25
        • +
      - +

      Your /etc/shorewall/interfaces file might look like:

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - -
      ZONE INTERFACE BROADCAST OPTIONS
      neteth0detectdhcp,noping,norfc1918
      -eth1detect 
      -
      - - -

      The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces - to multiple zones.

      - - -

      Your /etc/shorewall/hosts file might look like:

      - - -
      - - - - - - - - - - - - - - - - - - - - - - - -
      ZONE HOST(S) OPTIONS
      loc1eth1:192.168.1.0/25 
      loc2eth1:192.168.1.128/25routestopped
      -
      - - -

      Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.

      - - -

      Nested and Overlapping Zones

      - - -

      The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow -you to define nested or overlapping zones. Such overlapping/nested zones - are allowed and Shorewall processes zones in the order that they appear - in the /etc/shorewall/zones file. So if you have nested zones, you want - the sub-zone to appear before the super-zone and in the case of overlapping - zones, the rules that will apply to hosts that belong to both zones -is determined by which zone appears first in /etc/shorewall/zones.

      - - -

      Hosts that belong to more than one zone may be managed by the rules - of all of those zones. This is done through use of the special CONTINUE policy described below.

      - - -

      - /etc/shorewall/policy Configuration.

      - - -

      This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms of clients - who initiate connections and servers who receive those connection - requests. Policies defined in /etc/shorewall/policy describe which zones - are allowed to establish connections with other zones.

      - - -

      Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to a particular - connection request then the policy from /etc/shorewall/policy is applied.

      - - -

      Four policies are defined:

      - - -
        -
      • ACCEPT - The connection is allowed.
        • -
      • DROP - The connection request is ignored.
        • -
      • REJECT - The connection request is rejected with -an RST (TCP) or an ICMP destination-unreachable packet being returned - to the client.
        • -
      • CONTINUE - The connection is neither ACCEPTed, -DROPped nor REJECTed. CONTINUE may be used when one or both of the -zones named in the entry are sub-zones of or intersect with another -zone. For more information, see below. 
        • - -
      - -

      For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time that the policy - is applied.

      - - -

      Entries in /etc/shorewall/policy have four columns as follows:

      - - -
        - -
      1. SOURCE - The name of -a client zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or -"all").
        2. - -
      2. DEST - The name of a -destination zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all"). -Shorewall automatically allows all traffic from the firewall to itself so -the name of the firewall zone cannot appear in both the -SOURCE and DEST columns.
        3. - -
      3. POLICY - The default -policy for connection requests from the SOURCE zone to the DESTINATION -zone.
        4. - -
      4. LOG LEVEL - Optional. -If left empty, no log message is generated when the policy is applied. - Otherwise, this column should contain an integer or name indicating - a syslog level. See the syslog.conf man page for a description of - each log level.
        5. - -
      5. LIMIT:BURST - Optional. -If left empty, TCP connection requests from the SOURCE zone -to the DEST zone will not be rate-limited. Otherwise, this -column specifies the maximum rate at which TCP connection requests will -be accepted followed by a colon (":") followed by the maximum burst size -that will be tolerated. Example: 10/sec:40 specifies that -the maximum rate of TCP connection requests allowed will be 10 per second -and a burst of 40 connections will be tolerated. Connection requests in -excess of these limits will be dropped.
        6. - - -
      - - -

      In the SOURCE and DEST columns, you can enter "all" to indicate all - zones. 

      - - -

      The policy file installed by default is as follows:

      - - -
      - - +
      + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      SOURCEDEST POLICY LOG LEVELLIMIT:BURST
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      -
      - - -

      This table may be interpreted as follows:

      - -
        -
      • All connection requests from the local network to hosts on -the internet are accepted.
        • -
      • All connection requests originating from the internet are -ignored and logged at level KERNEL.INFO.
        • -
      • All other connection requests are rejected and logged.
        • - -
      - -

      WARNING:

      - -

      The firewall script processes  the - /etc/shorewall/policy file from top to bottom and uses the first -applicable policy that it finds. For example, in the following -policy file, the policy for (loc, loc) connections would be ACCEPT as - specified in the first entry even though the third entry in the file specifies - REJECT.

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
      locallACCEPT  
      netallDROPinfo 
      loclocREJECTinfo 
      -
      - -

      - The CONTINUE policy

      - -

      Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones to be managed - under the rules of all of these zones. Let's look at an example:

      - -

      /etc/shorewall/zones:

      - -
      - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - +
      ZONE DISPLAY COMMENTS
      samSamSam's system at home
      netInternetThe Internet
      locLocLocal Network
      ZONE INTERFACE BROADCAST OPTIONS
      neteth0detectdhcp,noping,norfc1918
      -eth1detect 
      -
      - -

      /etc/shorewall/interfaces:

      - -
      +
      + + +

      The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.

      + + +

      Your /etc/shorewall/hosts file might look like:

      + + +
      + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - - +
      ZONE INTERFACE BROADCAST OPTIONS
      -eth0detectdhcp,noping,norfc1918
      loceth1detectroutestopped
      ZONE HOST(S) OPTIONS
      loc1eth1:192.168.1.0/25 
      loc2eth1:192.168.1.128/25routestopped
      -
      - -

      /etc/shorewall/hosts:

      - -
      - +
      + + +

      Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.

      + + +

      Nested and Overlapping Zones

      + + +

      The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow +you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that they +appear in the /etc/shorewall/zones file. So if you have nested zones, +you want the sub-zone to appear before the super-zone and in the case +of overlapping zones, the rules that will apply to hosts that belong +to both zones is determined by which zone appears first in /etc/shorewall/zones.

      + + +

      Hosts that belong to more than one zone may be managed by the rules + of all of those zones. This is done through use of the special CONTINUE policy described below.

      + + +

      + /etc/shorewall/policy Configuration.

      + + +

      This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in terms of +clients who initiate connections and servers who receive + those connection requests. Policies defined in /etc/shorewall/policy +describe which zones are allowed to establish connections with other +zones.

      + + +

      Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to a particular + connection request then the policy from /etc/shorewall/policy is applied.

      + + +

      Four policies are defined:

      + + +
        +
      • ACCEPT - The connection is allowed.
        • +
      • DROP - The connection request is ignored.
        • +
      • REJECT - The connection request is rejected +with an RST (TCP) or an ICMP destination-unreachable packet being +returned to the client.
        • +
      • CONTINUE - The connection is neither ACCEPTed, + DROPped nor REJECTed. CONTINUE may be used when one or both of the + zones named in the entry are sub-zones of or intersect with another + zone. For more information, see below. 
        • + +
      + + +

      For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that the + policy is applied.

      + + +

      Entries in /etc/shorewall/policy have four columns as follows:

      + + +
        + +
      1. SOURCE - The name +of a client zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or + "all").
        2. + +
      2. DEST - The name of + a destination zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or +"all"). Shorewall automatically allows all traffic from the firewall to +itself so the name of the firewall zone cannot appear +in both the SOURCE and DEST columns.
        3. + +
      3. POLICY - The default + policy for connection requests from the SOURCE zone to the DESTINATION + zone.
        4. + +
      4. LOG LEVEL - Optional. + If left empty, no log message is generated when the policy is applied. + Otherwise, this column should contain an integer or name indicating + a syslog level.
        5. + +
      5. LIMIT:BURST - Optional. + If left empty, TCP connection requests from the SOURCE zone + to the DEST zone will not be rate-limited. Otherwise, this + column specifies the maximum rate at which TCP connection requests + will be accepted followed by a colon (":") followed by the maximum burst + size that will be tolerated. Example: 10/sec:40 specifies +that the maximum rate of TCP connection requests allowed will be 10 per +second and a burst of 40 connections will be tolerated. Connection requests +in excess of these limits will be dropped.
        6. + + +
      + + +

      In the SOURCE and DEST columns, you can enter "all" to indicate all + zones. 

      + + +

      The policy file installed by default is as follows:

      + + +
      + + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - +
      ZONE HOST(S) OPTIONS
      neteth0:0.0.0.0/0 
      sameth0:206.191.149.197routestopped
      SOURCEDEST POLICY LOG LEVELLIMIT:BURST
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      -
      +
      + + +

      This table may be interpreted as follows:

      + +
        +
      • All connection requests from the local network to hosts + on the internet are accepted.
        • +
      • All connection requests originating from the internet +are ignored and logged at level KERNEL.INFO.
        • +
      • All other connection requests are rejected and logged.
        • + +
      -

      Note that Sam's home system is a member of both the sam zone - and the net zone and as described above , that means that sam must -be listed before net  in /etc/shorewall/zones.

      +

      WARNING:

      -

      /etc/shorewall/policy:

      +

      The firewall script processes  the + /etc/shorewall/policy file from top to bottom and uses the first + applicable policy that it finds. For example, in the following + policy file, the policy for (loc, loc) connections would be ACCEPT as + specified in the first entry even though the third entry in the file +specifies REJECT.

      -
      - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - +
      SOURCE DEST POLICY LOG LEVEL
      locnetACCEPT 
      samallCONTINUE 
      netallDROPinfo
      allallREJECTinfo
      SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
      locallACCEPT  
      netallDROPinfo 
      loclocREJECTinfo 
      -
      + -

      The second entry above says that when Sam is the client, connection - requests should first be process under rules where the source zone is - sam and if there is no match then the connection request should be - treated under rules where the source zone is net. It is important - that this policy be listed BEFORE the next policy (net to all).

      +

      + The CONTINUE policy

      -

      Partial /etc/shorewall/rules:

      +

      Where zones are nested or overlapping , the + CONTINUE policy allows hosts that are within multiple zones to be managed + under the rules of all of these zones. Let's look at an example:

      -
      - +

      /etc/shorewall/zones:

      + +
      + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ...      
      DNATsamloc:192.168.1.3tcpssh- 
      DNATnetloc:192.168.1.5tcpwww- 
      ...      
      ZONE DISPLAY COMMENTS
      samSamSam's system at home
      netInternetThe Internet
      locLocLocal Network
      +
      + +

      /etc/shorewall/interfaces:

      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ZONE INTERFACE BROADCAST OPTIONS
      -eth0detectdhcp,noping,norfc1918
      loceth1detectroutestopped
      +
      + +

      /etc/shorewall/hosts:

      + +
      + + + + + + + + + + + + + + + + + + + + +
      ZONE HOST(S) OPTIONS
      neteth0:0.0.0.0/0 
      sameth0:206.191.149.197routestopped
      -
      - -

      Given these two rules, Sam can connect to the firewall's internet interface - with ssh and the connection request will be forwarded to 192.168.1.3. - Like all hosts in the net zone, Sam can connect to the firewall's - internet interface on TCP port 80 and the connection request will be forwarded - to 192.168.1.5. The order of the rules is not significant.

      - -

      Sometimes it is necessary to suppress port forwarding - for a sub-zone. For example, suppose that all hosts can SSH to the firewall - and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the - firewall's external IP, he should be connected to the firewall itself. - Because of the way that Netfilter is constructed, this requires two -rules as follows:

      - -
      - -

       

      - + +

      Note that Sam's home system is a member of both the sam zone + and the net zone and + as described above , that means that sam +must be listed before net  in /etc/shorewall/zones.

      + +

      /etc/shorewall/policy:

      + +
      - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - -
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
             
      ...      
      DNATsamfwtcpssh- 
      DNATnet!samloc:192.168.1.3tcpssh- 
      ...      
      SOURCE DEST POLICY LOG LEVEL
      locnetACCEPT 
      samallCONTINUE 
      netallDROPinfo
      allallREJECTinfo
      -
      + + + + +
      + +

      The second entry above says that when Sam is the client, connection + requests should first be process under rules where the source zone +is sam and if there is no match then the connection request should + be treated under rules where the source zone is net. It is important + that this policy be listed BEFORE the next policy (net to all).

      + +

      Partial /etc/shorewall/rules:

      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ...      
      DNATsamloc:192.168.1.3tcpssh- 
      DNATnetloc:192.168.1.5tcpwww- 
      ...      
      +
      + +

      Given these two rules, Sam can connect to the firewall's internet interface + with ssh and the connection request will be forwarded to 192.168.1.3. + Like all hosts in the net zone, Sam can connect to the firewall's + internet interface on TCP port 80 and the connection request will be + forwarded to 192.168.1.5. The order of the rules is not significant.

      + +

      Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can SSH to the + firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects + to the firewall's external IP, he should be connected to the firewall + itself. Because of the way that Netfilter is constructed, this requires + two rules as follows:

      + +
      + +

       

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
             
      ...      
      DNATsamfwtcpssh- 
      DNATnet!samloc:192.168.1.3tcpssh- 
      ...      
      +
      +

      The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the @@ -1164,318 +1207,334 @@ rules as follows:

      connection port forwarded to 192.168.1.3. If you need to exclude more than one zone in this way, - you can list the zones separated - by commas (e.g., net!sam,joe,fred). - This technique also may be - used when the ACTION is REDIRECT.

      + you can list the zones separated + by commas (e.g., net!sam,joe,fred). + This technique also may +be used when the ACTION is +REDIRECT.

      - +

      /etc/shorewall/rules

      - +

      The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules - for each of these rules. 
      -

      -

      Shorewall automatically enables firewall->firewall traffic over the -loopback interface (lo) -- that traffic cannot be regulated using rules and -any rule that tries to regulate such traffic will generate a warning and -will be ignored.
      -

      - - - -

      Entries in the file have the following columns:

      - -
        -
      • ACTION -
          -
        • ACCEPT, DROP or REJECT. These have the same meaning here -as in the policy file above.
          • -
        • DNAT -- Causes the connection request to be forwarded to -the system specified in the DEST column (port forwarding). "DNAT" -stands for "Destination Network Address Translation"
          • -
        • REDIRECT -- Causes the connection request to be redirected - to a port on the local (firewall) system.
          • - -
        - -

        The ACTION may optionally be followed by ":" and a syslogd log - level (example: REJECT:info). This causes the packet to be logged at - the specified level prior to being processed according to the specified - ACTION.
        -
        - The use of DNAT or REDIRECT requires that you have NAT enabled.
        -  

        -
        • -
      • SOURCE - Describes the source hosts to which the rule -applies.. The contents of this field must begin with the name of -a zone defined in /etc/shorewall/zones, $FW or "all". If the ACTION -is DNAT or REDIRECT, sub-zones may be excluded from the rule by following -the initial zone name with "!' and a comma-separated list of those -sub-zones to be excluded. There is an example above.
        -
        - If the source is not 'all' then the source may be further restricted -by adding a colon (":") followed by a comma-separated list of qualifiers. -Qualifiers are may include: - -
          -
        • An interface name - refers to any connection requests arriving - on the specified interface (example loc:eth4). Beginning with - Shorwall 1.3.9, the interface name may optionally be followed by a colon -(":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
          • -
        • An IP address - refers to a connection request from the -host with the specified address (example net:155.186.235.151). -If the ACTION is DNAT, this must not be a DNS name.
          • -
        • A MAC Address in Shorewall format.
          • -
        • A subnet - refers to a connection request from any host -in the specified subnet (example net:155.186.235.0/24).
          • - -
        -
        • -
      • DEST - Describes the destination host(s) to which the - rule applies. May take any of the forms described above for SOURCE - plus the following two additional forms: + in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules + for each of these rules. 
        +

        +

        Shorewall automatically enables firewall->firewall traffic over the + loopback interface (lo) -- that traffic cannot be regulated using rules +and any rule that tries to regulate such traffic will generate a warning +and will be ignored.
        +

        + + + +

        Entries in the file have the following columns:

        + +
          +
        • ACTION +
            -
          • An IP address followed by a colon and the port number - that the server is listening on (service names from /etc/services - are not allowed - example loc:192.168.1.3:80).
            -
            • -
          • A single port number (again, service names are not allowed) - -- this form is only allowed if the ACTION is REDIRECT and refers - to a server running on the firewall itself and listening on the - specified port.
            -
            • - +
          • ACCEPT, DROP or REJECT. These have the same meaning +here as in the policy file above.
            • +
          • DNAT -- Causes the connection request to be forwarded + to the system specified in the DEST column (port forwarding). +"DNAT" stands for "Destination Network Address + Translation"
            • +
          • REDIRECT -- Causes the connection request to be redirected + to a port on the local (firewall) system.
            • +
          -
          • -
        • PROTO - Protocol. Must be a protocol name from /etc/protocols, - a number, "all" or "related". Specifies the protocol of the connection - request. "related" should be specified only if you have given ALLOWRELATED="no" - in /etc/shorewall/shorewall.conf and you wish to override that setting - for related connections originating with the client(s) and server(s) - specified in this rule. When "related" is given for the protocol, - the remainder of the columns should be left blank.
          • -
        • DEST PORT(S) - Port or port range (<low port>:<high - port>) being connected to. May only be specified if the protocol - is tcp, udp or icmp. For icmp, this column's contents are interpreted - as an icmp type. If you don't want to specify DEST PORT(S) but need - to include information in one of the columns to the right, enter - "-" in this column. You may give a list of ports and/or port ranges - separated by commas. Port numbers may be either integers or service names - from /etc/services.
          • -
        • SOURCE PORTS(S) - May be used to restrict - the rule to a particular client port or port range (a port range is - specified as <low port number>:<high port number>). If -you don't want to restrict client ports but want to specify something -in the next column, enter "-" in this column. If you wish to specify -a list of port number or ranges, separate the list elements with commas - (with no embedded white space). Port numbers may be either integers -or service names from /etc/services.
          • -
        • ORIGINAL DEST - This column may only be non-empty if - the ACTION is DNAT or REDIRECT.
          -
          - If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column -is left empty, any connection request arriving at the firewall from -the SOURCE that matches the rule will be forwarded or redirected. This - works fine for connection requests arriving from the internet where - the firewall has only a single external IP address. When the firewall - has multiple external IP addresses or when the SOURCE is other than - the internet, there will usually be a desire for the rule to only apply - to those connection requests directed to a particular IP address (see - Example 2 below for another usage). That IP address (or a comma-separated + +

          The ACTION may optionally be followed by ":" and a syslog +level (example: REJECT:info). This causes the packet to be logged + at the specified level prior to being processed according to the specified + ACTION.
          +
          + The use of DNAT or REDIRECT requires that you have NAT enabled.
          +  

          +
          • +
        • SOURCE - Describes the source hosts to which the +rule applies.. The contents of this field must begin with the +name of a zone defined in /etc/shorewall/zones, $FW or "all". If the + ACTION is DNAT or REDIRECT, sub-zones may be excluded from the rule +by following the initial zone name with "!' and a comma-separated +list of those sub-zones to be excluded. There is an example above.
          +
          + If the source is not 'all' then the source may be further +restricted by adding a colon (":") followed by a comma-separated +list of qualifiers. Qualifiers are may include: + +
            +
          • An interface name - refers to any connection requests + arriving on the specified interface (example loc:eth4). Beginning + with Shorwall 1.3.9, the interface name may optionally be followed by +a colon (":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, + net:eth0:192.0.2.0/24).
            • +
          • An IP address - refers to a connection request from +the host with the specified address (example net:155.186.235.151). + If the ACTION is DNAT, this must not be a DNS name.
            • +
          • A MAC Address in Shorewall format.
            • +
          • A subnet - refers to a connection request from any host + in the specified subnet (example net:155.186.235.0/24).
            • + +
          +
          • +
        • DEST - Describes the destination host(s) to which + the rule applies. May take any of the forms described above for + SOURCE plus the following two additional forms: + +
            +
          • An IP address followed by a colon and the port number + that the server is listening on (service names from /etc/services + are not allowed - example loc:192.168.1.3:80).
            +
            • +
          • A single port number (again, service names are not allowed) + -- this form is only allowed if the ACTION is REDIRECT and refers + to a server running on the firewall itself and listening on +the specified port.
            +
            • + +
          +
          • +
        • PROTO - Protocol. Must be a protocol name from + /etc/protocols, a number, "all" or "related". Specifies the protocol + of the connection request. "related" should be specified only +if you have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf +and you wish to override that setting for related connections originating + with the client(s) and server(s) specified in this rule. When "related" + is given for the protocol, the remainder of the columns should +be left blank.
          • +
        • DEST PORT(S) - Port or port range (<low + port>:<high port>) being connected to. May only be specified + if the protocol is tcp, udp or icmp. For icmp, this column's +contents are interpreted as an icmp type. If you don't want to specify + DEST PORT(S) but need to include information in one of the columns +to the right, enter "-" in this column. You may give a list of ports +and/or port ranges separated by commas. Port numbers may be either integers + or service names from /etc/services.
          • +
        • SOURCE PORTS(S) - May be used to restrict + the rule to a particular client port or port range (a port range +is specified as <low port number>:<high port number>). +If you don't want to restrict client ports but want to specify something + in the next column, enter "-" in this column. If you wish to specify + a list of port number or ranges, separate the list elements with +commas (with no embedded white space). Port numbers may be either +integers or service names from /etc/services.
          • +
        • ORIGINAL DEST - This column may only be non-empty + if the ACTION is DNAT or REDIRECT.
          +
          + If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column + is left empty, any connection request arriving at the firewall from + the SOURCE that matches the rule will be forwarded or redirected. +This works fine for connection requests arriving from the internet +where the firewall has only a single external IP address. When the +firewall has multiple external IP addresses or when the SOURCE is other +than the internet, there will usually be a desire for the rule to only +apply to those connection requests directed to a particular IP address +(see Example 2 below for another usage). That IP address (or a comma-separated list of such addresses) is specified in the ORIGINAL DEST column.
          -
          - The IP address may be optionally followed by ":" and a second - IP address. This latter address, if present, is used as the source - address for packets forwarded to the server (This is called "Source NAT" -or SNAT).
          -
          - + The IP address may be optionally followed by ":" and a + second IP address. This latter address, if present, is used as the source + address for packets forwarded to the server (This is called "Source +NAT" or SNAT).
          +
          + Note:  When using SNAT, it is a good idea to qualify the source with an IP address or subnet. Otherwise, it is likely that SNAT will occur on connections other than those described in the rule. The reason for this is that SNAT occurs in the Netfilter POSTROUTING hook where it is not possible to restrict the scope of a rule by incoming interface.
          -
          -           Example: DNAT     loc:192.168.1.0/24    loc:192.168.1.3    - tcp    www    -    206.124.146.179:192.168.1.3
          -
          -           If SNAT is not used (no ":" and second IP address), -the original source address is used. If you want any destination -address to match the rule but want to specify SNAT, simply use a colon -followed by the SNAT address.
          • - +
          +           Example: DNAT     loc:192.168.1.0/24    + loc:192.168.1.3    tcp    www    -    206.124.146.179:192.168.1.3
          +
          +           If SNAT is not used (no ":" and second IP address), + the original source address is used. If you want any destination + address to match the rule but want to specify SNAT, simply use a +colon followed by the SNAT address. +
        - +

        Example 1. You wish to forward all - ssh connection requests from the internet to local system 192.168.1.3. 

        - + ssh connection requests from the internet to local system 192.168.1.3. 

        + +
        - + - - - - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDEST PROTODEST
        - PORT(S)        		SOURCE
        - PORT(S)        		ORIGINAL
        - DEST
        DNATnetloc:192.168.1.3tcpssh  
        -
        - -

        Example 2. 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. This example shows yet - another use for the ORIGINAL - DEST column; here, connection - requests that were NOT - - (notice the "!") originally - destined to 206.124.146.177 - are redirected to local - port 3128.

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDEST PROTODEST
        - PORT(S)        		SOURCE
        - PORT(S)        		ORIGINAL
        - DEST
        REDIRECTloc3128tcpwww !206.124.146.177
        ACCEPTfwnettcpwww  
        -
        - - -

        Example 3. You want to run a web server at 155.186.235.222 in -your DMZ and have it accessible remotely and locally. the DMZ is managed - by Proxy ARP or by classical sub-netting.

        - - -
        - - - + - - - - - - - + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + - + +
        ACTIONSOURCEDEST PROTODEST
        - PORT(S)        		SOURCE
        - PORT(S)        		ORIGINAL
        - DEST        		ACTIONSOURCEDEST PROTODEST
        + PORT(S)        		SOURCE
        + PORT(S)        		ORIGINAL
        + DEST
        ACCEPTnetdmz:155.186.235.222tcpwww- 
        ACCEPTlocdmz:155.186.235.222tcpwww  
        DNATnetloc:192.168.1.3tcpssh  
        -
        +
      - + +

      Example 2. 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. This example shows yet + another use for the ORIGINAL + DEST column; here, connection + requests that were NOT + (notice +the "!") originally + destined to 206.124.146.177 are + redirected to local port 3128.

      + + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      REDIRECTloc3128tcpwww !206.124.146.177
      ACCEPTfwnettcpwww  
      +
      + + +

      Example 3. You want to run a web server at 155.186.235.222 in +your DMZ and have it accessible remotely and locally. the DMZ is managed + by Proxy ARP or by classical sub-netting.

      + + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ACCEPTnetdmz:155.186.235.222tcpwww- 
      ACCEPTlocdmz:155.186.235.222tcpwww  
      +
      + +

      Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 and you want - the FTP server to be accessible from the internet in addition to the -local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that since -the server is in the 192.168.2.0/24 subnetwork, we can assume that access - to the server from that subnet will not involve the firewall (but see FAQ 2). Note that unless you - have more than one external - IP address, you can leave + DMZ. Your internet interface address is 155.186.235.151 and you want + the FTP server to be accessible from the internet in addition to the + local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that + since the server is in the 192.168.2.0/24 subnetwork, we can assume +that access to the server from that subnet will not involve the firewall +(but see FAQ 2). Note that unless you + have more than one external + IP address, you can leave the ORIGINAL DEST column blank in the first rule. You cannot @@ -1491,82 +1550,85 @@ leave it blank in the clearly not what you want - .

      + .

      - +
      - + - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - +
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      DNATnetdmz:192.168.2.2tcpftp  
      DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
      DNATnetdmz:192.168.2.2tcpftp  
      DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
      -
      + - +

      If you are running wu-ftpd, you should restrict the range of passive in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions - so I use port range 65500-65535. In /etc/ftpaccess, this entry is appropriate:

      + so I use port range 65500-65535. In /etc/ftpaccess, this entry is +appropriate:

      - +
      - + +

      passive ports  0.0.0.0/0 65500 65534

      -
      + - +

      If you are running pure-ftpd, you would include "-p 65500:65534" on - the pure-ftpd runline.

      + the pure-ftpd runline.

      - +

      The important point here is to ensure that the port range used for FTP - passive connections is unique and will not overlap with any usage on -the firewall system.

      + passive connections is unique and will not overlap with any usage on + the firewall system.

      - +

      Example 5. You wish to allow unlimited DMZ access to the host @@ -1574,97 +1636,101 @@ the firewall system.

      02:00:08:E3:FA:55.

      - +
      - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACCEPTloc:~02-00-08-E3-FA-55dmzall   
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ACCEPTloc:~02-00-08-E3-FA-55dmzall   
      -
      + - Example 6. You wish to -allow access to the SMTP server in your DMZ from all zones.
      -
      + Example 6. You wish + to allow access to the SMTP server in your DMZ from all zones.
      + +
      - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTION
      -       		SOURCE
      -       		DEST
      -       		PROTO
      -       		DEST
      -PORTS(S)
      -       		SOURCE
      -PORT(S)
      -       		ORIGINAL
      -DEST
      -
      ACCEPT
      -       		all
      -       		dmz
      -       		tcp
      -       		25
      -
      -
      -
      ACTION
      +       		SOURCE
      +       		DEST
      +       		PROTO
      +       		DEST
      + PORTS(S)
      +       		SOURCE
      + PORT(S)
      +       		ORIGINAL
      + DEST
      +
      ACCEPT
      +       		all
      +       		dmz
      +       		tcp
      +       		25
      +
      +
      +
      -
      -Note: When 'all' is used as a source or destination, intra-zone traffic is -not affected. In this example, if there were two DMZ interfaces then the -above rule would NOT enable SMTP traffic between hosts on these interfaces.
      +
      + Note: When 'all' is used as a source or destination, intra-zone traffic + is not affected. In this example, if there were two DMZ interfaces then the + above rule would NOT enable SMTP traffic between hosts on these interfaces.
      +

      Look here for information on other services.

      - +

      /etc/shorewall/common

      - +

      Shorewall allows definition of rules that apply between all zones. @@ -1674,163 +1740,167 @@ above rule would NOT enable SMTP traffic between hosts on these interfaces. + than modify + /etc/shorewall/common.def, + you should copy + that file to + /etc/shorewall/common + and modify that + file.

      - +

      The /etc/shorewall/common - file is expected - to contain iptables - commands; rather - than running iptables - directly, you -should run it -indirectly using the - Shorewall function 'run_iptables'. - That way, if iptables - encounters an error, the - firewall will be safely - stopped.

      + file is expected + to contain iptables + commands; rather + than running + iptables directly, + you should run + it indirectly using the + Shorewall function 'run_iptables'. + That way, if iptables + encounters an error, the + firewall will be safely + stopped.

      - +

      /etc/shorewall/masq

      - +

      The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation  (SNAT). There is one entry in -the file for each subnet that you want to masquerade. In order to make -use of this feature, you must have NAT enabled - .

      + and Source Network Address Translation  (SNAT). There is one entry in + the file for each subnet that you want to masquerade. In order to make + use of this feature, you must have NAT enabled + .

      - +

      Columns are:

      - +
        -
      • INTERFACE - The interface that will masquerade the - subnet; this is normally your internet interface. This interface -name can be optionally qualified by adding ":" and a subnet or host -IP. When this qualification is added, only packets addressed to that -host or subnet will be masqueraded.
        • -
      • SUBNET - The subnet that you want to have masqueraded - through the INTERFACE. This may be expressed as a single IP address, - a subnet or an interface name. In the latter instance, the interface - must be configured and started before Shorewall is started as Shorewall - will determine the subnet based on information obtained from the 'ip' - utility.
        -
        - The subnet may be optionally followed by "!' and a comma-separated - list of addresses and/or subnets that are to be excluded from masquerading.
        • -
      • ADDRESS - The source address to be used for outgoing - packets. This column is optional and if left blank, the current primary - IP address of the interface in the first column is used. If you have - a static IP on that interface, listing it here makes processing of output - packets a little less expensive for the firewall.
        • - +
      • INTERFACE - The interface that will masquerade + the subnet; this is normally your internet interface. This interface + name can be optionally qualified by adding ":" and a subnet or host + IP. When this qualification is added, only packets addressed to +that host or subnet will be masqueraded.
        • +
      • SUBNET - The subnet that you want to have masqueraded + through the INTERFACE. This may be expressed as a single IP address, + a subnet or an interface name. In the latter instance, the interface + must be configured and started before Shorewall is started as Shorewall + will determine the subnet based on information obtained from the 'ip' + utility.
        +
        + The subnet may be optionally followed by "!' and a comma-separated + list of addresses and/or subnets that are to be excluded from masquerading.
        • +
      • ADDRESS - The source address to be used for +outgoing packets. This column is optional and if left blank, the current + primary IP address of the interface in the first column is used. If +you have a static IP on that interface, listing it here makes processing +of output packets a little less expensive for the firewall.
        • +
      - +

      Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq - file would look like:    

      + connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like:    

      - +
      - + - - - - - - - - - - - + + + + + + + + + + + + - - - - -
      INTERFACE SUBNETADDRESS
      eth0192.168.9.0/24 
      INTERFACE SUBNETADDRESS
      eth0192.168.9.0/24 
      -
      - - -

      Example 2: You have a number of IPSEC tunnels through ipsec0 - and you want to masquerade traffic from your 192.168.9.0/24 subnet to - the remote subnet 10.1.0.0/16 only.

      - - -
      - - - - - - - - - - - - - - - - - - - - - -
      INTERFACE SUBNETADDRESS
      ipsec0:10.1.0.0/16192.168.9.0/24 
      -
      - - -

      Example 3: You have a DSL line connected on eth0 and a local - network (192.168.10.0/24) - connected to - eth1. You want - all local->net - connections to use - source address - 206.124.146.176.

      - -
      - - - - - - - - - - - - - - - - - -
      INTERFACE SUBNETADDRESS
      eth0192.168.10.0/24206.124.146.176
      -
      - + + + + + + + + +

      Example 2: You have a number of IPSEC tunnels through ipsec0 + and you want to masquerade traffic from your 192.168.9.0/24 subnet + to the remote subnet 10.1.0.0/16 only.

      + + +
      + + + + + + + + + + + + + + + + + + + + + + +
      INTERFACE SUBNETADDRESS
      ipsec0:10.1.0.0/16192.168.9.0/24 
      +
      + + +

      Example 3: You have a DSL line connected on eth0 and a local + network (192.168.10.0/24) + connected +to eth1. You + want all local->net + connections to use + source address + 206.124.146.176.

      + +
      + + + + + + + + + + + + + + + + + + +
      INTERFACE SUBNETADDRESS
      eth0192.168.10.0/24206.124.146.176
      +
      + +

      Example 4: Same as example 3 except that you wish @@ -1840,35 +1910,36 @@ host or subnet will be masqueraded.

      • the SNAT rule.

      - +
      - + - - - - - - - - - - - + + + + + + + + + + + + - - + +
      INTERFACE SUBNETADDRESS
      eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
      INTERFACE SUBNETADDRESS
      eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
      -
      + - +

      /etc/shorewall/proxyarp

      - +

      If you want to use proxy ARP on an entire sub-network, @@ -1877,30 +1948,30 @@ host or subnet will be masqueraded. http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide - to use the - technique described - in that HOWTO, - you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by including -the proxyarp - option in -the interface's - record in - - /etc/shorewall/interfaces. - When using Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp. -

      + If you decide + to use +the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by including + the proxyarp + option in + the interface's + record in + + /etc/shorewall/interfaces. + When using Proxy ARP + sub-netting, you do + NOT include + any entries in + /etc/shorewall/proxyarp. +

      - +

      The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -1908,47 +1979,48 @@ the interface's on a small set of systems since you need one entry - in this file - for each system - using proxy - ARP. Columns are:

      - + in this +file for each + system using proxy + ARP. Columns are:

      +
        -
      • ADDRESS - address of the system.
        • -
      • INTERFACE - the interface that connects to the system. - If the interface is obvious from the subnetting, you may enter "-" - in this column.
        • -
      • EXTERNAL - the external interface that you want -to honor ARP requests for the ADDRESS specified in the first column.
        • -
      • HAVEROUTE - If - you already have - a route through - INTERFACE to - ADDRESS, this - column should - contain - "Yes" - or - "yes". - If you want - Shorewall to add - the route, the - column should - contain - "No" - or - "no".
        • - +
      • ADDRESS - address of the system.
        • +
      • INTERFACE - the interface that connects to the + system. If the interface is obvious from the subnetting, you may + enter "-" in this column.
        • +
      • EXTERNAL - the external interface that you want + to honor ARP requests for the ADDRESS specified in the first column.
        • +
      • HAVEROUTE - If + you already have + a route through + INTERFACE to + ADDRESS, this + column should + contain + "Yes" + or + "yes". + If you want + Shorewall to add + the route, the + column should + contain + "No" + or + "no".
        • +
      - +

      Note: After you have made a change to the /etc/shorewall/proxyarp - file, you may need to flush the ARP cache of all routers on the LAN segment - connected to the interface specified in the EXTERNAL column of the change/added - entry(s). If you are having problems communicating between an individual - host (A) on that segment and a system whose entry has changed, you may - need to flush the ARP cache on host A as well.

      + file, you may need to flush the ARP cache of all routers on the LAN + segment connected to the interface specified in the EXTERNAL column +of the change/added entry(s). If you are having problems communicating + between an individual host (A) on that segment and a system whose entry + has changed, you may need to flush the ARP cache on host A as well.

      - + +

      ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may take a long @@ -1957,95 +2029,95 @@ to delete a stale entry in order to restore a system to working order after changing my proxy ARP settings.

      - +

      Example: You have public IP addresses 155.182.235.0/28. You configure your - firewall as follows:

      - + firewall as follows:

      +
        -
      • eth0 - 155.186.235.1 (internet connection)
        • -
      • eth1 - 192.168.9.0/24 (masqueraded local systems)
        • -
      • eth2 - 192.168.10.1 (interface to your DMZ)
        • - +
      • eth0 - 155.186.235.1 (internet connection)
        • +
      • eth1 - 192.168.9.0/24 (masqueraded local systems)
        • +
      • eth2 - 192.168.10.1 (interface to your DMZ)
        • +
      - +

      In your DMZ, you want to install a Web/FTP server with public address - 155.186.235.4. On the Web server, you subnet just like the firewall's - eth0 and you configure 155.186.235.1 as the default gateway. In your - /etc/shorewall/proxyarp file, you will have:

      + 155.186.235.4. On the Web server, you subnet just like the firewall's + eth0 and you configure 155.186.235.1 as the default gateway. In your + /etc/shorewall/proxyarp file, you will have:

      - +
      - + - + - - - - - - - - - - - - + + + + + + + + + + + + - + - +
      ADDRESS INTERFACE EXTERNALHAVEROUTE
      155.186.235.4eth2eth0No
      ADDRESS INTERFACE EXTERNALHAVEROUTE
      155.186.235.4eth2eth0No
      -
      - + +

      Note: You may want to configure the servers in your DMZ with a subnet - that is smaller than the subnet of your internet interface. See the -Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) - for details. In this case you will want to place "Yes" in the HAVEROUTE - column.

      - + for details. In this case you will want to place "Yes" in the HAVEROUTE + column.

      +

      To learn how I use Proxy ARP in my DMZ, see my configuration files.

      - +

      Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. - If you start or restart Shorewall with an IPSEC tunnel active, the proxied - IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) - rather than to the interface that you specify in the INTERFACE column -of /etc/shorewall/proxyarp. I haven't had the time to debug this problem -so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

      - + If you start or restart Shorewall with an IPSEC tunnel active, the proxied + IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) + rather than to the interface that you specify in the INTERFACE column + of /etc/shorewall/proxyarp. I haven't had the time to debug this problem + so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

      +

      You might be able to work around this problem using the following - (I haven't tried it):

      - + (I haven't tried it):

      +

      In /etc/shorewall/init, include:

      - +

           qt service ipsec stop

      - +

      In /etc/shorewall/start, include:

      - +

          qt service ipsec start

      - +

      /etc/shorewall/nat

      - +

      The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that you wish to -define. In order to make use of this feature, you must have NAT enabled .

      - +

      IMPORTANT: If @@ -2057,605 +2129,642 @@ define. In order to make use of this feature, you must have - rules file. - Also, in most - cases - - Proxy ARP - provides a - superior solution - to static NAT - because the - internal systems - are accessed using - the same IP - address internally - and externally.

      + with simple + entries in + the + rules file. + Also, in most + cases + + Proxy ARP + provides a + superior solution + to static NAT + because the + internal systems + are accessed using + the same IP + address internally + and externally.

      - +

      Columns in an entry are:

      - +
        -
      • EXTERNAL - External IP address - This should -NOT be the primary IP address of the interface named in the next column.
        • -
      • INTERFACE - Interface that you want the EXTERNAL -IP address to appear on.
        • -
      • INTERNAL - Internal IP address.
        • -
      • ALL - INTERFACES - - If Yes - or yes (or - left - empty), - NAT will - be - effective - from all - hosts. - If - No or no - then NAT - will be - effective - only - through - the - interface - named in - the - INTERFACE - column. Note: - If two or more NATed systems are connected to the same firewall interface - and you want them to be able to communicate using their EXTERNAL IP - addresses, then you will want to specify the multi option in the - /etc/shorewall/interface entry for that interface.
        • -
      • LOCAL - If Yes or yes and the ALL INTERFACES column -contains Yes or yes, NAT will be effective from the firewall system. - Note: For this to work, you must be running kernel 2.4.19 -or later and iptables 1.2.6a or later and you must have enabled  CONFIG_IP_NF_NAT_LOCAL - in your kernel.
        • - +
      • EXTERNAL - External IP address - This should + NOT be the primary IP address of the interface named in the next +column.
        • +
      • INTERFACE - Interface that you want the EXTERNAL + IP address to appear on.
        • +
      • INTERNAL - Internal IP address.
        • +
      • ALL + INTERFACES + - If Yes + or yes (or + left + empty), + NAT will + be + effective + from +all + hosts. If + No or no + then NAT + will be + effective + only + through + the + interface + named in + the + INTERFACE + column. + Note: If two or more NATed systems are connected to the +same firewall interface and you want them to be able to communicate +using their EXTERNAL IP addresses, then you will want to specify the + multi option in the /etc/shorewall/interface +entry for that interface.
        • +
      • LOCAL - If Yes or yes and the ALL INTERFACES column + contains Yes or yes, NAT will be effective from the firewall system. + Note: For this to work, you must be running kernel +2.4.19 or later and iptables 1.2.6a or later and you must have enabled  + CONFIG_IP_NF_NAT_LOCAL in your kernel.
        • +
      - +

      Look here for additional information and an example. -

      +

      - +

      /etc/shorewall/tunnels

      - +

      The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP - and PPTP tunnels with end-points on your firewall. To use ipsec, you must - install version 1.9, 1.91 or the current FreeS/WAN development snapshot. 

      - +

      Note: For kernels 2.4.4 and above, you will need to use version 1.91 - or a development snapshot as patching with version 1.9 results in kernel - compilation errors.

      + or a development snapshot as patching with version 1.9 results in +kernel compilation errors.

      - +

      Instructions for setting up IPSEC tunnels may - be found here, instructions for IPIP and - GRE tunnels are here  and instructions -for PPTP tunnels are here.

      - -

      /etc/shorewall/shorewall.conf

      + be found here, instructions for IPIP +and GRE tunnels are here  and instructions + for PPTP tunnels are here.

      + +

      /etc/shorewall/shorewall.conf

      - +

      This file is used to set the following firewall parameters:

      - +
        -
      • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
        -Determines the disposition of TCP packets that fail the checks enabled by -the tcpflags interface option and must have -a value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP -(ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") -then TCP_FLAGS_DISPOSITION=DROP is assumed.
        • -
      • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
        -Determines the syslogd log level for logging packets that fail the checks -enabled by the tcpflags interface option.The value -must be a valid syslogd log level. If you don't want to log these packets, - set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
        +
      • MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
        +If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes +to cause the marking specified in the tcrules file to occur in that chain +rather than in the PREROUTING chain. This permits you to mark inbound traffic +based on its destination address when SNAT or Masquerading are in use. To +determine if your kernel has a FORWARD chain in the mangle table, use the +"/sbin/shorewall show mangle" command; if a FORWARD chain is displayed then +your kernel will support this option. If this option is not specified or +if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No +is assumed.
        • -
      • MACLIST_DISPOSITION - Added in Version 1.3.10
        - Determines the disposition of connections requests that fail RFC1918_LOG_LEVEL - Added at version 1.3.12
        + This parameter determines the level at which packets logged under the         'norfc1918' +mechanism  are logged. The value must be a valid syslog +level and if no level is given, then info is assumed. Prior to Shorewall +version 1.3.12, these packets are always logged at the info level.
        • +
      • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
        +Determines the disposition of TCP packets that fail the checks enabled by + the tcpflags interface option and must have + a value of ACCEPT (accept the packet), REJECT (send an RST response) or +DROP (ignore the packet). If not set or if set to the empty value (e.g., +TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
        • +
      • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
        + Determines the syslog +level for logging packets that fail the checks enabled by the tcpflags interface option.The value must be a valid +syslogd log level. If you don't want to log these packets, set to the empty +value (e.g., TCP_FLAGS_LOG_LEVEL="").
        +
        • +
      • MACLIST_DISPOSITION - Added in Version 1.3.10
        + Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT (accept the connection request anyway), REJECT (reject the connection request) or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
        • -
      • MACLIST_LOG_LEVEL - Added in Version 1.3.10
        - Determines the syslogd log level for logging connection requests that -fail MAC Verification. The value must -be a valid syslogd log level. If you don't want to log these connection -requests, set to the empty value (e.g., MACLIST_LOG_LEVEL="").
        -
        • -
      • NEWNOTSYN - Added in Version 1.3.8
        - When set to "Yes" or "yes", Shorewall will filter TCP packets that -are not part of an established connention and that are not SYN packets -(SYN flag on - ACK flag off). If set to "No", Shorewall will silently drop -such packets. If not set or set to the empty value (e.g., "NEWNOTSYN="), -NEWNOTSYN=No is assumed.
        -
        - If you have a HA setup with failover to another firewall, you should - have NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes - if you have asymmetric routing.
        -
        • -
      • FORWARDPING - Added in Version 1.3.7
        - When set to "Yes" or "yes", ICMP echo-request (ping) packets from - interfaces that specify "filterping" are ACCEPTed by the firewall. -When set to "No" or "no", such ping requests are silently dropped unless - they are handled by an explicit entry in the rules -file. If not specified, "No" is assumed.
        • -
      • LOGNEWNOTSYN - Added in Version 1.3.6
        - Beginning with version 1.3.6, Shorewall drops non-SYN TCP packets - that are not part of an existing connection. If you would like to -log these packets, set LOGNEWNOTSYN to the syslog level at which you -want the packets logged. Example: LOGNEWNOTSYN=debug|
        -
        - Note: Packets logged under this option are usually the -result of broken remote IP stacks rather than the result of any sort -of attempt to breach your firewall.
        -  
        • -
      • MERGE_HOSTS - Added in Version 1.3.5
        - Prior to 1.3.5, when the /etc/shorewall/hosts - file included an entry for a zone then the entire zone had to be defined - in the /etc/shorewall/hosts file and any associations between the zone - and interfaces in the /etc/shorewall/interfaces - file were ignored. This behavior is preserved if MERGE_HOSTS=No or -if MERGE_HOSTS is not set or is set to the empty value.
        -
        - Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone assignments - in the /etc/shorewall/hosts file are ADDED to those in the /etc/shorewall/interfaces - file.
        -
        - Example:
        -
        - Interfaces File:
        -   +
      • MACLIST_LOG_LEVEL - Added in Version 1.3.10
        + Determines the syslog +level for logging connection requests that fail MAC Verification. The value must be a valid +syslogd log level. If you don't want to log these connection requests, set +to the empty value (e.g., MACLIST_LOG_LEVEL="").
        +
        • +
      • NEWNOTSYN - Added in Version 1.3.8
        + When set to "Yes" or "yes", Shorewall will filter TCP packets that + are not part of an established connention and that are not SYN packets + (SYN flag on - ACK flag off). If set to "No", Shorewall will silently +drop such packets. If not set or set to the empty value (e.g., "NEWNOTSYN="), + NEWNOTSYN=No is assumed.
        +
        + If you have a HA setup with failover to another firewall, you should + have NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes + if you have asymmetric routing.
        +
        • +
      • FORWARDPING - Added in Version 1.3.7
        + When set to "Yes" or "yes", ICMP echo-request (ping) packets + from interfaces that specify "filterping" are ACCEPTed by the firewall. + When set to "No" or "no", such ping requests are silently dropped +unless they are handled by an explicit entry in the rules file. If not specified, "No" is assumed.
        • +
      • LOGNEWNOTSYN - Added in Version 1.3.6
        + Beginning with version 1.3.6, Shorewall drops non-SYN TCP +packets that are not part of an existing connection. If you would +like to log these packets, set LOGNEWNOTSYN to the syslog +level at which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
        +
        + Note: Packets logged under this option are usually +the result of broken remote IP stacks rather than the result of +any sort of attempt to breach your firewall.
        +  
        • +
      • MERGE_HOSTS - Added in Version 1.3.5
        + Prior to 1.3.5, when the /etc/shorewall/hosts + file included an entry for a zone then the entire zone had to be +defined in the /etc/shorewall/hosts file and any associations between +the zone and interfaces in the /etc/shorewall/interfaces + file were ignored. This behavior is preserved if MERGE_HOSTS=No or + if MERGE_HOSTS is not set or is set to the empty value.
        +
        + Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone + assignments in the /etc/shorewall/hosts file are ADDED to those +in the /etc/shorewall/interfaces file.
        +
        + Example:
        +
        + Interfaces File:
        +   - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
        ZONEHOSTSBROADCASTOPTIONS
        loceth1-dhcp
        -ppp+  
        ZONEHOSTSBROADCASTOPTIONS
        loceth1-dhcp
        -ppp+  
        - +


        - Hosts File:
        -  

        - + Hosts File:
        +  

        + - - - - - - - - - - - + + + + + + + + + + + +
        ZONEHOSTS
        locppp+:192.168.12.0/24
        ZONEHOSTS
        locppp+:192.168.12.0/24
        - +


        -         With MERGE_HOSTS=No, the loc zone consists of only - ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 - and ppp+:192.168.12.0/24.
        -  

        -
        • -
      • DETECT_DNAT_ADDRS - Added in Version 1.3.4
        - If set to "Yes" or "yes", Shorewall will detect the IP address(es) -of the interface(es) to the source zone and will include this (these) address(es) - in DNAT rules as the original destination IP address. If set to "No" or - "no", Shorewall will not detect this (these) address(es) and any destination - IP address will match the DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" - is assumed.
        -
        • -
      • MULTIPORT - Added in Version 1.3.2
        - If set to "Yes" or "yes", Shorewall will use the Netfilter multiport - facility. In order to use this facility, your kernel must have multiport - support (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, -Shorewall will generate a single rule from each record in the /etc/shorewall/rules - file that meets these criteria:
        -   +         With MERGE_HOSTS=No, the loc zone consists of + only ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 + and ppp+:192.168.12.0/24.
        +  

        +
        • +
      • DETECT_DNAT_ADDRS - Added in Version 1.3.4
        + If set to "Yes" or "yes", Shorewall will detect the IP address(es) + of the interface(es) to the source zone and will include this (these) +address(es) in DNAT rules as the original destination IP address. If set +to "No" or "no", Shorewall will not detect this (these) address(es) and +any destination IP address will match the DNAT rule. If not specified or +empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
        +
        • +
      • MULTIPORT - Added in Version 1.3.2
        + If set to "Yes" or "yes", Shorewall will use the Netfilter +multiport facility. In order to use this facility, your kernel must +have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). When this +support is used, Shorewall will generate a single rule from each record +in the /etc/shorewall/rules file that meets these criteria:
        +  
          -
        • No port range(s) specified
          • -
        • Specifies 15 or fewer ports
          • - +
        • No port range(s) specified
          • +
        • Specifies 15 or fewer ports
          • +
        - +

        Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range.

        -
        • -
      • NAT_BEFORE_RULES
        - If set to "No" or "no", port forwarding rules can override the -contents of the /etc/shorewall/nat file. If set -to "Yes" or "yes", port forwarding rules cannot override static NAT. -If not set or set to an empty value, "Yes" is assumed.
        • -
      • FW
        + rule for each listed port or port range.

        +
        • +
      • NAT_BEFORE_RULES
        + If set to "No" or "no", port forwarding rules can override +the contents of the /etc/shorewall/nat file. If +set to "Yes" or "yes", port forwarding rules cannot override static +NAT. If not set or set to an empty value, "Yes" is assumed.
        • +
      • FW
        -         This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an - empty string, - the value - "fw" - is assumed.
        • -
      • SUBSYSLOCK
        - This parameter should be set to the name of a file that -the firewall should create if it starts successfully and remove -when it stops. Creating and removing this file allows Shorewall -to work with your distribution's initscripts. For RedHat, this -should be set to /var/lock/subsys/shorewall. For Debian, the value -is /var/state/shorewall and in LEAF it is - /var/run/shorwall. - Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
        • -
      • STATEDIR
        - This parameter specifies the name of a directory where Shorewall - stores state information. If the directory doesn't exist when Shorewall - starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.
        -
        - NOTE: If you change the STATEDIR variable while the firewall - is running, create the new directory if necessary then copy the contents - of the old directory to the new directory.
        • -
      • ALLOWRELATED
        - This parameter must be assigned the value "Yes" ("yes") - or "No" ("no") and specifies whether Shorewall allows connection - requests that are related to an already allowed connection. If you - say "No" ("no"), you can still override this setting by including -"related" rules in /etc/shorewall/rules ("related" given as the protocol). -If you specify ALLOWRELATED=No, you will need to include rules in - /etc/shorewall/icmpdef +         This + parameter + specifies the + name of the + firewall zone. + If not set or + if set to an + empty string, + the value + "fw" + is assumed.
        • +
      • SUBSYSLOCK
        + This parameter should be set to the name of a file that + the firewall should create if it starts successfully and remove + when it stops. Creating and removing this file allows Shorewall + to work with your distribution's initscripts. For RedHat, this + should be set to /var/lock/subsys/shorewall. For Debian, the value + is /var/state/shorewall and in LEAF it is + /var/run/shorwall. + Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
        • +
      • STATEDIR
        + This parameter specifies the name of a directory where + Shorewall stores state information. If the directory doesn't +exist when Shorewall starts, it will create the directory. Example: +STATEDIR=/tmp/shorewall.
        +
        + NOTE: If you change the STATEDIR variable while the +firewall is running, create the new directory if necessary then copy +the contents of the old directory to the new directory.
        • +
      • ALLOWRELATED
        + This parameter must be assigned the value "Yes" + ("yes") or "No" ("no") and specifies whether Shorewall allows + connection requests that are related to an already allowed connection. + If you say "No" ("no"), you can still override this setting by +including "related" rules in /etc/shorewall/rules ("related" given +as the protocol). If you specify ALLOWRELATED=No, you will need to +include rules in /etc/shorewall/icmpdef to handle common ICMP packet types.
        • -
      • MODULESDIR
        - This parameter specifies the directory where your kernel -netfilter modules may be found. If you leave the variable empty, -Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
        • -
      • LOGRATE and LOGBURST
        - These parameters set the match rate and initial burst size - for logged packets. Please see the iptables man page for a description - of the behavior of these parameters (the iptables option --limit is - set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters - are set empty, no rate-limiting will occur.
        -
        - Example:
        -     LOGRATE=10/minute
        -     LOGBURST=5
        -  
        • -
      • LOGFILE
        +
      • MODULESDIR
        + This parameter specifies the directory where your kernel + netfilter modules may be found. If you leave the variable empty, + Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
        • +
      • LOGRATE and LOGBURST
        + These parameters set the match rate and initial burst + size for logged packets. Please see the iptables man page for a +description of the behavior of these parameters (the iptables option +--limit is set by LOGRATE and --limit-burst is set by LOGBURST). If +both parameters are set empty, no rate-limiting will occur.
        +
        + Example:
        +     LOGRATE=10/minute
        +     LOGBURST=5
        +  
        • +
      • LOGFILE
        - This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing the - "show - log", - "monitor", - "status" - and - "hits" - commands. If - not assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
        • -
      • NAT_ENABLED
        - This parameter determines whether Shorewall supports NAT -operations. NAT operations include:
        -
        -     Static NAT
        -     Port Forwarding
        -     Port Redirection
        -     Masquerading
        -
        - If the parameter has no value or has a value of "Yes" or - "yes" then NAT is enabled. If the parameter has a value of "no" - or "No" then NAT is disabled.
        + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages when + processing the + "show + log", + "monitor", + "status" + and + "hits" + commands. If + not assigned + or if +assigned + an empty + value, + /var/log/messages + is assumed.
        • +
      • NAT_ENABLED
        + This parameter determines whether Shorewall supports +NAT operations. NAT operations include:
        +
        +     Static NAT
        +     Port Forwarding
        +     Port Redirection
        +     Masquerading
        +
        + If the parameter has no value or has a value of "Yes" + or "yes" then NAT is enabled. If the parameter has a value of + "no" or "No" then NAT is disabled.
        +
        • +
      • MANGLE_ENABLED
        + This parameter determines if packet mangling is enabled. + If the parameter has no value or has a value of "Yes" or "yes" + than packet mangling is enabled. If the parameter has a value of +"no" or "No" then packet mangling is disabled. If packet mangling is + disabled, the /etc/shorewall/tos file is ignored.
        +
        • +
      • IP_FORWARDING
        + This parameter determines whether Shorewall enables +or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). + Possible values are:
        +
        +     On or on - packet forwarding will be enabled.
        +     Off or off - packet forwarding will be disabled.
        +     Keep or keep - Shorewall will neither enable nor + disable packet forwarding.
        +
        + If this variable is not set or is given an empty value + (IP_FORWARD="") then IP_FORWARD=On is assumed.
        • -
      • MANGLE_ENABLED
        - This parameter determines if packet mangling is enabled. -If the parameter has no value or has a value of "Yes" or "yes" than - packet mangling is enabled. If the parameter has a value of "no" - or "No" then packet mangling is disabled. If packet mangling is - disabled, the /etc/shorewall/tos file is ignored.
        -
        • -
      • IP_FORWARDING
        - This parameter determines whether Shorewall enables or disables - IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible - values are:
        -
        -     On or on - packet forwarding will be enabled.
        -     Off or off - packet forwarding will be disabled.
        -     Keep or keep - Shorewall will neither enable nor - disable packet forwarding.
        -
        - If this variable is not set or is given an empty value (IP_FORWARD="") - then IP_FORWARD=On is assumed.
        -
        • -
      • ADD_IP_ALIASES
        - This parameter determines whether Shorewall automatically -adds the - external address(es) in /etc/shorewall/nat - . If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these aliases. If it is set to "No" or "no", you must - add these aliases yourself using your distribution's network configuration - tools.
        -
        - If this variable is not set or is given an empty value (ADD_IP_ALIASES="") - then ADD_IP_ALIASES=Yes is assumed.
        • -
      • ADD_SNAT_ALIASES
        - This parameter determines whether Shorewall automatically adds -the SNAT ADDRESS in /etc/shorewall/masq. - If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these addresses. If it is set to "No" or "no", you must add these - addresses yourself using your distribution's network configuration tools.
        -
        - If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="") - then ADD_SNAT_ALIASES=No is assumed.
        -
        • -
      • LOGUNCLEAN
        +
      • ADD_IP_ALIASES
        + This parameter determines whether Shorewall automatically + adds the + external address(es) in /etc/shorewall/nat + . If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these aliases. If it is set to "No" or "no", you must + add these aliases yourself using your distribution's network configuration + tools.
        +
        + If this variable is not set or is given an empty value + (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
        • +
      • ADD_SNAT_ALIASES
        + This parameter determines whether Shorewall automatically +adds the SNAT ADDRESS in /etc/shorewall/masq. + If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these addresses. If it is set to "No" or "no", you must add these + addresses yourself using your distribution's network configuration + tools.
        +
        + If this variable is not set or is given an empty value + (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
        +
        • +
      • LOGUNCLEAN
        - This parameter - determines the - logging level - of - mangled/invalid - packets - controlled by - the 'dropunclean - and logunclean' - interface - options. - If LOGUNCLEAN - is empty - (LOGUNCLEAN=) - then -packets - selected by - 'dropclean' are - dropped - silently - ('logunclean' - packets are - logged under - the 'info' log - level). - Otherwise, - these packets - are logged -at the -specified - level - (Example: - LOGUNCLEAN=debug).
        • -
      • BLACKLIST_DISPOSITION
        + This parameter + determines the + logging level + of + mangled/invalid + packets + controlled by + the 'dropunclean + and +logunclean' + interface + options. If + LOGUNCLEAN is + empty + (LOGUNCLEAN=) + then packets + selected + by 'dropclean' + are dropped + silently + ('logunclean' + packets + are logged + under + the 'info' log + level). + Otherwise, + these packets + are logged at + the specified + level + (Example: + LOGUNCLEAN=debug).
        • +
      • BLACKLIST_DISPOSITION
        - This parameter - determines the - disposition of - packets from - blacklisted - hosts. It may - have the value - DROP if the - packets are to - be dropped - or REJECT - if the - packets are to - be replied - with an ICMP - port - unreachable - reply or a TCP - RST (tcp - only). If you - do not assign - a value or if - you assign an - empty value - then DROP -is assumed.
        • -
      • BLACKLIST_LOGLEVEL
        + This parameter + determines the + disposition of + packets from + blacklisted + hosts. It may + have the value + DROP if the + packets are + to be +dropped or + REJECT if the + packets are to + be replied + with an ICMP + port + unreachable + reply or a TCP + RST (tcp + only). If you + do not assign + a value or if + you assign +an empty +value then +DROP is +assumed.
        • +
      • BLACKLIST_LOGLEVEL
        - This paremter - determines if - packets from - blacklisted - hosts are - logged and it - determines the - syslog level - that they are - to be logged - at. Its -value is -a syslog - log level - (Example: - BLACKLIST_LOGLEVEL=debug). - If you do not - assign a value - or if you - assign an - empty value - then packets - from - blacklisted - hosts are -not logged.
        • -
      • CLAMPMSS
        + This paremter + determines if + packets from + blacklisted + hosts are + logged and it + determines the + syslog level + that they are + to be logged + at. Its + value + is a syslog +level + (Example: + BLACKLIST_LOGLEVEL=debug). + If you do not + assign a value + or if you + assign an + empty value + then packets + from + blacklisted + hosts +are not + logged.
        • +
      • CLAMPMSS
        - This parameter - enables the - TCP Clamp MSS - to PMTU - feature of - Netfilter and - is usually - required when - your internet - connection is - through PPPoE - or PPTP. -If set to - "Yes" - or - "yes", - the feature - is enabled. - If left - blank or - set to - "No" - or -"no", - the feature is - not enabled. - Note: This - option - requires - CONFIG_IP_NF_TARGET_TCPMSS - in - your kernel.
        • -
      • ROUTE_FILTER
        - If this parameter is given the value "Yes" or "yes" then route -filtering (anti-spoofing) is enabled on all network interfaces. -The default value is "no".
        • - + This parameter + enables the + TCP Clamp MSS + to PMTU + feature of + Netfilter and + is usually + required when + your internet + connection is + through +PPPoE + or PPTP. If + set to + "Yes" + or + "yes", + the feature is + enabled. If + left blank or + set to + "No" + or + "no", + the feature is + not enabled. + Note: This + option + requires + CONFIG_IP_NF_TARGET_TCPMSS + in + your kernel. +
      • ROUTE_FILTER
        + If this parameter is given the value "Yes" or "yes" then route + filtering (anti-spoofing) is enabled on all network interfaces. + The default value is "no".
        • +
      - +

      /etc/shorewall/modules Configuration

      - +

      The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall will - source this file during start/restart provided that it exists and that - the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).

      - +

      The file that is released with Shorewall calls the Shorewall function - "loadmodule" for the set of modules that I load.

      + "loadmodule" for the set of modules that I load.

      - +

      The loadmodule function is called as follows:

      - +
      - +

      loadmodule <modulename> [ <module parameters> ]

      -
      + - + +

      where

      - + +
      - +

      <modulename>                

      - +
      - +

      is the name of the modules without the trailing ".o" (example ip_conntrack).

      -
      +
      - +

      <module parameters>

      - +
      - +

      Optional parameters to the insmod utility.

      -
      - + + - +

      The function determines if the module named by <modulename> - is already loaded and if not then the function determines if the - ".o" file corresponding to the module exists in the moduledirectory; - if so, then the following command is executed:

      + is already loaded and if not then the function determines if + the ".o" file corresponding to the module exists in the moduledirectory; + if so, then the following command is executed:

      - +
      - +

      insmod moduledirectory/<modulename>.o <module - parameters>

      -
      + parameters>

      + - +

      If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports compressed @@ -2663,223 +2772,225 @@ it does, the function assumes that the running configuration supports compress - +

      - +

      insmod moduledirectory/<modulename>.o.gz <module - parameters>

      -
      + parameters>

      + - +

      /etc/shorewall/tos Configuration

      - +

      The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, protocol, - source port and destination port. In order for this file to be processed - by Shorewall, you must have mangle support -enabled .

      + in packet headers based on packet source, packet destination, protocol, + source port and destination port. In order for this file to be processed + by Shorewall, you must have mangle support + enabled .

      - +

      Entries in the file have the following columns:

      - +
        -
      • SOURCE -- The source zone. May be qualified by following - the zone name with a colon (":") and either an IP address, an IP -subnet, a MAC address in Shorewall Format or the - name of an interface. This column may also contain the name of - the firewall - zone to indicate packets originating on the -firewall itself or "all" to indicate any source.
        • -
      • DEST -- The destination zone. May be qualified by - following the zone name with a colon (":") and either an IP address - or an IP subnet. Because packets are marked prior to routing, you - may not specify the name of an interface. This column may also +
      • SOURCE -- The source zone. May be qualified +by following the zone name with a colon (":") and either an IP +address, an IP subnet, a MAC address in Shorewall +Format or the name of an interface. This column may also contain +the name of + the firewall + zone to indicate packets originating +on the firewall itself or "all" to indicate any source.
        • +
      • DEST -- The destination zone. May be qualified + by following the zone name with a colon (":") and either an IP address + or an IP subnet. Because packets are marked prior to routing, you + may not specify the name of an interface. This column may also contain  "all" to indicate any destination.
        • -
      • PROTOCOL -- The name of a protocol in /etc/protocols - or the protocol's number.
        • -
      • SOURCE PORT(S) -- The source port or a port range. - For all ports, place a hyphen ("-") in this column.
        • -
      • DEST PORT(S)  -- The destination port or a port -range. To indicate all ports, place a hyphen ("-") in this column.
        • -
      • TOS -- The type of service. Must be one of the following:
        • - +
      • PROTOCOL -- The name of a protocol in /etc/protocols + or the protocol's number.
        • +
      • SOURCE PORT(S) -- The source port or a port +range. For all ports, place a hyphen ("-") in this column.
        • +
      • DEST PORT(S)  -- The destination port or a port + range. To indicate all ports, place a hyphen ("-") in this column.
        • +
      • TOS -- The type of service. Must be one of the + following:
        • +
      - +
      - +
      - +

      Minimize-Delay (16)
      - Maximize-Throughput (8)
      - Maximize-Reliability (4)
      - Minimize-Cost (2)
      - Normal-Service (0)

      -
      -
      + Maximize-Throughput (8)
      + Maximize-Reliability (4)
      + Minimize-Cost (2)
      + Normal-Service (0)

      + + - +

      The /etc/shorewall/tos file that is included with Shorewall contains - the following entries.

      + the following entries.

      - -
      + +
      - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
      SOURCEDESTPROTOCOLSOURCE
      - PORT(S)      		DEST PORT(S)TOS
      allalltcp-ssh16
      allalltcpssh-16
      allalltcp-ftp16
      allalltcpftp-16
      allalltcp-ftp-data8
      allalltcpftp-data-8
      SOURCEDESTPROTOCOLSOURCE
      + PORT(S)      		DEST PORT(S)TOS
      allalltcp-ssh16
      allalltcpssh-16
      allalltcp-ftp16
      allalltcpftp-16
      allalltcp-ftp-data8
      allalltcpftp-data-8
      -
      +
      - +

      WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file.

      + adding the ESP and AH protocols to the /etc/shorewall/tos file.

      - +

      /etc/shorewall/blacklist

      - +

      Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall - Format - or - subnet - address. - Example:

      + an + IP + address, a MAC address in Shorewall Format + or + subnet + address. - + Example:

      + + 
            130.252.100.69
            206.124.146.0/24
      - +

      Packets from hosts listed in - the - blacklist - file - will - be + the + blacklist + file + will + be -disposed - of - according - to - the - value + disposed + of + according + to + the + value - assigned - to - the BLACKLIST_DISPOSITION + assigned + to + the BLACKLIST_DISPOSITION - and BLACKLIST_LOGLEVEL variables - in + and BLACKLIST_LOGLEVEL variables + in - /etc/shorewall/shorewall.conf. - Only - packets + /etc/shorewall/shorewall.conf. + Only + packets - arriving - on - interfaces - that - have - the + arriving + on + interfaces + that + have + the 'blacklist' option @@ -2892,174 +3003,170 @@ disposed the blacklist. The black list is designed to prevent listed -hosts/subnets from accessing services on your network.
      -

      - + hosts/subnets from accessing services on your network.
      +

      +

      Beginning with Shorewall 1.3.8, the blacklist file has three columns:
      -

      - +

      +
        -
      • ADDRESS/SUBNET - As described above.
        • -
      • PROTOCOL - Optional. If specified, only packets specifying - this protocol will be blocked.
        • -
      • PORTS - Optional; may only be given if PROTOCOL is tcp, - udp or icmp. Expressed as a comma-separated list of port numbers or service - names (from /etc/services). If present, only packets destined for the specified - protocol and one of the listed ports are blocked. When the PROTOCOL is -icmp, the PORTS column contains a comma-separated list of ICMP type numbers -or names (see "iptables -h icmp").
        -
        • - +
      • ADDRESS/SUBNET - As described above.
        • +
      • PROTOCOL - Optional. If specified, only packets specifying + this protocol will be blocked.
        • +
      • PORTS - Optional; may only be given if PROTOCOL is +tcp, udp or icmp. Expressed as a comma-separated list of port numbers +or service names (from /etc/services). If present, only packets destined +for the specified protocol and one of the listed ports are blocked. When +the PROTOCOL is icmp, the PORTS column contains a comma-separated list +of ICMP type numbers or names (see "iptables -h icmp").
        +
        • +
      - +

      Shorewall also has a dynamic blacklist - capability.

      + capability.

      - +

      IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, I suggest that - you install and configure Squid (http://www.squid-cache.org). -

      + designed to police your users' web browsing -- to do that, I suggest +that you install and configure Squid (http://www.squid-cache.org).

      - +

      /etc/shorewall/rfc1918 (Added in Version 1.3.1)

      - +

      This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:

      + interface option. Columns in the file are:

      - -
        - -
      • SUBNET - The subnet using VLSM notation (e.g., - 192.168.0.0/16).
        • - -
      • TARGET - What to do with packets to/from - the SUBNET: -
          - -
        • RETURN - Process the packet normally thru the - rules and policies.
          • - -
        • DROP - Silently drop the packet.
          • - -
        • logdrop - Log then drop the packet.
          • - -
        - -
        • - -
      - - - - -

      /etc/shorewall/routestopped (Added in Version - 1.3.4)

      - - - - -

      This file defines the hosts that are accessible from the firewall when - the firewall is stopped.  Columns in the file are:

      - - - -
        -
      • INTERFACE - The firewall interface through which - the host(s) comminicate with the firewall.
        • +
      • SUBNET - The subnet using VLSM notation (e.g., + 192.168.0.0/16).
        • -
      • HOST(S) - (Optional) - A comma-separated list -of IP/Subnet addresses. If not supplied or supplied as "-" then 0.0.0.0/0 - is assumed.
        • - +
      • TARGET - What to do with packets to/from + the SUBNET: +
          + +
        • RETURN - Process the packet normally thru + the rules and policies.
          • + +
        • DROP - Silently drop the packet.
          • + +
        • logdrop - Log then drop the packet -- see +the RFC1918_LOG_LEVEL parameter above.
          • + + + +
        + +
        • +
      - + +

      /etc/shorewall/routestopped (Added in Version + 1.3.4)

      + + + + +

      This file defines the hosts that are accessible from the firewall when + the firewall is stopped.  Columns in the file are:

      + + + + +
        + +
      • INTERFACE - The firewall interface through + which the host(s) comminicate with the firewall.
        • + +
      • HOST(S) - (Optional) - A comma-separated +list of IP/Subnet addresses. If not supplied or supplied as "-" then +0.0.0.0/0 is assumed.
        • + +
      + + + +

      Example: When your firewall is stopped, you want firewall accessibility - from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces -through eth1 and your local hosts through eth2.

      + from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces + through eth1 and your local hosts through eth2.

      - +
      - + - - + + - + - + - + - + - + - + - + - + - + - + - + - - + + +
      INTERFACEINTERFACEHOST(S)HOST(S)
      eth2eth2192.168.1.0/24192.168.1.0/24
      eth1eth1--
      -
      + - +

      /etc/shorewall/maclist (Added in Version 1.3.10)

      - This file is described in the MAC Validation - Documentation.
      -
      - -

      Updated 11/24/2002 - Tom Eastep -

      - - - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      - - - - - - -
      + This file is described in the MAC Validation + Documentation.

      -
      -
      -
      -
      + +

      Updated 12/20/2002 - Tom Eastep +

      + + + +

      Copyright + © 2001, 2002 Thomas M. Eastep.
      +

      + + + + +


      diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index 6efbda7b5..10242d846 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -1,893 +1,1016 @@ - + + - + + - + + - + + Shorewall FAQ - + + - + - - - + + - - - + + + + +
      - +
      + +

      Shorewall FAQs

      -
      - -

      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.

      - -

      1a. Ok -- I followed those instructions - but it doesn't work.
      -

      - -

      1b. I'm still having problems with - port forwarding

      - -

      2. I port forward www requests - to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 in my -local network. External clients can browse http://www.mydomain.com -but internal clients can't.

      - -

      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.

      - -

      3. I want to use Netmeeting/MSN - Messenger with Shorewall. What do I do?

      - -

      4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather -than 'blocked'. Why?

      - -

      4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!

      - -

      5. I've installed Shorewall and now - I can't ping through the firewall

      - -

      6. Where are the log messages - written and how do I change the destination?

      - -

      6a. Are there any log parsers - that work with Shorewall?

      - -

      7. When I stop Shorewall using -'shorewall stop', I can't connect to anything. Why doesn't that command - work?

      - -

      8. When I try to start Shorewall - on RedHat 7.x, I get messages about insmod failing -- what's wrong?

      - -

      9. Why can't Shorewall detect - my interfaces properly?

      - -

      10. What distributions does - it work with?

      - -

      11. What features does it -support?

      - + +

      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.

      + +

      1a. Ok -- I followed those instructions + but it doesn't work.
      +

      + +

      1b. I'm still having problems with + port forwarding

      + +

      2. I port forward www requests + to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 +in my local network. External clients can browse http://www.mydomain.com + but internal clients can't.

      + +

      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.

      + +

      3. I want to use Netmeeting/MSN + Messenger with Shorewall. What do I do?

      + +

      4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' +rather than 'blocked'. Why?

      + +

      4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!

      + +

      5. I've installed Shorewall and now + I can't ping through the firewall

      + +

      6. Where are the log messages + written and how do I change the destination?

      + +

      6a. Are there any log parsers + that work with Shorewall?

      + +

      7. When I stop Shorewall using + 'shorewall stop', I can't connect to anything. Why doesn't that command + work?

      + +

      8. When I try to start Shorewall + on RedHat I get messages about insmod failing -- what's +wrong?

      + +

      9. Why can't Shorewall detect + my interfaces properly?

      + +

      10. What distributions does + it work with?

      + +

      11. What features does it + support?

      +

      12. Why isn't there a GUI

      - +

      13. Why do you call it "Shorewall"?

      - -

      14. 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 rfc1918 blocking for my eth0 interface, - it also blocks the cable modems web server.

      - -

      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.

      - -

      15. My local systems can't see - out to the net

      - -

      16. Shorewall is writing log messages - all over my console making it unusable!
      -

      - 17. How do I find out why - this is getting logged?
      -
      - 18. Is there any way to use aliased ip addresses - with Shorewall, and maintain separate rulesets for different IPs?
      + +

      14. 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 rfc1918 blocking for my +eth0 interface, it also blocks the cable modems web server.

      + +

      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.

      + +

      15. My local systems can't see + out to the net

      + +

      16. Shorewall is writing log messages + all over my console making it unusable!
      +

      + 17. How do I find + out why this traffic is getting logged?
      +
      + 18. Is there any way to use aliased + ip addresses with Shorewall, and maintain separate rulesets for + different IPs?
      +
      + 19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?
      +
      + 20. I have just set up a server. Do +I have to change Shorewall to allow access to my server from the internet?

      - 19.       I have added entries to /etc/shorewall/tcrules -but they don't seem to do anything. Why?
      -
      -20. I have just set up a server. -Do I have to change Shorewall to allow access to my server from the internet?
      -       -
      -

      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.

      - +       21. I see these strange log entries +occasionally; what are they?
      +
      + 22. I have some iptables commands that I +want to run when Shorewall starts. Which file do I put them in?
      + +
      +

      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.

      +

      Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format of a port-forwarding -rule to a local system is as follows:

      - -
      + href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding + rule to a local system is as follows:

      + +
      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:<local IP address>[:<local -port>]<protocol><port #>
      -
      -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>
      +
      +
      -
      - -

      So to forward UDP port 7777 to internal system 192.168.1.5, - the rule is:

      - -
      +
      + +

      So to forward UDP port 7777 to internal system 192.168.1.5, + the rule is:

      + +
      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:192.168.1.5udp7777
      -
      -
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:192.168.1.5udp7777
      +
      +
      -
      - -
      -
           DNAT net loc:192.168.1.5 udp 7777
      -
      - -

      If you want to forward requests directed to a particular -address ( <external IP> ) on your firewall to an internal system:

      - -
      +
      + +
      If + you want to forward requests directed to a particular address ( <external + IP> ) on your firewall to an internal system:
      + +
      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:<local IP address>[:<local -port>]<protocol><port #>-<external IP>
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>-<external IP>
      -
      - -

      1a. Ok -- I followed those instructions - but it doesn't work

      - +
      + +

      1a. Ok -- I followed those instructions + but it doesn't work

      +

      Answer: That is usually the result of one of two things:

      - +
        -
      • You are trying to test from inside your firewall (no, -that won't work -- see FAQ #2).
        • -
      • 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).
        • - +
      • You are trying to test from inside your firewall + (no, that won't work -- see FAQ #2).
        • +
      • 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).
        • +
      - -

      1b. I'm still having problems with port - forwarding

      - Answer: To further diagnose this problem:
      - + +

      1b. I'm still having problems with port + forwarding

      + Answer: To further diagnose this problem:
      +
        -
      • As root, type "iptables -t nat -Z". This clears the NetFilter counters - in the nat table.
        • -
      • Try to connect to the redirected port from an external host.
        • -
      • As root type "shorewall show nat"
        • -
      • Locate the appropriate DNAT rule. It will be in a chain called - zone_dnat where zone is the zone that includes the server -('loc' in the above examples).
        • -
      • 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).
        • -
      • If the packet count is zero:
        • - +
      • As root, type "iptables -t nat -Z". This clears the +NetFilter counters in the nat table.
        • +
      • Try to connect to the redirected port from an external + host.
        • +
      • As root type "shorewall show nat"
        • +
      • Locate the appropriate DNAT rule. It will be in a chain + called zone_dnat where zone is the zone that includes + the  ('net' in the above examples).
        • +
      • 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).
        • +
      • If the packet count is zero:
        • +
          -
        • the connection request is not reaching your server (possibly -it is being blocked by your ISP); or
          • -
        • 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
          • -
        • 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.
          -
          • - +
        • the connection request is not reaching your server +(possibly it is being blocked by your ISP); or
          • +
        • 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
          • +
        • 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.
          +
          • +
        - +
      - -

      2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in my local network. External - clients can browse http://www.mydomain.com but internal clients can't.

      - + +

      2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in my local network. + External clients can browse http://www.mydomain.com but internal + clients can't.

      +

      Answer: I have two objections to this setup.

      - +
        -
      • 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 :-)
        • -
      • The accessibility problem is best solved using Bind Version 9 "views" (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.
        • - +
      • 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 :-)
        • +
      • The accessibility problem is best solved using + Bind Version 9 "views" + (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.
        • +
      - -

      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:

      - -

      a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1 (No longer required as of Shorewall version 1.3.9).

      - -
      + +

      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:

      + +

      a) In /etc/shorewall/interfaces, specify "multi" as an option + for eth1 (No longer required as of Shorewall version 1.3.9).

      + +

      b) In /etc/shorewall/rules, add:

      -
      - -
      -
      +
      + +
      +
      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
      -
      -
      - -
      -
           DNAT    loc:192.168.1.0/24    loc:192.168.1.5    tcp    www    -    130.151.100.69:192.168.1.254
      -
      - -
      -

      That rule only works of course if you have a static external - IP address. If you have a dynamic IP address and are running Shorewall - 1.3.4 or later then include this in /etc/shorewall/params:

      -
      - -
      + +
      + + +
      +

      That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are running + Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

      +
      + +
           ETH0_IP=`find_interface_address eth0`
      -
      - -
      +
      + +

      and make your DNAT rule:

      -
      - -
      -
      +
      + +
      +
      + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
      DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
      -
      -
      - -
      -

      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.

      -
      - -

      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.

      - -

      Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both external and internal clients - to access a NATed host using the host's DNS name.

      - -

      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.

      - -

      If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:

      - -

      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).
      - b) Set the Z->Z policy to ACCEPT.
      - c) Masquerade Z to itself.
      -
      - Example:

      - + +
      + +
      +

      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.

      +
      + +

      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.

      + +

      Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external and internal + clients to access a NATed host using the host's DNS name.

      + +

      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.

      + +

      If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:

      + +

      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).
      + b) Set the Z->Z policy to ACCEPT.
      + c) Masquerade Z to itself.
      +
      + Example:

      +

      Zone: dmz
      - Interface: eth2
      - Subnet: 192.168.2.0/24

      - + Interface: eth2
      + Subnet: 192.168.2.0/24

      +

      In /etc/shorewall/interfaces:

      - -
      + +
      + - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + + +
      ZONEINTERFACEBROADCASTOPTIONS
      dmzeth2192.168.2.255multi
      ZONEINTERFACEBROADCASTOPTIONS
      dmzeth2192.168.2.255multi
      -
      - +
      +

      In /etc/shorewall/policy:

      - -
      + +
      + - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + + +
      SOURCE DESTINATIONPOLICYLIMIT:BURST
      dmzdmzACCEPT
      -
      SOURCE DESTINATIONPOLICYLIMIT:BURST
      dmzdmzACCEPT
      +
      -
      - -
      +
      + +
           dmz    dmz    ACCEPT
      -
      - + +

      In /etc/shorewall/masq:

      - -
      + +
      + - - - - - - - - - - - + + + + + + + + + + + - - + + + +
      INTERFACE SUBNETADDRESS
      eth2192.168.2.0/24
      -
      INTERFACE SUBNETADDRESS
      eth2192.168.2.0/24
      +
      -
      - -

      3. I want to use Netmeeting/MSN Messenger - with Shorewall. What do I do?

      - +
      + +

      3. I want to use Netmeeting/MSN Messenger + with Shorewall. What do I do?

      +

      Answer: There is an H.323 connection - tracking/NAT module that may help. Also check the Netfilter mailing - list archives at http://netfilter.samba.org. -

      - -

      4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather than - 'blocked'. Why?

      - -

      Answer: 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 -can 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. -

      - -

      If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web server in violation of - your Service Agreement.

      - -

      4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!

      - -

      Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing 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->all policy - to REJECT, restart Shorewall and do the nmap UDP scan again.

      - -

      5. I've installed Shorewall and now I - can't ping through the firewall

      - -

      Answer: If you want your firewall to be totally open - for "ping":

      - + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help. Also check the Netfilter + mailing list archives at http://netfilter.samba.org. +

      + +

      4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' rather + than 'blocked'. Why?

      + +

      Answer: 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 can 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.

      + +

      If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server in violation + of your Service Agreement.

      + +

      4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!

      + +

      Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing 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->all policy to REJECT, restart Shorewall and do the +nmap UDP scan again.

      + +

      5. I've installed Shorewall and now I + can't ping through the firewall

      + +

      Answer: If you want your firewall to be totally open + for "ping":

      +

      a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
      - b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
      - c) Add the following to /etc/shorewall/icmpdef:

      - -
      -

      run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT

      -
      - -

      6. Where are the log messages written - and how do I change the destination?

      - -

      Answer: 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 policies and rules. 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").

      - -

      By default, older versions of Shorewall ratelimited log messages - through settings in /etc/shorewall/shorewall.conf - -- If you want to log all messages, set:

      - -
      -
           LOGLIMIT=""
           LOGBURST=""
      -
      - -

      6a. Are there any log parsers that work - with Shorewall?

      - -

      Answer: Here are several links that may be helpful: -

      - -
      + b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
      + c) Add the following to /etc/shorewall/icmpdef: +

      + +
      + +

      run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
      +

      +
      + For a complete description of Shorewall 'ping' management, see this page. + +

      6. Where are the log messages written + and how do I change the destination?

      + +

      Answer: 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 policies + and rules. 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").

      + +

      By default, older versions of Shorewall ratelimited log messages + through settings in /etc/shorewall/shorewall.conf + -- If you want to log all messages, set:

      + +
      +
           LOGLIMIT=""
           LOGBURST=""

      Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
      +
      + +

      6a. Are there any log parsers that work + with Shorewall?

      + +

      Answer: Here are several links that may be helpful: +

      + +
      +

      http://www.shorewall.net/pub/shorewall/parsefw/
      - http://www.fireparse.com
      - http://cert.uni-stuttgart.de/projects/fwlogwatchhttp://www.fireparse.com
      + http://cert.uni-stuttgart.de/projects/fwlogwatch
      - http://www.logwatch.org
      -

      -
      - -

      7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't that command work?

      - -

      The 'stop' command is intended to place your firewall into - a safe state whereby only those interfaces/hosts having the 'routestopped' - option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. - If you want to totally open up your firewall, you must use the 'shorewall - clear' command.

      - -

      8. When I try to start Shorewall on RedHat - 7.x, I get messages about insmod failing -- what's wrong?

      - -

      Answer: The output you will see looks something like - this:

      - + http://www.logwatch.org
      +

      +
      + 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.  +

      7. When I stop Shorewall using 'shorewall + stop', I can't connect to anything. Why doesn't that command work?

      + +

      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.

      + +

      8. When I try to start Shorewall on RedHat, +I get messages about insmod failing -- what's wrong?

      + +

      Answer: The output you will see looks something like + this:

      + 
           /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
           Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
           /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
           /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
           /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
           iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
           Perhaps iptables or your kernel needs to be upgraded.
      - -

      This is usually cured by the following sequence of commands: -

      - -
      + +

      This is usually cured by the following sequence of commands: +

      + +
           service ipchains stop
           chkconfig --delete ipchains
           rmmod ipchains
      -
      - -
      -

      Also, be sure to check the errata - for problems concerning the version of iptables (v1.2.3) shipped with - RH7.2.

      -
      - +
      + +
      +

      Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped + with RH7.2.

      +
      +

      - -

      9. Why can't Shorewall detect my interfaces - properly?

      - -

      I just installed Shorewall and when I issue the start command, - I see the following:

      - -
      + +

      9. Why can't Shorewall detect my interfaces + properly?

      + +

      I just installed Shorewall and when I issue the start command, + I see the following:

      + +
           Processing /etc/shorewall/shorewall.conf ...
           Processing /etc/shorewall/params ...
           Starting Shorewall...
           Loading Modules...
           Initializing...
           Determining Zones...
           Zones: net loc
           Validating interfaces file...
           Validating hosts file...
           Determining Hosts in Zones...
           Net Zone: eth0:0.0.0.0/0
           Local Zone: eth1:0.0.0.0/0
           Deleting user chains...
           Creating input Chains...
           ...
      -
      - -
      +
      + +

      Why can't Shorewall detect my interfaces properly?

      -
      - -
      -

      Answer: 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

      -
      - -

      10. What Distributions does it work - with?

      - -

      Shorewall works with any GNU/Linux distribution that includes - the proper prerequisites.

      - +
      + +
      +

      Answer: 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

      +
      + +

      10. What Distributions does it work + with?

      + +

      Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.

      +

      11. What Features does it have?

      - -

      Answer: See the Shorewall - Feature List.

      - + +

      Answer: See the Shorewall + Feature List.

      +

      12. Why isn't there a GUI?

      - -

      Answer: 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.

      - + +

      Answer: 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.

      +

      13. Why do you call it "Shorewall"?

      - -

      Answer: Shorewall is a concatenation of "Shoreline" - (the city where I live) - and "Firewall".

      - -

      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.

      - -

      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.

      - -

      Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:

      - -
      + +

      Answer: Shorewall is a concatenation of "Shoreline" + (the city where +I live) and "Firewall". The full name of the product +is actually "Shoreline Firewall" but "Shorewall" is must more commonly used.

      + +

      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.

      + +

      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?

      + +

      Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:

      + +
           run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
      -
      - -
      -

      If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:

      -
      - -
      -
      +
      + +
      +

      If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:

      +
      + +
      +
      + - - - - - - - - - + + + + + + + + + - - + + + +
      SUBNET TARGET
      192.168.100.1RETURN
      SUBNET TARGET
      192.168.100.1RETURN
      -
      -
      - -
      + +
      + +

      Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
      -

      - -

      Note: If you add a second IP address to your external firewall - interface to correspond to the modem address, you must also make an entry - in /etc/shorewall/rfc1918 for that address. For example, if you configure - the address 192.168.100.2 on your firewall, then you would add two entries - to /etc/shorewall/rfc1918:
      -

      - -
      +

      + +

      Note: If you add a second IP address to your external firewall + interface to correspond to the modem address, you must also make + an entry in /etc/shorewall/rfc1918 for that address. For example, + if you configure the address 192.168.100.2 on your firewall, then +you would add two entries to /etc/shorewall/rfc1918:
      +

      + +
      + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
      SUBNET
      -       		TARGET
      -
      192.168.100.1
      -       		RETURN
      -
      192.168.100.2
      -       		RETURN
      -
      SUBNET
      +       		TARGET
      +
      192.168.100.1
      +       		RETURN
      +
      192.168.100.2
      +       		RETURN
      +
      -
      -
      - -
      -

      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.

      -
      - -
      -

      The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.

      -
      - -

      15. My local systems can't see out to - the net

      - -

      Answer: 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:

      - + +
      + +
      +

      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.

      +
      + +
      +

      The solution is the same as FAQ 14 above. Simply substitute + the IP address of your ISPs DHCP server.

      +
      + +

      15. My local systems can't see out to + the net

      + +

      Answer: 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:

      +
        -
      1. - -

        The default gateway on each local system isn't set to - the IP address of the local firewall interface.

        -
        2. -
      2. - -

        The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.

        -
        3. -
      3. - -

        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.

        -
        4. - +
      4. + + +

        The default gateway on each local system isn't set to + the IP address of the local firewall interface.

        +
        5. +
      5. + + +

        The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.

        +
        6. +
      6. + + +

        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.

        +
        7. +
      - -

      16. Shorewall is writing log messages - all over my console making it unusable!

      - -

      Answer: "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.
      -

      - -

      17. How do I find out why this is getting logged?

      - Answer: Logging occurs out of a number of chains (as indicated - in the log message) in Shorewall:
      - + +

      16. Shorewall is writing log messages + all over my console making it unusable!

      + +

      Answer: "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.
      +

      + +

      17. How do I find out why this traffic is getting +logged?

      + Answer: Logging occurs out of a number of chains + (as indicated in the log message) in Shorewall:
      +
        -
      1. man1918 - The destination address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see man1918 - The destination address is listed + in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
        2. -
      2. rfc1918 - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 - The source address is listed in + /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
        3. -
      3. all2<zone>, <zone>2all or all2all - - You have a policy 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 rule to that effect.
        -
        4. -
      4. <zone1>2<zone2> - Either you have a policy for <zone1> to - <zone2> that specifies a log level and this packet is being - logged under that policy or this packet matches a rule that includes a log level.
        5. -
      5. <interface>_mac - The packet is being logged under the - maclist interface option.
        -
        6. -
      6. logpkt - The packet is being logged under the logunclean - interface option.
        7. -
      7. badpkt - The packet is being logged under the dropunclean - interface option as specified - in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
        8. -
      8. blacklst - The packet is being logged because the source - IP is blacklisted in the /etc/shorewall/blacklist - file.
        9. -
      9. newnotsyn - 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 NEWNOTSYN - and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
        10. -
      10. INPUT or FORWARD - 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.
        11. - +
      11. all2<zone>, <zone>2all +or all2all - You have a policy 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 rule + to that effect.
        +
        12. +
      12. <zone1>2<zone2> - Either you +have a policy for <zone1> + to <zone2> that specifies a log level and this +packet is being logged under that policy or this packet matches a + rule that includes a log level.
        13. +
      13. <interface>_mac - The packet is being logged + under the maclist interface option.
        +
        14. +
      14. logpkt - The packet is being logged under + the logunclean interface option.
        15. +
      15. badpkt - The packet is being logged under + the dropunclean interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
        16. +
      16. blacklst - The packet is being logged because + the source IP is blacklisted in the /etc/shorewall/blacklist file.
        17. +
      17. newnotsyn - 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 NEWNOTSYN and LOGNEWNOTSYN in + /etc/shorewall/shorewall.conf.
        18. +
      18. INPUT or FORWARD - 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.
        19. +
      19. logflags - The packet is being logged because it failed + the checks implemented by the tcpflags interface option.
        +
        20. +
      - -

      18. Is there any way to use aliased ip addresses - with Shorewall, and maintain separate rulesets for different IPs?

      - Answer: Yes. You simply use the IP address in your rules (or -if you use NAT, use the local IP address in your rules). Note: 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.
      -
      - Example 1:
      -
      - /etc/shorewall/rules + +

      18. Is there any way to use aliased ip addresses + with Shorewall, and maintain separate rulesets for different IPs?

      + Answer: Yes. You simply use the IP address in your +rules (or if you use NAT, use the local IP address in your rules). +Note: 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.
      +
      + Example 1:
      +
      + /etc/shorewall/rules 
           # Accept AUTH but only on address 192.0.2.125

           ACCEPT	net	fw:192.0.2.125	tcp	auth
      - Example 2 (NAT):
      -
      - /etc/shorewall/nat
      - + Example 2 (NAT):
      +
      + /etc/shorewall/nat
      + 
           192.0.2.126	eth0	10.1.1.126
      - /etc/shorewall/rules + /etc/shorewall/rules 
           # Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)

           ACCEPT	net	loc:10.1.1.126	tcp	www
      - Example 3 (DNAT):
      -       + Example 3 (DNAT):
      + 
           # Forward SMTP on external address 192.0.2.127 to local system 10.1.1.127

           DNAT	net	loc:10.1.1.127	tcp	smtp	-	192.0.2.127
      + +

      19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?

      + You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf + so the contents of the tcrules file are simply being ignored.
      + +

      20. I have just set up a server. Do I have + to change Shorewall to allow access to my server from the internet?
      +

      + Yes. Consult the QuickStart + guide that you used during your initial setup for information about + how to set up rules for your server.
      + +

      21. I see these strange log entries occasionally; + what are they?
      +

      + +
      + 
      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
           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 
           [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 ]
      +
      + 192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal + LAN
      +
      + Answer: 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.
      +
      + 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.
      +
      + 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.
      -

      19. I have added entries to /etc/shorewall/tcrules -but they don't seem to do anything. Why?

      - You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf -so the contents of the tcrules file are simply being ignored.
      -

      20. I have just set up a server. Do I have -to change Shorewall to allow access to my server from the internet?
      -

      -Yes. Consult the QuickStart guide -that you used during your initial setup for information about how to set -up rules for your server.
      -
      - +

      22. I have some iptables commands that +I want to run when Shorewall starts. Which file do I put them in?

      + You can place these commands in one of the Shorewall Extension Scripts. 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.
      +
      +
      - Last updated 11/24/2002 - Tom Eastep - -

      Copyright - © 2001, 2002 Thomas M. Eastep.
      + Last updated 12/13/2002 - Tom Eastep + +

      Copyright + © 2001, 2002 Thomas M. Eastep.
      +

      +
      +

      -




      diff --git a/Shorewall-docs/MAC_Validation.html b/Shorewall-docs/MAC_Validation.html index 19fdb4615..49be690fa 100644 --- a/Shorewall-docs/MAC_Validation.html +++ b/Shorewall-docs/MAC_Validation.html @@ -2,103 +2,109 @@ MAC Verification - + - + - + - - - + + - - - + +
      + + + +
      - +
      +

      MAC Verification
      -

      -
      -
      -
      - 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. There are four components to this facility.
      - +
      + 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.
      +
      +You must have the iproute package (ip utility) installed to use MAC Verification.
      +
      +There are four components to this facility.
      +
        -
      1. The maclist interface option in /etc/shorewall/interfaces. When this -option is specified, all traffic arriving on the interface is subjet to MAC -verification.
        2. -
      2. The maclist option in /etc/shorewall/hosts. - When this option is specified for a subnet, all traffic from that subnet -is subject to MAC verification.
        3. -
      3. The /etc/shorewall/maclist file. This file is used to associate -MAC addresses with interfaces and to optionally associate IP addresses with -MAC addresses.
        4. -
      4. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables - in /etc/shorewall/shorewall.conf. The - MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and determines - the disposition of connection requests that fail MAC verification. The MACLIST_LOG_LEVEL - variable gives the syslogd level at which connection requests that fail verification - are to be logged. If set the the empty value (e.g., MACLIST_LOG_LEVEL="") - then failing connection requests are not logged.
        -
        5. - +
      5. The maclist interface option in /etc/shorewall/interfaces. When +this option is specified, all traffic arriving on the interface is subjet +to MAC verification.
        6. +
      6. The maclist option in /etc/shorewall/hosts. + When this option is specified for a subnet, all traffic from that subnet + is subject to MAC verification.
        7. +
      7. The /etc/shorewall/maclist file. This file is used to associate +MAC addresses with interfaces and to optionally associate IP addresses with + MAC addresses.
        8. +
      8. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables + in /etc/shorewall/shorewall.conf. +The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and +determines the disposition of connection requests that fail MAC verification. +The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection +requests that fail verification are to be logged. If set the the empty value +(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.
        +
        9. +
      - The columns in /etc/shorewall/maclist are:
      - + The columns in /etc/shorewall/maclist are:
      +
        -
      • INTERFACE - The name of an ethernet interface on the Shorewall system.
        • -
      • 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.
        • -
      • IP Address - An optional comma-separated list of IP addresses for +
      • INTERFACE - The name of an ethernet interface on the Shorewall +system.
        • +
      • 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.
        • +
      • IP Address - An optional comma-separated list of IP addresses for the device whose MAC is listed in the MAC column.
        • - +
      - +

      Example 1: Here are my files:

      - /etc/shorewall/shorewall.conf:
      -       + /etc/shorewall/shorewall.conf:
      + 
           MACLIST_DISPOSITION=REJECT
           MACLIST_LOG_LEVEL=info
      - /etc/shorewall/interfaces:
      - + /etc/shorewall/interfaces:
      + 
           #ZONE           INTERFACE       BROADCAST       OPTIONS
           net             eth0            206.124.146.255 norfc1918,filterping,dhcp,blacklist
           loc             eth2            192.168.1.255   dhcp,filterping,maclist
           dmz             eth1            192.168.2.255   filterping
           net             eth3            206.124.146.255 filterping,blacklist
           -               texas           192.168.9.255   filterping
           loc             ppp+            -               filterping
      - /etc/shorewall/maclist:
      - + /etc/shorewall/maclist:
      + 
           #INTERFACE              MAC                     IP ADDRESSES (Optional)
           eth2                    00:A0:CC:63:66:89       192.168.1.3     #Wookie
           eth2                    00:10:B5:EC:FD:0B       192.168.1.4     #Tarry
           eth2                    00:A0:CC:DB:31:C4       192.168.1.5     #Ursa
           eth2                    00:06:25:aa:a8:0f       192.168.1.7     #Eastept1 (Wireless)
           eth2                    00:04:5A:0E:85:B9       192.168.1.250   #Wap
      - As shown above, I use MAC Verification on my local - zone.
      - + As shown above, I use MAC Verification on my local + zone.
      +

      Example 2: Router in Local Zone

      - 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 - file:
      - + 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 + file:
      + 
           eth2                     00:06:43:45:C6:15       192.168.1.253,192.168.2.0/24
      - 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 -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. -

      Updated 10/23/2002 - Tom Eastep + 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 + 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. +

      Updated 12/22/2002 - Tom Eastep

      - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      -
      -
      + +

      Copyright + © 2001, 2002 Thomas M. Eastep.

      +
      +
      +



      diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 4bd17b10c..72cba3084 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -1,1525 +1,1867 @@ - + + Shorewall News - + + - + + - + - - - + + - - - + + + + +
      +
      - + +

      Shorewall News Archive

      -
      - + +

      12/27/2002 - Shorewall 1.3.12 Released

      +

      Features include:
      +

      +
        +
      1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
        2. +
      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.
        3. +
      3. "shorewall [re]start" has been speeded up by more than 40% with my + configuration. Your milage may vary.
        4. +
      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"
        5. +
      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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
        6. +
      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_CHAIN=Yes in shorewall.conf. This allows for marking + input packets based on their destination even when you are using Masquerading + or SNAT.
        7. +
      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.
        8. +
      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.
        +
        9. +
      +

      12/20/2002 - Shorewall 1.3.12 Beta 3
      +

      + 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.
      + +

      12/20/2002 - Shorewall 1.3.12 Beta 2

      + +

      The first public Beta version of Shorewall 1.3.12 is now available (Beta + 1 was made available only to a limited audience).
      +

      + Features include:
      + +
        +
      1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
        2. +
      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.
        3. +
      3. "shorewall [re]start" has been speeded up by more than 40% with + my configuration. Your milage may vary.
        4. +
      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"
        5. +
      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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
        6. +
      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_CHAIN=Yes in shorewall.conf. This allows for + marking input packets based on their destination even when you are using + Masquerading or SNAT.
        7. +
      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.
        8. + +
      + You may download the Beta from:
      + +
      http://www.shorewall.net/pub/shorewall/Beta
      + ftp://ftp.shorewall.net/pub/shorewall/Beta
      +
      + +

      12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux +

      + Shorewall is at the center of MandrakeSoft's recently-announced Multi + Network Firewall (MNF) product. Here is the press + release.
      + +

      12/7/2002 - Shorewall Support for Mandrake 9.0

      + +

      Two months and 3 days after I 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.

      + +

      12/6/2002 - Debian 1.3.11a Packages Available
      +

      + +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      + +

      12/3/2002 - Shorewall 1.3.11a

      + +

      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.

      +

      11/24/2002 - Shorewall 1.3.11

      +

      In this version:

      +
        -
      • A 'tcpflags' option has been added to entries in A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. This option causes Shorewall to make a set of sanity check on TCP packet header flags.
        • -
      • It is now allowed to use 'all' in the SOURCE or DEST column in a rule. When used, 'all' must appear by -itself (in may not be qualified) and it does not enable intra-zone traffic. -For example, the rule
        -
        -    ACCEPT loc all tcp 80
        -
        -does not enable http traffic from 'loc' to 'loc'.
        • -
      • Shorewall's use of the 'echo' command is now compatible with bash clones -such as ash and dash.
        • -
      • fw->fw policies now generate a startup error. fw->fw rules generate -a warning and are ignored
        • +
      • It is now allowed to use 'all' in the SOURCE or DEST column + in a rule. When used, 'all' +must appear by itself (in may not be qualified) and it does not enable +intra-zone traffic. For example, the rule
        +
        +     ACCEPT loc all tcp 80
        +
        + does not enable http traffic from 'loc' to 'loc'.
        • +
      • Shorewall's use of the 'echo' command is now compatible +with bash clones such as ash and dash.
        • +
      • fw->fw policies now generate a startup error. fw->fw + rules generate a warning and are ignored
        • +
      +

      11/14/2002 - Shorewall Documentation in PDF Format

      - +

      Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. -the PDF may be downloaded from

      - + the PDF may be downloaded from

      +

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      -     http://slovakia.shorewall.net/pub/shorewall/pdf/
      -

      - -

      11/09/2002 - Shorewall is Back at SourceForge -

      - -

      The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
      -

      - -

      11/09/2002 - Shorewall 1.3.10

      - -

      In this version:

      - - - -

      10/24/2002 - Shorewall is now in Gentoo Linux
      -

      - Alexandru Hartmann reports that his Shorewall package is now a part -of the Gentoo Linux distribution. Thanks - Alex!
      - -

      10/23/2002 - Shorewall 1.3.10 Beta 1

      - In this version:
      - - - You may download the Beta from:
      - - - -

      10/10/2002 -  Debian 1.3.9b Packages Available
      -

      - -

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - -

      10/9/2002 - Shorewall 1.3.9b

      - This release rolls up fixes to the installer and to the firewall script.
      - -

      10/6/2002 - Shorewall.net now running on RH8.0
      -
      - The firewall and server here at shorewall.net are now running RedHat - release 8.0.
      -
      - 9/30/2002 - Shorewall 1.3.9a

      - Roles up the fix for broken tunnels.
      - -

      9/30/2002 - TUNNELS Broken in 1.3.9!!!

      - There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
      - -

      9/28/2002 - Shorewall 1.3.9

      - -

      In this version:
      +     http://slovakia.shorewall.net/pub/shorewall/pdf/

      -
        -
      • DNS Names - are now allowed in Shorewall config files (although I recommend against - using them).
        • -
      • The connection SOURCE may now be qualified by both interface - and IP address in a Shorewall rule.
        • -
      • Shorewall startup is now disabled after initial installation - until the file /etc/shorewall/startup_disabled is removed. This avoids - nasty surprises during reboot for users who install Shorewall but don't - configure it.
        • -
      • The 'functions' and 'version' files and the 'firewall' symbolic - link have been moved from /var/lib/shorewall to /usr/lib/shorewall to - appease the LFS police at Debian.
        -
        • - -
      - -

      9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
      -

      - Brown Paper Bag - A couple of recent configuration changes at www.shorewall.net - broke the Search facility:
      - -
      -
        -
      1. Mailing List Archive Search was not available.
        2. -
      2. The Site Search index was incomplete
        3. -
      3. Only one page of matches was presented.
        4. - -
      -
      - Hopefully these problems are now corrected. -

      9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
      -

      - A couple of recent configuration changes at www.shorewall.net - had the negative effect of breaking the Search facility:
      - -
        -
      1. Mailing List Archive Search was not available.
        2. -
      2. The Site Search index was incomplete
        3. -
      3. Only one page of matches was presented.
        4. - -
      - Hopefully these problems are now corrected.
      - -

      9/18/2002 -  Debian 1.3.8 Packages Available
      -

      +

      11/09/2002 - Shorewall is Back at SourceForge +

      + +

      The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
      +

      + +

      11/09/2002 - Shorewall 1.3.10

      +

      In this version:

      + + + +

      10/24/2002 - Shorewall is now in Gentoo Linux
      +

      + Alexandru Hartmann reports that his Shorewall package is +now a part of the Gentoo Linux distribution. + Thanks Alex!
      + +

      10/23/2002 - Shorewall 1.3.10 Beta 1

      + In this version:
      + + + You may download the Beta from:
      + + + +

      10/10/2002 -  Debian 1.3.9b Packages Available
      +

      +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - -

      9/16/2002 - Shorewall 1.3.8

      +

      10/9/2002 - Shorewall 1.3.9b

      + This release rolls up fixes to the installer and to the +firewall script.
      + +

      10/6/2002 - Shorewall.net now running on RH8.0
      +
      + The firewall and server here at shorewall.net are now +running RedHat release 8.0.
      +
      + 9/30/2002 - Shorewall 1.3.9a

      + Roles up the fix for broken tunnels.
      + +

      9/30/2002 - TUNNELS Broken in 1.3.9!!!

      + There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall.
      + +

      9/28/2002 - Shorewall 1.3.9

      +

      In this version:
      -

      - +

      +
        -
      • A NEWNOTSYN option - has been added to shorewall.conf. This option determines whether -Shorewall accepts TCP packets which are not part of an established -connection and that are not 'SYN' packets (SYN flag on and ACK flag -off).
        • -
      • The need for the 'multi' option to communicate between - zones za and zb on the same interface is removed in the case where -the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
        • - +
      • DNS Names are + now allowed in Shorewall config files (although I recommend against + using them).
        • +
      • The connection SOURCE may now be qualified +by both interface and IP address in a Shorewall rule.
        • +
      • Shorewall startup is now disabled after initial + installation until the file /etc/shorewall/startup_disabled is + removed. This avoids nasty surprises during reboot for users who +install Shorewall but don't configure it.
        • +
      • The 'functions' and 'version' files and the 'firewall' + symbolic link have been moved from /var/lib/shorewall to /usr/lib/shorewall + to appease the LFS police at Debian.
        +
        • + +
      + +

      9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
      +

      + Brown Paper Bag + A couple of recent configuration changes at www.shorewall.net + broke the Search facility:
      + + +
      + +
        +
      1. Mailing List Archive Search was not available.
        2. +
      2. The Site Search index was incomplete
        3. +
      3. Only one page of matches was presented.
        4. + + +
      +
      + Hopefully these problems are now corrected. + +

      9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
      +

      + A couple of recent configuration changes at www.shorewall.net + had the negative effect of breaking the Search facility:
      + +
        +
      1. Mailing List Archive Search was not available.
        2. +
      2. The Site Search index was incomplete
        3. +
      3. Only one page of matches was presented.
        4. + +
      + Hopefully these problems are now corrected.
      + +

      9/18/2002 -  Debian 1.3.8 Packages Available
      +

      + +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      + +

      9/16/2002 - Shorewall 1.3.8

      + +

      In this version:
      +

      + +
        +
      • A NEWNOTSYN + option has been added to shorewall.conf. This option determines + whether Shorewall accepts TCP packets which are not part of an + established connection and that are not 'SYN' packets (SYN flag + on and ACK flag off).
        • +
      • The need for the 'multi' option to communicate + between zones za and zb on the same interface is removed in the + case where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will + exist if:
        • + +
          -
        • There is a policy for za to zb; or
          • -
        • There is at least one rule for za to zb.
          • - +
        • There is a policy for za to zb; + or
          • +
        • There is at least one rule for za +to zb.
          • + +
        - +
      - +
        -
      • The /etc/shorewall/blacklist file now contains three - columns. In addition to the SUBNET/ADDRESS column, there are optional - PROTOCOL and PORT columns to block only certain applications from the - blacklisted addresses.
        -
        • - +
      • The /etc/shorewall/blacklist file now +contains three columns. In addition to the SUBNET/ADDRESS column, +there are optional PROTOCOL and PORT columns to block only certain +applications from the blacklisted addresses.
        +
        • +
      - +

      9/11/2002 - Debian 1.3.7c Packages Available

      - + +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + +

      9/2/2002 - Shorewall 1.3.7c

      - + +

      This is a role up of a fix for "DNAT" rules where the source zone is $FW - (fw).

      - + (fw).

      + +

      8/31/2002 - I'm not available

      - + +

      I'm currently on vacation  -- please respect my need for a couple of weeks free of Shorewall problem reports.

      - + +

      -Tom

      - + +

      8/26/2002 - Shorewall 1.3.7b

      - + +

      This is a role up of the "shorewall refresh" bug fix and the change which - reverses the order of "dhcp" and "norfc1918" checking.

      - + reverses the order of "dhcp" and "norfc1918" checking.

      + +

      8/26/2002 - French FTP Mirror is Operational

      - + +

      ftp://france.shorewall.net/pub/mirrors/shorewall - is now available.

      - + is now available.

      + +

      8/25/2002 - Shorewall Mirror in France

      - + +

      Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored - at http://france.shorewall.net.

      - + at http://france.shorewall.net.

      + +

      8/25/2002 - Shorewall 1.3.7a Debian Packages Available

      - + +

      Lorenzo Martignoni reports that the packages for version 1.3.7a are available - at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + at http://security.dsi.unimi.it/~lorenzo/debian.html.

      + +

      8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author - -- Shorewall 1.3.7a released -

      - +

      + +

      1.3.7a corrects problems occurring in rules file processing when starting - Shorewall 1.3.7.

      - + Shorewall 1.3.7.

      + +

      8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

      - + +

      Features in this release include:

      - + + - + +

      I would like to thank John Distler for his valuable input regarding TCP - SYN and ICMP treatment in Shorewall. That input has led to marked - improvement in Shorewall in the last two releases.

      - + SYN and ICMP treatment in Shorewall. That input has led to + marked improvement in Shorewall in the last two releases.

      + +

      8/13/2002 - Documentation in the CVS Repository

      - + +

      The Shorewall-docs project now contains just the HTML and image files - the Frontpage files have been removed.

      - + +

      8/7/2002 - STABLE branch added to CVS Repository

      - + +

      This branch will only be updated after I release a new version of Shorewall - so you can always update from this branch to get the latest stable - tree.

      - + so you can always update from this branch to get the latest + stable tree.

      + +

      8/7/2002 - Upgrade Issues section added to the Errata Page

      - + +

      Now there is one place to go to look for issues involved with upgrading - to recent versions of Shorewall.

      - + to recent versions of Shorewall.

      + +

      8/7/2002 - Shorewall 1.3.6

      - + +

      This is primarily a bug-fix rollup with a couple of new features:

      - + + - +

      7/30/2002 - Shorewall 1.3.5b Released

      - + +

      This interim release:

      - + + - +

      7/29/2002 - New Shorewall Setup Guide Available

      - + +

      The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. - The guide is intended for use by people who are setting up Shorewall - to manage multiple public IP addresses and by people who want to -learn more about Shorewall than is described in the single-address -guides. Feedback on the new guide is welcome.

      - + The guide is intended for use by people who are setting up + Shorewall to manage multiple public IP addresses and by people + who want to learn more about Shorewall than is described in the + single-address guides. Feedback on the new guide is welcome.

      + +

      7/28/2002 - Shorewall 1.3.5 Debian Package Available

      - + +

      Lorenzo Martignoni reports that the packages are version 1.3.5a and are - available at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + +

      7/27/2002 - Shorewall 1.3.5a Released

      - + +

      This interim release restores correct handling of REDIRECT rules.

      - + +

      7/26/2002 - Shorewall 1.3.5 Released

      - + +

      This will be the last Shorewall release for a while. I'm going to be focusing on rewriting a lot of the documentation.

      - + +

       In this version:

      - + + - +

      7/16/2002 - New Mirror in Argentina

      - + +

      Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in - Argentina. Thanks Buanzo!!!

      - + Argentina. Thanks Buanzo!!!

      + +

      7/16/2002 - Shorewall 1.3.4 Released

      - + +

      In this version:

      - + +
        -
      • A new - /etc/shorewall/routestopped file has been added. This file -is intended to eventually replace the routestopped option - in the /etc/shorewall/interface and /etc/shorewall/hosts files. -This new file makes remote firewall administration easier by allowing - any IP or subnet to be enabled while Shorewall is stopped.
        • -
      • An /etc/shorewall/stopped A new /etc/shorewall/routestopped + file has been added. This file is intended to eventually +replace the routestopped option in the /etc/shorewall/interface + and /etc/shorewall/hosts files. This new file makes remote +firewall administration easier by allowing any IP or subnet to be + enabled while Shorewall is stopped.
        • +
      • An /etc/shorewall/stopped extension script has been added. - This script is invoked after Shorewall has stopped.
        • -
      • A DETECT_DNAT_ADDRS option has been added -to /etc/shoreall/shorewall.conf. - When this option is selected, DNAT rules only apply when the destination - address is the external interface's primary IP address.
        • -
      • The QuickStart - Guide has been broken into three guides and has been almost - entirely rewritten.
        • -
      • The Samples have been updated to reflect the new -capabilities in this release.
        • - + This script is invoked after Shorewall has stopped. +
      • A DETECT_DNAT_ADDRS option has + been added to /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only apply when + the destination address is the external interface's primary + IP address.
        • +
      • The QuickStart Guide has + been broken into three guides and has been almost entirely rewritten.
        • +
      • The Samples have been updated to reflect + the new capabilities in this release.
        • +
      - +

      7/8/2002 - Shorewall 1.3.3 Debian Package Available

      - + +

      Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + +

      7/6/2002 - Shorewall 1.3.3 Released

      - + +

      In this version:

      - + +
        -
      • Entries in /etc/shorewall/interface that use the -wildcard character ("+") now have the "multi" option assumed.
        • -
      • The 'rfc1918' chain in the mangle table has been -renamed 'man1918' to make log messages generated from that chain -distinguishable from those generated by the 'rfc1918' chain in -the filter table.
        • -
      • Interface names appearing in the hosts file are -now validated against the interfaces file.
        • -
      • The TARGET column in the rfc1918 file is now checked - for correctness.
        • -
      • The chain structure in the nat table has been changed - to reduce the number of rules that a packet must traverse and -to correct problems with NAT_BEFORE_RULES=No
        • -
      • The "hits" command has been enhanced.
        • - +
      • Entries in /etc/shorewall/interface +that use the wildcard character ("+") now have the "multi" +option assumed.
        • +
      • The 'rfc1918' chain in the mangle table + has been renamed 'man1918' to make log messages generated + from that chain distinguishable from those generated by the + 'rfc1918' chain in the filter table.
        • +
      • Interface names appearing in the hosts + file are now validated against the interfaces file.
        • +
      • The TARGET column in the rfc1918 file + is now checked for correctness.
        • +
      • The chain structure in the nat table +has been changed to reduce the number of rules that a packet +must traverse and to correct problems with NAT_BEFORE_RULES=No
        • +
      • The "hits" command has been enhanced.
        • +
      - +

      6/25/2002 - Samples Updated for 1.3.2

      - + +

      The comments in the sample configuration files have been updated to reflect - new features introduced in Shorewall 1.3.2.

      - + new features introduced in Shorewall 1.3.2.

      + +

      6/25/2002 - Shorewall 1.3.1 Debian Package Available

      - + +

      Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + +

      6/19/2002 - Documentation Available in PDF Format

      - + +

      Thanks to Mike Martinez, the Shorewall Documentation is now available for download in Adobe PDF format.

      - + +

      6/16/2002 - Shorewall 1.3.2 Released

      - + +

      In this version:

      - + + - +

      6/6/2002 - Why CVS Web access is Password Protected

      - + +

      Last weekend, I installed the CVS Web package to provide brower-based access to the Shorewall CVS repository. Since then, I have had several instances where my server was almost unusable due to the high load generated by website copying tools like HTTrack and WebStripper. These mindless tools:

      - + +
        -
      • Ignore robot.txt files.
        • -
      • Recursively copy everything that they find.
        • -
      • Should be classified as weapons rather than tools.
        • - +
      • Ignore robot.txt files.
        • +
      • Recursively copy everything that they + find.
        • +
      • Should be classified as weapons rather + than tools.
        • +
      - +

      These tools/weapons are particularly damaging when combined with CVS Web - because they doggedly follow every link in the cgi-generated HTML - resulting in 1000s of executions of the cvsweb.cgi script. Yesterday, - I spend several hours implementing measures to block these tools but - unfortunately, these measures resulted in my server OOM-ing under -even moderate load.

      - + because they doggedly follow every link in the cgi-generated + HTML resulting in 1000s of executions of the cvsweb.cgi script. + Yesterday, I spend several hours implementing measures to block + these tools but unfortunately, these measures resulted in my server + OOM-ing under even moderate load.

      + +

      Until I have the time to understand the cause of the OOM (or until I buy - more RAM if that is what is required), CVS Web access will remain - Password Protected.

      - + more RAM if that is what is required), CVS Web access will + remain Password Protected.

      + +

      6/5/2002 - Shorewall 1.3.1 Debian Package Available

      - + +

      Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

      - + +

      6/2/2002 - Samples Corrected

      - + +

      The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These problems have been corrected - in the 1.3.1 samples.

      - + DNS and SSH from working properly. These problems have been + corrected in the 1.3.1 + samples.

      + +

      6/1/2002 - Shorewall 1.3.1 Released

      - + +

      Hot on the heels of 1.3.0, this release:

      - + + - +

      5/29/2002 - Shorewall 1.3.0 Released

      - + +

      In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 includes:

      - + +
        -
      • A 'filterping' interface option that allows ICMP -echo-request (ping) requests addressed to the firewall to be handled -by entries in /etc/shorewall/rules and /etc/shorewall/policy.
        • - +
      • A 'filterping' interface option that +allows ICMP echo-request (ping) requests addressed to the +firewall to be handled by entries in /etc/shorewall/rules and +/etc/shorewall/policy.
        • +
      - +

      5/23/2002 - Shorewall 1.3 RC1 Available

      - + +

      In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) incorporates the following:

      - + + - + +

      5/19/2002 - Shorewall 1.3 Beta 2 Available

      - + +

      In addition to the changes in Beta 1, this release which carries the designation 1.2.91 adds:

      - + +
        -
      • The structure of the firewall is changed markedly. - There is now an INPUT and a FORWARD chain for each interface; this - reduces the number of rules that a packet must traverse, especially - in complicated setups.
        • -
      • Sub-zones may - now be excluded from DNAT and REDIRECT rules.
        • -
      • The names of the columns in a number of the configuration - files have been changed to be more consistent and self-explanatory - and the documentation has been updated accordingly.
        • -
      • The sample configurations have been updated for -1.3.
        • - +
      • The structure of the firewall is changed + markedly. There is now an INPUT and a FORWARD chain for each + interface; this reduces the number of rules that a packet +must traverse, especially in complicated setups.
        • +
      • Sub-zones + may now be excluded from DNAT and REDIRECT rules.
        • +
      • The names of the columns in a number +of the configuration files have been changed to be more consistent + and self-explanatory and the documentation has been updated + accordingly.
        • +
      • The sample configurations have been +updated for 1.3.
        • +
      - + +

      5/17/2002 - Shorewall 1.3 Beta 1 Available

      - + +

      Beta 1 carries the version designation 1.2.90 and implements the following - features:

      - + features:

      + +
        -
      • Simplified rule syntax which makes the intent of -each rule clearer and hopefully makes Shorewall easier to learn.
        • -
      • Upward compatibility with 1.2 configuration files - has been maintained so that current users can migrate to the -new syntax at their convenience.
        • -
      • WARNING:  Compatibility -with the old parameterized sample configurations has NOT been maintained. - Users still running those configurations should migrate to the - new sample configurations before upgrading to 1.3 Beta 1.
        • - +
      • Simplified rule syntax which makes the + intent of each rule clearer and hopefully makes Shorewall +easier to learn.
        • +
      • Upward compatibility with 1.2 configuration + files has been maintained so that current users can migrate + to the new syntax at their convenience.
        • +
      • WARNING:  Compatibility + with the old parameterized sample configurations has NOT been + maintained. Users still running those configurations should + migrate to the new sample configurations before upgrading to + 1.3 Beta 1.
        • +
      - +

      5/4/2002 - Shorewall 1.2.13 is Available

      - + +

      In this version:

      - + + - +

      4/30/2002 - Shorewall Debian News

      - + +

      Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian Testing Branch and the Debian Unstable Branch.

      - + +

      4/20/2002 - Shorewall 1.2.12 is Available

      - + +
        -
      • The 'try' command works again
        • -
      • There is now a single RPM that also works with SuSE.
        • - +
      • The 'try' command works again
        • +
      • There is now a single RPM that also +works with SuSE.
        • +
      - +

      4/17/2002 - Shorewall Debian News

      - + +

      Lorenzo Marignoni reports that:

      - + + - +

      Thanks, Lorenzo!

      - + +

      4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

      - + +

      Thanks to Stefan Mohr, there - is now a Shorewall 1.2.11 - SuSE RPM available.

      - + SuSE RPM available.

      + +

      4/13/2002 - Shorewall 1.2.11 Available

      - + +

      In this version:

      - + + - + +

      4/13/2002 - Hamburg Mirror now has FTP

      - + +

      Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  - Thanks Stefan!

      - + Thanks Stefan!

      + +

      4/12/2002 - New Mirror in Hamburg

      - + +

      Thanks to Stefan Mohr, there - is now a mirror of the Shorewall website at http://germany.shorewall.net.

      - + is now a mirror of the Shorewall website at http://germany.shorewall.net. +

      + +

      4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available

      - + +

      Version 1.1 of the QuickStart - Guide is now available. Thanks to those who have read version - 1.0 and offered their suggestions. Corrections have also been made - to the sample scripts.

      - + Guide is now available. Thanks to those who have read +version 1.0 and offered their suggestions. Corrections have also +been made to the sample scripts.

      + +

      4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available

      - + +

      Version 1.0 of the QuickStart - Guide is now available. This Guide and its accompanying sample - configurations are expected to provide a replacement for the recently - withdrawn parameterized samples.

      - + Guide is now available. This Guide and its accompanying + sample configurations are expected to provide a replacement +for the recently withdrawn parameterized samples.

      + +

      4/8/2002 - Parameterized Samples Withdrawn

      - + +

      Although the parameterized - samples have allowed people to get a firewall up and running - quickly, they have unfortunately set the wrong level of expectation - among those who have used them. I am therefore withdrawing support - for the samples and I am recommending that they not be used in new -Shorewall installations.

      - + samples have allowed people to get a firewall up and running + quickly, they have unfortunately set the wrong level of expectation + among those who have used them. I am therefore withdrawing +support for the samples and I am recommending that they not +be used in new Shorewall installations.

      + +

      4/2/2002 - Updated Log Parser

      - + +

      John Lodge has provided an updated - version of his CGI-based log parser - with corrected date handling.

      - + version of his CGI-based + log parser with corrected date handling.

      + +

      3/30/2002 - Shorewall Website Search Improvements

      - + +

      The quick search on the home page now excludes the mailing list archives. - The Extended Search allows excluding - the archives or restricting the search to just the archives. An archive - search form is also available on the mailing - list information page.

      - + The Extended Search allows + excluding the archives or restricting the search to just the + archives. An archive search form is also available on the mailing list information page.

      + +

      3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)

      - + + - +

      3/25/2002 - Log Parser Available

      - + +

      John Lodge has provided a CGI-based log parser for Shorewall. Thanks - John.

      - + John.

      + +

      3/20/2002 - Shorewall 1.2.10 Released

      - + +

      In this version:

      - + + - +

      3/11/2002 - Shorewall 1.2.9 Released

      - + +

      In this version:

      - + + - + +

      3/1/2002 - 1.2.8 Debian Package is Available

      - + +

      See http://security.dsi.unimi.it/~lorenzo/debian.html

      - + +

      2/25/2002 - New Two-interface Sample

      - +

      I've enhanced the two interface sample to allow access from the firewall - to servers in the local zone - - http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

      - + http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

      +

      2/23/2002 - Shorewall 1.2.8 Released

      - + +

      Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects problems associated with the lock file used to prevent multiple state-changing - operations from occuring simultaneously. My apologies for any inconvenience - my carelessness may have caused.

      - + operations from occuring simultaneously. My apologies for +any inconvenience my carelessness may have caused.

      + +

      2/22/2002 - Shorewall 1.2.7 Released

      - + +

      In this version:

      - + +
        -
      • UPnP probes (UDP destination port 1900) are now -silently dropped in the common chain
        • -
      • RFC 1918 checking in the mangle table has been streamlined - to no longer require packet marking. RFC 1918 checking in the filter - table has been changed to require half as many rules as previously.
        • -
      • A 'shorewall check' command has been added that -does a cursory validation of the zones, interfaces, hosts, rules -and policy files.
        • - +
      • UPnP probes (UDP destination port 1900) + are now silently dropped in the common chain
        • +
      • RFC 1918 checking in the mangle table + has been streamlined to no longer require packet marking. + RFC 1918 checking in the filter table has been changed to +require half as many rules as previously.
        • +
      • A 'shorewall check' command has been +added that does a cursory validation of the zones, interfaces, +hosts, rules and policy files.
        • +
      - + +

      2/18/2002 - 1.2.6 Debian Package is Available

      - + +

      See http://security.dsi.unimi.it/~lorenzo/debian.html

      - + +

      2/8/2002 - Shorewall 1.2.6 Released

      - + +

      In this version:

      - + +
        -
      • $-variables may now be used anywhere in the configuration - files except /etc/shorewall/zones.
        • -
      • The interfaces and hosts files now have their contents - validated before any changes are made to the existing Netfilter - configuration. The appearance of a zone name that isn't defined -in /etc/shorewall/zones causes "shorewall start" and "shorewall restart" - to abort without changing the Shorewall state. Unknown options in -either file cause a warning to be issued.
        • -
      • A problem occurring when BLACKLIST_LOGLEVEL was -not set has been corrected.
        • - +
      • $-variables may now be used anywhere +in the configuration files except /etc/shorewall/zones.
        • +
      • The interfaces and hosts files now have + their contents validated before any changes are made to +the existing Netfilter configuration. The appearance of a +zone name that isn't defined in /etc/shorewall/zones causes "shorewall + start" and "shorewall restart" to abort without changing the Shorewall + state. Unknown options in either file cause a warning to be issued.
        • +
      • A problem occurring when BLACKLIST_LOGLEVEL + was not set has been corrected.
        • +
      - +

      2/4/2002 - Shorewall 1.2.5 Debian Package Available

      - + +

      see http://security.dsi.unimi.it/~lorenzo/debian.html

      - + +

      2/1/2002 - Shorewall 1.2.5 Released

      - + +

      Due to installation problems with Shorewall 1.2.4, I have released Shorewall - 1.2.5. Sorry for the rapid-fire development.

      - + 1.2.5. Sorry for the rapid-fire development.

      + +

      In version 1.2.5:

      - + +
        -
      • The installation problems have been corrected.
        • -
      • SNAT is now -supported.
        • -
      • A "shorewall version" command has been added
        • -
      • The default value of the STATEDIR variable in - /etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall -in order to conform to the GNU/Linux File Hierarchy Standard, Version -2.2.
        • - +
      • The installation problems have been corrected.
        • +
      • SNAT + is now supported.
        • +
      • A "shorewall version" command has been + added
        • +
      • The default value of the STATEDIR variable + in /etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall + in order to conform to the GNU/Linux File Hierarchy Standard, + Version 2.2.
        • +
      - +

      1/28/2002 - Shorewall 1.2.4 Released

      - + +
        -
      • The "fw" zone may -now be given a different name.
        • -
      • You may now place end-of-line comments (preceded -by '#') in any of the configuration files
        • -
      • There is now protection against against two state -changing operations occuring concurrently. This is implemented -using the 'lockfile' utility if it is available (lockfile is part -of procmail); otherwise, a less robust technique is used. The lockfile -is created in the STATEDIR defined in /etc/shorewall/shorewall.conf -and has the name "lock".
        • -
      • "shorewall start" no longer fails if "detect" is - specified in /etc/shorewall/interfaces - for an interface with subnet mask 255.255.255.255.
        • - +
      • The "fw" zone may now be given a different name.
        • +
      • You may now place end-of-line comments + (preceded by '#') in any of the configuration files
        • +
      • There is now protection against against + two state changing operations occuring concurrently. This + is implemented using the 'lockfile' utility if it is available + (lockfile is part of procmail); otherwise, a less robust technique + is used. The lockfile is created in the STATEDIR defined in /etc/shorewall/shorewall.conf + and has the name "lock".
        • +
      • "shorewall start" no longer fails if +"detect" is specified in /etc/shorewall/interfaces + for an interface with subnet mask 255.255.255.255.
        • +
      - +

      1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html

      - + +

      1/20/2002 - Corrected firewall script available 

      - + +

      Corrects a problem with BLACKLIST_LOGLEVEL. See the - errata for details.

      - + errata for details.

      + +

      1/19/2002 - Shorewall 1.2.3 Released

      - + +

      This is a minor feature and bugfix release. The single new feature is:

      - + + - +

      The following problems were corrected:

      - +
        -
      • The "shorewall status" command no longer hangs.
        • -
      • The "shorewall monitor" command now displays the -icmpdef chain
        • -
      • The CLIENT PORT(S) column in tcrules is no longer -ignored
        • - +
      • The "shorewall status" command no longer + hangs.
        • +
      • The "shorewall monitor" command now displays + the icmpdef chain
        • +
      • The CLIENT PORT(S) column in tcrules +is no longer ignored
        • +
      - +

      1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release

      - + +

      Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution - that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo - for details.

      - + for details.

      + +

      1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2 - Shorewall Debian package is now available. There is a link to Lorenzo's - site from the Shorewall download page.

      - + Shorewall Debian package is now available. There is a link to + Lorenzo's site from the Shorewall download + page.

      + +

      1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores - the "shorewall status" command to health.

      - + the "shorewall status" command to health.

      + +

      1/8/2002 - Shorewall 1.2.2 Released

      - + +

      In version 1.2.2

      - + +
        -
      • Support for IP blacklisting has been added +
      • Support for IP blacklisting has been +added - +
          -
        • You specify whether you want packets from blacklisted - hosts dropped or rejected using the BLACKLIST_DISPOSITION setting - in /etc/shorewall/shorewall.conf
          • -
        • You specify whether you want packets from blacklisted - hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL setting - in /etc/shorewall/shorewall.conf
          • -
        • You list the IP addresses/subnets that you wish -to blacklist in /etc/shorewall/blacklist
          • -
        • You specify the interfaces you want checked against - the blacklist using the new "You specify whether you want packets + from blacklisted hosts dropped or rejected using the + BLACKLIST_DISPOSITION + setting in /etc/shorewall/shorewall.conf
          • +
        • You specify whether you want packets + from blacklisted hosts logged and at what syslog level + using the BLACKLIST_LOGLEVEL + setting in /etc/shorewall/shorewall.conf
          • +
        • You list the IP addresses/subnets that + you wish to blacklist in /etc/shorewall/blacklist
          • +
        • You specify the interfaces you want +checked against the blacklist using the new "blacklist" option in - /etc/shorewall/interfaces.
          • -
        • The black list is refreshed from /etc/shorewall/blacklist - by the "shorewall refresh" command.
          • + /etc/shorewall/interfaces. +
        • The black list is refreshed from /etc/shorewall/blacklist + by the "shorewall refresh" command.
          • - + +
        -
        • -
      • Use of TCP RST replies has been expanded  +
        • +
      • Use of TCP RST replies has been expanded  + - +
          -
        • TCP connection requests rejected because of a REJECT - policy are now replied with a TCP RST packet.
          • -
        • TCP connection requests rejected because of a protocol=all - rule in /etc/shorewall/rules are now replied with a TCP RST - packet.
          • +
        • TCP connection requests rejected because + of a REJECT policy are now replied with a TCP RST packet.
          • +
        • TCP connection requests rejected because + of a protocol=all rule in /etc/shorewall/rules are now + replied with a TCP RST packet.
          • - + +
        -
        • -
      • A LOGFILE -specification has been added to /etc/shorewall/shorewall.conf. -LOGFILE is used to tell the /sbin/shorewall program where to look -for Shorewall messages.
        • - + +
      • A LOGFILE specification +has been added to /etc/shorewall/shorewall.conf. LOGFILE is used + to tell the /sbin/shorewall program where to look for Shorewall +messages.
        • +
      - +

      1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates - to the previously-released samples. There are two new rules added:

      - + to the previously-released samples. There are two new rules +added:

      + +
        -
      • Unless you have explicitly enabled Auth connections - (tcp port 113) to your firewall, these connections will be REJECTED - rather than DROPPED. This speeds up connection establishment -to some servers.
        • -
      • Orphan DNS replies are now silently dropped.
        • - +
      • Unless you have explicitly enabled Auth + connections (tcp port 113) to your firewall, these connections + will be REJECTED rather than DROPPED. This speeds up connection + establishment to some servers.
        • +
      • Orphan DNS replies are now silently dropped.
        • +
      - +

      See the README file for upgrade instructions.

      - +

      1/1/2002 - Shorewall Mailing List Moving

      - + +

      The Shorewall mailing list hosted at - Sourceforge is moving to Shorewall.net. If you are a current -subscriber to the list at Sourceforge, please is moving to Shorewall.net. If you are a current + subscriber to the list at Sourceforge, please see these instructions. - If you would like to subscribe to the new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

      - + +

      12/31/2001 - Shorewall 1.2.1 Released

      - + +

      In version 1.2.1:

      - + + - +

      12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing 1.2 on 12/21/2001

      - -

      Version 1.2 contains the following new features:

      - - - -

      For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version 1.1.x users will not - be forced into a quick upgrade to 1.2.0 just to have access to bug -fixes.

      - -

      For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading to 1.2.0:

      - -
      -

      rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

      -
      - -

      12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror in Texas. This web - site is mirrored at http://www.infohiiway.com/shorewall and the ftp site -is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

      + +

      Version 1.2 contains the following new features:

      + + + + +

      For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version 1.1.x users will + not be forced into a quick upgrade to 1.2.0 just to have access + to bug fixes.

      + +

      For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading to 1.2.0:

      + +
      + +

      rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

      +
      + + +

      12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror in Texas. This + web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

      + +

      11/30/2001 - A new set of the parameterized Sample Configurations has been released. In this version:

      - + +
        -
      • Ping is now allowed between the zones.
        • -
      • In the three-interface configuration, it is now possible - to configure the internet services that are to be available to - servers in the DMZ. 
        • - +
      • Ping is now allowed between the zones.
        • +
      • In the three-interface configuration, +it is now possible to configure the internet services that +are to be available to servers in the DMZ. 
        • +
      - +

      11/20/2001 - The current version of Shorewall is 1.1.18. 

      - + +

      In this version:

      - + +
        -
      • The spelling of ADD_IP_ALIASES has been corrected -in the shorewall.conf file
        • -
      • The logic for deleting user-defined chains has been - simplified so that it avoids a bug in the LRP version of the 'cut' - utility.
        • -
      • The /var/lib/lrpkg/shorwall.conf file has been corrected - to properly display the NAT entry in that file.
        • - +
      • The spelling of ADD_IP_ALIASES has been + corrected in the shorewall.conf file
        • +
      • The logic for deleting user-defined chains + has been simplified so that it avoids a bug in the LRP version + of the 'cut' utility.
        • +
      • The /var/lib/lrpkg/shorwall.conf file +has been corrected to properly display the NAT entry in that +file.
        • +
      +

      11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall mirror in the Slovak - Republic. The website is now mirrored at , there is now a Shorewall mirror in the +Slovak Republic. The website is now mirrored at http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

      - + +

      11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. - There are three sample configurations:

      - + There are three sample configurations:

      + +
        -
      • One Interface -- for a standalone system.
        • -
      • Two Interfaces -- A masquerading firewall.
        • -
      • Three Interfaces -- A masquerading firewall with -DMZ.
        • - +
      • One Interface -- for a standalone system.
        • +
      • Two Interfaces -- A masquerading firewall.
        • +
      • Three Interfaces -- A masquerading firewall + with DMZ.
        • +
      - + +

      Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.

      + . See the README file for instructions.

      - +

      11/1/2001 - The current version of Shorewall is 1.1.17.  I intend - this to be the last of the 1.1 Shorewall releases.

      + this to be the last of the 1.1 Shorewall releases.

      - +

      In this version:

      - + + - +

      10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:

      - + version:

      + - +

      10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:

      - + version:

      +
        -
      • Support for nested zones has been improved. See the documentation for details
        • -
      • Shorewall now correctly checks the alternate configuration - directory for the 'zones' file.
        • - +
      • Support for nested zones has been improved. + See the documentation for + details
        • +
      • Shorewall now correctly checks the alternate + configuration directory for the 'zones' file.
        • +
      - +

      10/4/2001 - The current version of Shorewall is 1.1.14. In this - version

      - + version

      + - +

      9/12/2001 - The current version of Shorewall is 1.1.13. In this - version

      - + version

      +
        -
      • Shell variables can now be used to parameterize Shorewall - rules.
        • -
      • The second column in the hosts file may now contain - a comma-separated list.
        -
        - Example:
        -     sea    eth0:130.252.100.0/24,206.191.149.0/24
        • -
      • Handling of multi-zone interfaces has been improved. - See the documentation - for the /etc/shorewall/interfaces file.
        • - +
      • Shell variables can now be used to parameterize + Shorewall rules.
        • +
      • The second column in the hosts file may + now contain a comma-separated list.
        +
        + Example:
        +     sea    eth0:130.252.100.0/24,206.191.149.0/24
        • +
      • Handling of multi-zone interfaces has +been improved. See the documentation for the /etc/shorewall/interfaces + file.
        • +
      - +

      8/28/2001 - The current version of Shorewall is 1.1.12. In this - version

      - + version

      +
        -
      • Several columns in the rules file may now contain -comma-separated lists.
        • -
      • Shorewall is now more rigorous in parsing the options - in /etc/shorewall/interfaces.
        • -
      • Complementation using "!" is now supported in rules.
        • - +
      • Several columns in the rules file may +now contain comma-separated lists.
        • +
      • Shorewall is now more rigorous in parsing + the options in /etc/shorewall/interfaces.
        • +
      • Complementation using "!" is now supported + in rules.
        • +
      - +

      7/28/2001 - The current version of Shorewall is 1.1.11. In this - version

      - + version

      +
        -
      • A "shorewall refresh" command has been added to allow - for refreshing the rules associated with the broadcast address on - a dynamic interface. This command should be used in place of -"shorewall restart" when the internet interface's IP address changes.
        • -
      • The /etc/shorewall/start file (if any) is now processed - after all temporary rules have been deleted. This change prevents - the accidental removal of rules added during the processing of - that file.
        • -
      • The "dhcp" interface option is now applicable to -firewall interfaces used by a DHCP server running on the firewall.
        • -
      • The RPM can now be built from the .tgz file using -"rpm -tb" 
        • - +
      • A "shorewall refresh" command has been + added to allow for refreshing the rules associated with the + broadcast address on a dynamic interface. This command should + be used in place of "shorewall restart" when the internet interface's + IP address changes.
        • +
      • The /etc/shorewall/start file (if any) + is now processed after all temporary rules have been deleted. + This change prevents the accidental removal of rules added + during the processing of that file.
        • +
      • The "dhcp" interface option is now applicable + to firewall interfaces used by a DHCP server running on the + firewall.
        • +
      • The RPM can now be built from the .tgz + file using "rpm -tb" 
        • +
      - +

      7/6/2001 - The current version of Shorewall is 1.1.10. In this version

      - +
        -
      • Shorewall now enables Ipv4 Packet Forwarding by default. - Packet forwarding may be disabled by specifying IP_FORWARD=Off - in /etc/shorewall/shorewall.conf. If you don't want Shorewall -to enable or disable packet forwarding, add IP_FORWARDING=Keep -to your /etc/shorewall/shorewall.conf file.
        • -
      • The "shorewall hits" command no longer lists extraneous - service names in its last report.
        • -
      • Erroneous instructions in the comments at the head - of the firewall script have been corrected.
        • - +
      • Shorewall now enables Ipv4 Packet Forwarding + by default. Packet forwarding may be disabled by specifying + IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't + want Shorewall to enable or disable packet forwarding, add +IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf file.
        • +
      • The "shorewall hits" command no longer + lists extraneous service names in its last report.
        • +
      • Erroneous instructions in the comments + at the head of the firewall script have been corrected.
        • +
      - +

      6/23/2001 - The current version of Shorewall is 1.1.9. In this version

      - +
        -
      • The "tunnels" file really is in the RPM now.
        • -
      • SNAT can now be applied to port-forwarded connections.
        • -
      • A bug which would cause firewall start failures in - some dhcp configurations has been fixed.
        • -
      • The firewall script now issues a message if you have - the name of an interface in the second column in an entry in -/etc/shorewall/masq and that interface is not up.
        • -
      • You can now configure Shorewall so that it doesn't require the NAT and/or mangle -netfilter modules.
        • -
      • Thanks to Alex  Polishchuk, the "hits" command - from seawall is now in shorewall.
        • -
      • Support for IPIP tunnels has - been added.
        • - +
      • The "tunnels" file really is in + the RPM now.
        • +
      • SNAT can now be applied to port-forwarded + connections.
        • +
      • A bug which would cause firewall start + failures in some dhcp configurations has been fixed.
        • +
      • The firewall script now issues a message + if you have the name of an interface in the second column + in an entry in /etc/shorewall/masq and that interface is +not up.
        • +
      • You can now configure Shorewall so that + it doesn't require the NAT and/or + mangle netfilter modules.
        • +
      • Thanks to Alex  Polishchuk, the "hits" + command from seawall is now in shorewall.
        • +
      • Support for IPIP tunnels + has been added.
        • +
      - +

      6/18/2001 - The current version of Shorewall is 1.1.8. In this version

      - + - +

      6/2/2001 - The current version of Shorewall is 1.1.7. In this version

      - +
        -
      • The TOS rules are now deleted when the firewall is - stopped.
        • -
      • The .rpm will now install regardless of which version - of iptables is installed.
        • -
      • The .rpm will now install without iproute2 being -installed.
        • -
      • The documentation has been cleaned up.
        • -
      • The sample configuration files included in Shorewall - have been formatted to 80 columns for ease of editing on a -VGA console.
        • - +
      • The TOS rules are now deleted when the + firewall is stopped.
        • +
      • The .rpm will now install regardless +of which version of iptables is installed.
        • +
      • The .rpm will now install without iproute2 + being installed.
        • +
      • The documentation has been cleaned up.
        • +
      • The sample configuration files included + in Shorewall have been formatted to 80 columns for ease + of editing on a VGA console.
        • +
      - +

      5/25/2001 - The current version of Shorewall is 1.1.6. In this version

      - +
        -
      • You may now rate-limit - the packet log.
        • -
      •  Previous - versions of Shorewall have an implementation of Static NAT which - violates the principle of least surprise.  NAT only occurs for -packets arriving at (DNAT) or send from (SNAT) the interface named -in the INTERFACE column of /etc/shorewall/nat. Beginning with version -1.1.6, NAT effective regardless of which interface packets come from -or are destined to. To get compatibility with prior versions, I have -added a new "ALL "ALL INTERFACES"  column -to /etc/shorewall/nat. By placing "no" or "No" in the new column, - the NAT behavior of prior versions may be retained. 
        • -
      • The treatment of IPSEC - Tunnels where the remote gateway is a standalone system has been - improved. Previously, it was necessary to include an additional - rule allowing UDP port 500 traffic to pass through the tunnel. -Shorewall will now create this rule automatically when you place -the name of the remote peer's zone in a new GATEWAY ZONE column in -/etc/shorewall/tunnels. 
        • - +
      • You + may now rate-limit the packet log.
        • +
      •  Previous versions of + Shorewall have an implementation of Static NAT which violates the + principle of least surprise.  NAT only occurs for packets + arriving at (DNAT) or send from (SNAT) the interface named +in the INTERFACE column of /etc/shorewall/nat. Beginning with +version 1.1.6, NAT effective regardless of which interface packets +come from or are destined to. To get compatibility with prior versions, +I have added a new "ALL "ALL INTERFACES"  + column to /etc/shorewall/nat. By placing "no" or "No" in +the new column, the NAT behavior of prior versions may be retained. 
        • +
      • The treatment of IPSEC Tunnels where the remote gateway +is a standalone system has been improved. Previously, it was + necessary to include an additional rule allowing UDP port 500 traffic +to pass through the tunnel. Shorewall will now create this rule +automatically when you place the name of the remote peer's zone in +a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
        • +
      - +

      5/20/2001 - The current version of Shorewall is 1.1.5. In this version

      - + - +

      5/10/2001 - The current version of Shorewall is 1.1.4. In this version

      - +
        -
      • Accepting RELATED - connections is now optional.
        • -
      • Corrected problem where if "shorewall start" aborted - early (due to kernel configuration errors for example), superfluous - 'sed' error messages were reported.
        • -
      • Corrected rules generated for port redirection.
        • -
      • The order in which iptables kernel modules are loaded - has been corrected (Thanks to Mark Pavlidis). 
        • - +
      • Accepting + RELATED connections is now optional.
        • +
      • Corrected problem where if "shorewall +start" aborted early (due to kernel configuration errors for +example), superfluous 'sed' error messages were reported.
        • +
      • Corrected rules generated for port redirection.
        • +
      • The order in which iptables kernel modules + are loaded has been corrected (Thanks to Mark Pavlidis). 
        • +
      - +

      4/28/2001 - The current version of Shorewall is 1.1.3. In this version

      - +
        -
      • Correct message issued when Proxy ARP address added - (Thanks to Jason Kirtland).
        • -
      • /tmp/shorewallpolicy-$$ is now removed if there is - an error while starting the firewall.
        • -
      • /etc/shorewall/icmp.def and /etc/shorewall/common.def - are now used to define the icmpdef and common chains unless overridden - by the presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
        • -
      • In the .lrp, the file /var/lib/lrpkg/shorwall.conf - has been corrected. An extra space after "/etc/shorwall/policy" -has been removed and "/etc/shorwall/rules" has been added.
        • -
      • When a sub-shell encounters a fatal error and has -stopped the firewall, it now kills the main shell so that the main -shell will not continue.
        • -
      • A problem has been corrected where a sub-shell stopped - the firewall and main shell continued resulting in a perplexing -error message referring to "common.so" resulted.
        • -
      • Previously, placing "-" in the PORT(S) column in - /etc/shorewall/rules resulted in an error message during start. -This has been corrected.
        • -
      • The first line of "install.sh" has been corrected --- I had inadvertently deleted the initial "#".
        • - +
      • Correct message issued when Proxy ARP +address added (Thanks to Jason Kirtland).
        • +
      • /tmp/shorewallpolicy-$$ is now removed + if there is an error while starting the firewall.
        • +
      • /etc/shorewall/icmp.def and /etc/shorewall/common.def + are now used to define the icmpdef and common chains unless + overridden by the presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
        • +
      • In the .lrp, the file /var/lib/lrpkg/shorwall.conf + has been corrected. An extra space after "/etc/shorwall/policy" + has been removed and "/etc/shorwall/rules" has been added.
        • +
      • When a sub-shell encounters a fatal error + and has stopped the firewall, it now kills the main shell so + that the main shell will not continue.
        • +
      • A problem has been corrected where a +sub-shell stopped the firewall and main shell continued resulting +in a perplexing error message referring to "common.so" resulted.
        • +
      • Previously, placing "-" in the PORT(S) + column in /etc/shorewall/rules resulted in an error message +during start. This has been corrected.
        • +
      • The first line of "install.sh" has been + corrected -- I had inadvertently deleted the initial "#".
        • +
      - +

      4/12/2001 - The current version of Shorewall is 1.1.2. In this version

      - +
        -
      • Port redirection now works again.
        • -
      • The icmpdef and common chains Port redirection now works again.
        • +
      • The icmpdef and common chains may now be user-defined.
        • -
      • The firewall no longer fails to start if "routefilter" - is specified for an interface that isn't started. A warning message - is now issued in this case.
        • -
      • The LRP Version is renamed "shorwall" for 8,3 MSDOS - file system compatibility.
        • -
      • A couple of LRP-specific problems were corrected.
        • - +
      • The firewall no longer fails to start +if "routefilter" is specified for an interface that isn't +started. A warning message is now issued in this case.
        • +
      • The LRP Version is renamed "shorwall" +for 8,3 MSDOS file system compatibility.
        • +
      • A couple of LRP-specific problems were + corrected.
        • +
      - +

      4/8/2001 - Shorewall is now affiliated with the Leaf Project -

      - +

      +

      4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

      - +
        -
      • The common chain is traversed from INPUT, OUTPUT -and FORWARD before logging occurs
        • -
      • The source has been cleaned up dramatically
        • -
      • DHCP DISCOVER packets with RFC1918 source addresses - no longer generate log messages. Linux DHCP clients generate such - packets and it's annoying to see them logged. 
        • - +
      • The common chain is traversed from INPUT, + OUTPUT and FORWARD before logging occurs
        • +
      • The source has been cleaned up dramatically
        • +
      • DHCP DISCOVER packets with RFC1918 source + addresses no longer generate log messages. Linux DHCP clients + generate such packets and it's annoying to see them logged. 
        • +
      - +

      3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

      - +
        -
      • Log messages now indicate the packet disposition.
        • -
      • Error messages have been improved.
        • -
      • The ability to define zones consisting of an enumerated - set of hosts and/or subnetworks has been added.
        • -
      • The zone-to-zone chain matrix is now sparse so that - only those chains that contain meaningful rules are defined.
        • -
      • 240.0.0.0/4 and 169.254.0.0/16 have been added to -the source subnetworks whose packets are dropped under the norfc1918 - interface option.
        • -
      • Exits are now provided for executing an user-defined - script when a chain is defined, when the firewall is initialized, - when the firewall is started, when the firewall is stopped and - when the firewall is cleared.
        • -
      • The Linux kernel's route filtering facility can now - be specified selectively on network interfaces.
        • - +
      • Log messages now indicate the packet +disposition.
        • +
      • Error messages have been improved.
        • +
      • The ability to define zones consisting + of an enumerated set of hosts and/or subnetworks has been + added.
        • +
      • The zone-to-zone chain matrix is now +sparse so that only those chains that contain meaningful +rules are defined.
        • +
      • 240.0.0.0/4 and 169.254.0.0/16 have been + added to the source subnetworks whose packets are dropped + under the norfc1918 interface option.
        • +
      • Exits are now provided for executing +an user-defined script when a chain is defined, when the +firewall is initialized, when the firewall is started, when +the firewall is stopped and when the firewall is cleared.
        • +
      • The Linux kernel's route filtering facility + can now be specified selectively on network interfaces.
        • +
      - +

      3/19/2001 - The current version of Shorewall is 1.0.4. This version:

      - +
        -
      • Allows user-defined zones. Shorewall now has only -one pre-defined zone (fw) with the remaining zones being defined -in the new configuration file /etc/shorewall/zones. The /etc/shorewall/zones - file released in this version provides behavior that is compatible - with Shorewall 1.0.3. 
        • -
      • Adds the ability to specify logging in entries in -the /etc/shorewall/rules file.
        • -
      • Correct handling of the icmp-def chain so that only - ICMP packets are sent through the chain.
        • -
      • Compresses the output of "shorewall monitor" if awk - is installed. Allows the command to work if awk isn't installed -(although it's not pretty).
        • - +
      • Allows user-defined zones. Shorewall +now has only one pre-defined zone (fw) with the remaining +zones being defined in the new configuration file /etc/shorewall/zones. + The /etc/shorewall/zones file released in this version +provides behavior that is compatible with Shorewall 1.0.3. 
        • +
      • Adds the ability to specify logging in + entries in the /etc/shorewall/rules file.
        • +
      • Correct handling of the icmp-def chain + so that only ICMP packets are sent through the chain.
        • +
      • Compresses the output of "shorewall monitor" + if awk is installed. Allows the command to work if awk isn't + installed (although it's not pretty).
        • +
      - +

      3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix - release with no new features.

      - + release with no new features.

      +
        -
      • The PATH variable in the firewall script now includes - /usr/local/bin and /usr/local/sbin.
        • -
      • DMZ-related chains are now correctly deleted if the - DMZ is deleted.
        • -
      • The interface OPTIONS for "gw" interfaces are no -longer ignored.
        • - +
      • The PATH variable in the firewall script + now includes /usr/local/bin and /usr/local/sbin.
        • +
      • DMZ-related chains are now correctly +deleted if the DMZ is deleted.
        • +
      • The interface OPTIONS for "gw" interfaces + are no longer ignored.
        • +
      - +

      3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for tunnels and it supports IPSEC - tunnels with end-points on the firewall. There is also a .lrp available - now.

      - -

      Updated 11/24/2002 - Tom Eastep -

      - + additional "gw" (gateway) zone for tunnels and it supports + IPSEC tunnels with end-points on the firewall. There is also +a .lrp available now.

      + +

      Updated 12/27/2002 - Tom Eastep +

      +

      Copyright -© 2001, 2002 Thomas M. Eastep.

      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      +© 2001, 2002 Thomas M. Eastep.
      +


      diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm index 9de177b80..dc947d50f 100644 --- a/Shorewall-docs/Shorewall_index_frame.htm +++ b/Shorewall-docs/Shorewall_index_frame.htm @@ -2,140 +2,141 @@ - + - + - + - + Shorewall Index - - + + - + - - - + + - - - + + + - + + - - + +
      +
      - +

      Shorewall

      -
      +
      - + - + -
      - -
      -
      - Note:       Search is unavailable Daily 0200-0330 - GMT.
      - - + + +
      + Note:       Search is unavailable Daily 0200-0330 + GMT.
      + +

      Quick Search
      -

      - +
      - +

      Extended Search

      - +

      Copyright © 2001, 2002 Thomas M. Eastep.

      - +

      -
      -
      -

      +
      +
      +

      +



      diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm index f554fd4cb..dcb22fac4 100644 --- a/Shorewall-docs/Shorewall_sfindex_frame.htm +++ b/Shorewall-docs/Shorewall_sfindex_frame.htm @@ -2,134 +2,143 @@ + + + + Shorewall Index - - + + - + - - - + + - - - + + + - + + - + +
      +
      - +

      Shorewall

      -
      +
      - + - + -
      - -
      -
      - Note:       Search is unavailable Daily 0200-0330 - GMT.
      - + + +
      + Note:       Search is unavailable Daily 0200-0330 + GMT.
      + +

      Quick Search
      -

      - -
      - + + +

      Extended Search

      - +

      Copyright © 2001, 2002 Thomas M. Eastep.

      - -

      -
      -
      -

      + +


      +

      +
      +
      +


      diff --git a/Shorewall-docs/VPN.htm b/Shorewall-docs/VPN.htm index d18deab54..893839efc 100755 --- a/Shorewall-docs/VPN.htm +++ b/Shorewall-docs/VPN.htm @@ -1,81 +1,104 @@ + - - - - - -VPN + + + + + + + + + VPN - - - - - - - + + +
      -

      VPN

      -
      + + + + + +
      +

      VPN

      +
      -

      It is often the case that a system behind the firewall needs to be able to -access a remote network through Virtual Private Networking (VPN). The two most -common means for doing this are IPSEC and PPTP. The basic setup is shown in the -following diagram:

      -

      -

      A system with an RFC 1918 address needs to access a remote -network through a remote gateway. For this example, we will assume that the -local system has IP address 192.168.1.12 and that the remote gateway has IP -address 192.0.2.224.

      -

      If PPTP is being used, there are no firewall requirements beyond -the default loc->net ACCEPT policy. There is one restriction however: Only one -local system at a time can be connected to a single remote gateway unless you -patch your kernel from the 'Patch-o-matic' patches available at -http://www.netfilter.org.

      -

      If IPSEC is being used then there are firewall configuration -requirements as follows:

      -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +

      It is often the case that a system behind the firewall needs to be able +to access a remote network through Virtual Private Networking (VPN). The +two most common means for doing this are IPSEC and PPTP. The basic setup +is shown in the following diagram:

      + +

      +

      + +

      A system with an RFC 1918 address needs to access a remote + network through a remote gateway. For this example, we will assume that +the local system has IP address 192.168.1.12 and that the remote gateway +has IP address 192.0.2.224.

      + +

      If PPTP is being used, there are no firewall requirements +beyond the default loc->net ACCEPT policy. There is one restriction however: +Only one local system at a time can be connected to a single remote gateway +unless you patch your kernel from the 'Patch-o-matic' patches available +at http://www.netfilter.org.

      + +

      If IPSEC is being used then only one system may connect to +the remote gateway and there are firewall configuration requirements as +follows:

      + +
      +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCLIENT
      - PORT      		ORIGINAL
      - DEST
      DNATnet:192.0.2.224loc:192.168.1.1250   
      DNATnet:192.0.2.224loc:192.168.1.12udp500  
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTCLIENT
      + PORT      		ORIGINAL
      + DEST
      DNATnet:192.0.2.224loc:192.168.1.1250   
      DNATnet:192.0.2.224loc:192.168.1.12udp500  
      -
      -

      If you want to be able to give access to all of your local systems to the -remote network, you should consider running a VPN client on your firewall. As -starting points, see - -http://www.shorewall.net/Documentation.htm#Tunnels or -http://www.shorewall.net/PPTP.htm.

      -

      Last modified 8/27/2002 - Tom -Eastep

      -Copyright © 2002 Thomas M. Eastep.

       

      - + + +

      If you want to be able to give access to all of your local systems to +the remote network, you should consider running a VPN client on your firewall. +As starting points, see http://www.shorewall.net/Documentation.htm#Tunnels +or http://www.shorewall.net/PPTP.htm.

      + +

      Last modified 12/21/2002 - Tom Eastep

      +

      Copyright +© 2002 Thomas M. Eastep.

      +

       

      +
      - diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm index 87ca850e3..cfb645017 100644 --- a/Shorewall-docs/configuration_file_basics.htm +++ b/Shorewall-docs/configuration_file_basics.htm @@ -1,320 +1,435 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
      +
      +

      Configuration Files

      -
      - +

      Warning: If you copy or edit your configuration files on a system running Microsoft Windows, you must - run them through dos2unix - before you use them with Shorewall.

      - + before you use them with Shorewall.

      +

      Files

      - +

      Shorewall's configuration files are in the directory /etc/shorewall.

      - +
        -
      • /etc/shorewall/shorewall.conf - used to set several firewall - parameters.
        • -
      • /etc/shorewall/params - use this file to set shell variables - that you will expand in other files.
        • -
      • /etc/shorewall/zones - partition the firewall's view of -the world into zones.
        • -
      • /etc/shorewall/policy - establishes firewall high-level -policy.
        • -
      • /etc/shorewall/interfaces - describes the interfaces on -the firewall system.
        • -
      • /etc/shorewall/hosts - allows defining zones in terms of - individual hosts and subnetworks.
        • -
      • /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).
        • -
      • /etc/shorewall/modules - directs the firewall to load kernel - modules.
        • -
      • /etc/shorewall/rules - defines rules that are exceptions - to the overall policies established in /etc/shorewall/policy.
        • -
      • /etc/shorewall/nat - defines static NAT rules.
        • -
      • /etc/shorewall/proxyarp - defines use of Proxy ARP.
        • -
      • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) -- defines hosts accessible when Shorewall is stopped.
        • -
      • /etc/shorewall/tcrules - defines marking of packets for -later use by traffic control/shaping or policy routing.
        • -
      • /etc/shorewall/tos - defines rules for setting the TOS -field in packet headers.
        • -
      • /etc/shorewall/tunnels - defines IPSEC, GRE and IPIP tunnels - with end-points on the firewall system.
        • -
      • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC - addresses.
        • - +
      • /etc/shorewall/shorewall.conf - used to set several + firewall parameters.
        • +
      • /etc/shorewall/params - use this file to set shell + variables that you will expand in other files.
        • +
      • /etc/shorewall/zones - partition the firewall's +view of the world into zones.
        • +
      • /etc/shorewall/policy - establishes firewall high-level + policy.
        • +
      • /etc/shorewall/interfaces - describes the interfaces + on the firewall system.
        • +
      • /etc/shorewall/hosts - allows defining zones in +terms of individual hosts and subnetworks.
        • +
      • /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).
        • +
      • /etc/shorewall/modules - directs the firewall to + load kernel modules.
        • +
      • /etc/shorewall/rules - defines rules that are exceptions + to the overall policies established in /etc/shorewall/policy.
        • +
      • /etc/shorewall/nat - defines static NAT rules.
        • +
      • /etc/shorewall/proxyarp - defines use of Proxy +ARP.
        • +
      • /etc/shorewall/routestopped (Shorewall 1.3.4 and + later) - defines hosts accessible when Shorewall is stopped.
        • +
      • /etc/shorewall/tcrules - defines marking of packets + for later use by traffic control/shaping or policy routing.
        • +
      • /etc/shorewall/tos - defines rules for setting +the TOS field in packet headers.
        • +
      • /etc/shorewall/tunnels - defines IPSEC, GRE and +IPIP tunnels with end-points on the firewall system.
        • +
      • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC + addresses.
        • +
      • /etc/shorewall/init - commands that you wish to execute at the beginning +of a "shorewall start" or "shorewall restart".
        • +
      • /etc/shorewall/start - commands that you wish to execute at the completion +of a "shorewall start" or "shorewall restart"
        • +
      • /etc/shorewall/stop - commands that you wish to execute at the beginning +of a "shorewall stop".
        • +
      • /etc/shorewall/stopped - commands that you wish to execute at the +completion of a "shorewall stop".
        +
        • +
      - +

      Comments

      - +

      You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at the -end of any line, again by delimiting the comment from the rest of -the line with a pound sign.

      - + character a pound sign ("#"). You may also place comments at +the end of any line, again by delimiting the comment from the rest +of the line with a pound sign.

      +

      Examples:

      - + 
      # This is a comment
      - -
      ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
      - -

      Line Continuation

      - -

      You may continue lines in the configuration files using the usual backslash - ("\") followed immediately by a new line character.

      - -

      Example:

      - -
      ACCEPT	net	fw	tcp \
      smtp,www,pop3,imap  #Services running on the firewall
      - -

      Using DNS Names

      - -

      - -

      WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS names -and you are called out of bed at 2:00AM because Shorewall won't start as -a result of DNS problems then don't say that you were not forewarned.
      -

      - -

          -Tom
      -

      - -

      Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified either as IP addresses or as DNS Names.
      -
      - 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 change in the DNS->IP address relationship that occur after the firewall - has started have absolutely no effect on the firewall's ruleset.

      - -

      If your firewall rules include DNS names then:

      - -
        -
      • If your /etc/resolv.conf is wrong then your firewall won't - start.
        • -
      • If your /etc/nsswitch.conf is wrong then your firewall won't - start.
        • -
      • If your Name Server(s) is(are) down then your firewall won't - start.
        • -
      • If your startup scripts try to start your firewall before starting - your DNS server then your firewall won't start.
        -
        • -
      • Factors totally outside your control (your ISP's router is - down for example), can prevent your firewall from starting.
        • -
      • You must bring up your network interfaces prior to starting your - firewall.
        -
        • - -
      - -

      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.
      -
      - Examples of valid DNS names:
      -

      - -
        -
      • mail.shorewall.net
        • -
      • shorewall.net.
        • - -
      - Examples of invalid DNS names:
      - -
        -
      • mail (not fully qualified)
        • -
      • shorewall.net (only one period)
        • - -
      - DNS names may not be used as:
      - -
        -
      • The server address in a DNAT rule (/etc/shorewall/rules file)
        • -
      • In the ADDRESS column of an entry in /etc/shorewall/masq.
        • -
      • In the /etc/shorewall/nat file.
        • - -
      - These are iptables restrictions and are not simply imposed for your -inconvenience by Shorewall.
      -
      - -

      Complementing an Address or Subnet

      +
      ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
      + +

      Line Continuation

      + +

      You may continue lines in the configuration files using the usual backslash + ("\") followed immediately by a new line character.

      + +

      Example:

      + +
      ACCEPT	net	fw	tcp \
      smtp,www,pop3,imap  #Services running on the firewall
      + +

      Using DNS Names

      + +

      + +

      WARNING: I personally recommend strongly against + using DNS names in Shorewall configuration files. If you use DNS names + and you are called out of bed at 2:00AM because Shorewall won't start + as a result of DNS problems then don't say that you were not forewarned. +
      +

      + +

          -Tom
      +

      + +

      Beginning with Shorwall 1.3.9, Host addresses in Shorewall + configuration files may be specified as either IP addresses or DNS + Names.
      +
      + 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->IP address relationship that +occur after the firewall has started have absolutely no effect on the + firewall's ruleset.

      + +

      If your firewall rules include DNS names then:

      + +
        +
      • If your /etc/resolv.conf is wrong then your firewall won't + start.
        • +
      • If your /etc/nsswitch.conf is wrong then your firewall +won't start.
        • +
      • If your Name Server(s) is(are) down then your firewall +won't start.
        • +
      • If your startup scripts try to start your firewall before + starting your DNS server then your firewall won't start.
        +
        • +
      • Factors totally outside your control (your ISP's router + is down for example), can prevent your firewall from starting.
        • +
      • You must bring up your network interfaces prior to starting + your firewall.
        +
        • + +
      + +

      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.
      +
      + Examples of valid DNS names:
      +

      + +
        +
      • mail.shorewall.net
        • +
      • shorewall.net. (note the trailing period).
        • + +
      + Examples of invalid DNS names:
      + +
        +
      • mail (not fully qualified)
        • +
      • shorewall.net (only one period)
        • + +
      + DNS names may not be used as:
      + +
        +
      • The server address in a DNAT rule (/etc/shorewall/rules + file)
        • +
      • In the ADDRESS column of an entry in /etc/shorewall/masq.
        • +
      • In the /etc/shorewall/nat file.
        • + +
      + These restrictions are not imposed by Shorewall simply for +your inconvenience but are rather limitations of iptables.
      + +

      Complementing an Address or Subnet

      +

      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 "!".

      - +

      Comma-separated Lists

      - +

      Comma-separated lists are allowed in a number of contexts within the configuration files. A comma separated list:

      - +
        -
      • Must not have any embedded white space.
        - Valid: routestopped,dhcp,norfc1918
        - Invalid: routestopped,     dhcp,     norfc1818
        • -
      • 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)
        • -
      • Entries in a comma-separated list may appear in any order.
        • - +
      • Must not have any embedded white space.
        + Valid: routestopped,dhcp,norfc1918
        + Invalid: routestopped,     dhcp,     norfc1818
        • +
      • 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)
        • +
      • Entries in a comma-separated list may appear in +any order.
        • +
      - +

      Port Numbers/Service Names

      - +

      Unless otherwise specified, when giving a port number you can use either an integer or a service name from /etc/services.

      - +

      Port Ranges

      - +

      If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. 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:
      -

      - + port number>:<high port number>. 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:
      +

      + 
           DNAT	net	loc:192.168.1.3	tcp	4000:4100
      - +

      Using Shell Variables

      - +

      You may use the /etc/shorewall/params file to set shell variables that you can then use in some of the other configuration files.

      - +

      It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

      - + within the Shorewall programs

      +

      Example:

      - -
      + +
      + 
      NET_IF=eth0
      NET_BCAST=130.252.100.255
      NET_OPTIONS=noping,norfc1918
      -
      - +
      +


      - Example (/etc/shorewall/interfaces record):

      - -
      + Example (/etc/shorewall/interfaces record):

      + + +
      + 
      net $NET_IF $NET_BCAST $NET_OPTIONS
      -
      -       - +
      +       +

      The result will be the same as if the record had been written

      - -
      + + +
      + 
      net eth0 130.252.100.255 noping,norfc1918
      -
      -       - +
      +       +

      Variables may be used anywhere in the other configuration - files.

      - + files.

      +

      Using MAC Addresses

      - +

      Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this feature, - your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) - included.

      - + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + included.

      +

      MAC addresses are 48 bits wide and each Ethernet Controller has a unique MAC address.
      -
      - In GNU/Linux, MAC addresses are usually written as a series of - 6 hex numbers separated by colons. Example:
      -
      -      [root@gateway root]# ifconfig eth0
      -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
      -      inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
      -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      -      RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
      -      TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
      -      collisions:30394 txqueuelen:100
      -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 - Mb)
      -      Interrupt:11 Base address:0x1800
      -
      - 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".
      -

      - +
      + In GNU/Linux, MAC addresses are usually written as a +series of 6 hex numbers separated by colons. Example:
      +
      +      [root@gateway root]# ifconfig eth0
      +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
      +      inet addr:206.124.146.176 Bcast:206.124.146.255 + Mask:255.255.255.0
      +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      +      RX packets:2398102 errors:0 dropped:0 overruns:0 + frame:0
      +      TX packets:3044698 errors:0 dropped:0 overruns:0 + carrier:0
      +      collisions:30394 txqueuelen:100
      +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + (1582.8 Mb)
      +      Interrupt:11 Base address:0x1800
      +
      + 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".
      +

      +

      Note: It is not necessary to use the special Shorewall notation -in the /etc/shorewall/maclist file.
      -

      - -

      Shorewall Configurations

      - -

      Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start and restart - 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.

      - -

      This facility permits you to easily create a test or temporary configuration - by:

      - + in the /etc/shorewall/maclist file.
      +

      + +

      Logging

      + By default, Shorewall directs NetFilter to log using syslog (8). Syslog + classifies log messages by a facility and a priority (using + the notation facility.priority).
      +
      + The facilities defined by syslog are auth, authpriv, cron, daemon, +kern, lpr, mail, mark, news, syslog, user, uucp and local0 through +local7.
      +
      + Throughout the Shorewall documentation, I will use the term level + rather than priority since level is the term used by NetFilter. + The syslog documentation uses the term priority.
      + +

      Syslog Levels
      +

      + 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.
      +
      + Valid levels are:
      +
      +        7       debug
      +        6       info
      +        5       notice
      +        4       warning
      +        3       err
      +        2       crit
      +        1       alert
      +        0       emerg
      +
      + For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall + log messages are generated by NetFilter and are logged using the kern + 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.
      +
      + 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.
      + +

      Configuring a Separate Log for Shorewall Messages

      + There are a couple of limitations to syslogd-based logging:
      +
        -
      1. copying the files that need modification from /etc/shorewall - to a separate directory;
        2. -
      2. modify those files in the separate directory; and
        3. -
      3. specifying the separate directory in a shorewall start - or shorewall restart command (e.g., shorewall -c /etc/testconfig - restart ).
        4. - +
      4. 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).
        5. +
      5. All kernel.info messages will go to that destination and not just + those from NetFilter.
        +
        6. + +
      + 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.
      +
      + Download the ulod tar file and:
      + +
        +
      1. cd /usr/local/src (or wherever you do your builds)
        2. +
      2. tar -zxf source-tarball-that-you-downloaded
        3. +
      3. cd ulogd-version
        +
        4. +
      4. ./configure
        5. +
      5. make
        6. +
      6. make install
        +
        7. + +
      + 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-version +directory and move it to your firewall system.
      +
      + Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
      + +
        +
      1. syslogfile <file that you wish to log to>
        2. +
      2. syslogsync 1
        3. + +
      + I also copied the file /usr/local/src/ulogd-version/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.
      +
      + Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file that +you wish to log to>. This tells the /sbin/shorewall program where to +look for the log when processing its "show log", "logwatch" and "monitor" +commands.
      + +

      Shorewall Configurations

      + +

      Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start and + restart 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.

      + +

      This facility permits you to easily create a test or temporary configuration + by:

      + +
        +
      1. copying the files that need modification from +/etc/shorewall to a separate directory;
        2. +
      2. modify those files in the separate directory; +and
        3. +
      3. specifying the separate directory in a shorewall + start or shorewall restart command (e.g., shorewall -c /etc/testconfig + restart ).
        4. +
      - -

      Updated 11/21/2002 - Tom Eastep -

      + +

      Updated 12/20/2002 - Tom Eastep +

      - +

      Copyright - © 2001, 2002 Thomas M. Eastep.

      - - -
      -
      -
      -
      + © 2001, 2002 Thomas M. Eastep.
      +



      diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm index 479917401..cb46fa42b 100644 --- a/Shorewall-docs/download.htm +++ b/Shorewall-docs/download.htm @@ -1,395 +1,387 @@ - + - + - + - + Download - + - - - + + - - - + + + +
      - +
      +

      Shorewall Download

      -
      - +

      I strongly urge you to read and print a copy of the Shorewall QuickStart Guide - for the configuration that most closely matches your own.

      - -

      Once you've done that, download one of the modules:

      - + href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide + for the configuration that most closely matches your own.
      +

      + +

      The entire set of Shorewall documentation is available in PDF format at:

      + +

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      +     http://slovakia.shorewall.net/pub/shorewall/pdf/
      +     rsync://slovakia.shorewall.net/shorewall/pdf/ +

      + +

      The documentation in HTML format is included in the .rpm and in the .tgz +packages below.

      + +

      Once you've done that, download one of the modules:

      +
        -
      • If you run a RedHat, SuSE, Mandrake, - Linux PPC or TurboLinux 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 me know so that - I can mention them here. See the Installation Instructions - if you have problems installing the RPM.
        • -
      • 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).
        • -
      • If you run Debian - and would like a .deb package, Shorewall is in both the Debian -Testing Branch and the Debian - Unstable Branch.
        • -
      • Otherwise, download the shorewall module - (.tgz)
        • - +
      • If you run a RedHat, SuSE, Mandrake, + Linux PPC or TurboLinux 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 me know so that + I can mention them here. See the Installation Instructions + if you have problems installing the RPM.
        • +
      • 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).
        • +
      • If you run Debian + and would like a .deb package, Shorewall is included in both the + Debian + Testing Branch and the Debian +Unstable Branch.
        • +
      • Otherwise, download the shorewall +module (.tgz)
        • +
      - -

      The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.

      - -

      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.

      - + +

      The documentation in HTML format is included in the .tgz and .rpm files + and there is an documentation .deb that also contains the documentation.

      + +

      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.

      +
        -
      • RPM - "rpm -qip LATEST.rpm"
        • -
      • TARBALL - "tar -ztf LATEST.tgz" (the directory name will - contain the version)
        • -
      • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar -zxf -<downloaded .lrp>; cat var/lib/lrpkg/shorwall.version"
        • - +
      • RPM - "rpm -qip LATEST.rpm"
        • +
      • TARBALL - "tar -ztf LATEST.tgz" (the directory name + will contain the version)
        • +
      • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar +-zxf <downloaded .lrp>; cat var/lib/lrpkg/shorwall.version"
        • +
      - -

      Once you have verified the version, check the - errata to see if there are updates that apply to the version - that you have downloaded.

      - -

      WARNING - YOU CAN NOT 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.

      - -

      Download Latest Version (1.3.10): Remember that updates -to the mirrors occur 1-12 hours after an update to the primary site.

      - -
      + +

      Once you have verified the version, check the + errata to see if there are updates that apply to the version + that you have downloaded.

      + +

      WARNING - YOU CAN NOT 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.

      + +

      Download Latest Version (1.3.12): Remember that updates + to the mirrors occur 1-12 hours after an update to the Washington +State site.

      + +
      - - - - - - - - - - - + + + + + + + + + - - - - - - + + + + + - - - - - - - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + - - - - + Download + .md5sums + + + + + + + + + + + + + + + + + + + + + +
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      -       		sf.net
      -       		+
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      +       		sf.net
      +       		Download
      -
      -
      Slovak RepublicShorewall.net +
      +
      Slovak RepublicShorewall.netDownload .rpm
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .rpm
      - - Download.md5sums
      Texas, USAInfohiiway.comDownload - .rpm
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums      		 Download + .tgz 
      + Download + .lrp
      + + Download.md5sums      		 Download + .rpm  
      + Download + .tgz 
      + Download + .rpm
      + + Download.md5sums
      Texas, USAInfohiiway.comDownload + .rpm
      + Download + .tgz 
      + Download + .lrp
      + + Download.md5sums      		 Download .rpm  
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums
      Hamburg, GermanyShorewall.net Download - .rpm
      - Download - .tgz
      - Download - .lrp
      - - Download.md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download - .rpm  
      - Download - .tgz 
      - - Download .lrp
      - Download -.md5sums      		 Download - .rpm  
      - Download - .tgz 
      - - Download .lrp
      - Download -.md5sums
      Paris, FranceShorewall.netDownload - .rpm
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      Washington State, USA
      -       		Shorewall.net
      -       		Download .rpm
      - Download + Download + .tgz 
      + Download + .lrp
      + + Download.md5sums
      Hamburg, GermanyShorewall.net Download + .rpm
      + Download + .tgz
      + Download + .lrp
      + + Download.md5sums      		 Download + .rpm  
      + Download .tgz 
      - Download + Download .lrp
      - Download - .md5sums
      -       		- Download .rpm 
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      -
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download + .rpm  
      + Download + .tgz 
      + + Download .lrp
      + Download + .md5sums      		 Download + .rpm  
      + Download + .tgz 
      + + Download .lrp
      + Download + .md5sums
      Paris, FranceShorewall.netDownload .rpm
      + Download .tgz 
      + Download .lrp
      + Download + .md5sums      		 Download + .rpm  
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      Washington State, USA
      +       		Shorewall.net
      +       		Download .rpm
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      +       		+ Download .rpm 
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      +
      -
      - -

      Documentation in PDF format:
      -

      - -
      -

      Juraj Ontkanin has produced a Portable Document Format (PDF) file containing -the Shorewall 1.3.10 documenation (the documentation in HTML format is included -in the .rpm and in the .tgz). The .pdf may be downloaded from

      -
      - -
      -
      ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      - http://slovakia.shorewall.net/pub/shorewall/pdf/
      -
      -
      - +
      +

      Browse Download Sites:

      - -
      + +
      - - - - - - - - - - - + + + + + + + + + - - - - - - + + + + + - - - - - - + + + - - - - - - - + + + + - - - - - + + + - - - - - - + + + - - - - - - - + + + + - - - + + + +
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      -       		sf.net +
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      +       		sf.netBrowseN/A
      Slovak RepublicShorewall.netN/A
      Slovak RepublicShorewall.netBrowse Browse
      Texas, USAInfohiiway.com +
      Texas, USAInfohiiway.comBrowseBrowse
      Hamburg, GermanyShorewall.netBrowse +
      Hamburg, GermanyShorewall.netBrowseBrowse
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar +
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
      FranceShorewall.net +
      FranceShorewall.netBrowse Browse
      Washington State, USAShorewall.netBrowse +
      Washington State, USAShorewall.netBrowseBrowse
      -
      - +
      +

      CVS:

      - -
      + +

      The CVS repository at - cvs.shorewall.net contains the latest snapshots of the each Shorewall - component. There's no guarantee that what you find there will work at - all.
      -

      -
      - -

      Last Updated 11/11/2002 - CVS repository at + cvs.shorewall.net contains the latest snapshots of the each Shorewall + component. There's no guarantee that what you find there will work at + all.
      +

      +
      + +

      Last Updated 12/12/2002 - Tom Eastep

      - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      -
      -
      -
      -
      -
      -
      -
      -
      + +

      Copyright + © 2001, 2002 Thomas M. Eastep.
      +


      diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm index bfba7872f..f9bc052e0 100644 --- a/Shorewall-docs/errata.htm +++ b/Shorewall-docs/errata.htm @@ -1,175 +1,214 @@ - + Shorewall 1.3 Errata + - + - + - + - - - + + - - - + + + +
      - +
      +

      Shorewall Errata/Upgrade Issues

      -
      - +

      IMPORTANT

      - +
        -
      1. +
      2. +

        If you use a Windows system to download - a corrected script, be sure to run the script through - + dos2unix after you have moved - it to your Linux system.

        -
        3. -
      3. + it to your Linux system.

        +
        4. +
      4. +

        If you are installing Shorewall for the first time and plan to use the .tgz and install.sh script, you can untar the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

        -
        5. -
      5. + with the one you downloaded below, and then run install.sh.

        +
        6. +
      6. +

        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.

        -
        7. -
      7. + 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.

        +
        8. +

      8. 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.
        -

        -
        9. - + 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.
        +

        + +
      - + - -
      + +

      Problems in Version 1.3

      - -

      Version 1.3.10

      - + +

      Version 1.3.11a

        -
      • If you experience problems connecting to a PPTP server running on -your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, - this -version of the firewall script may help. Please report any cases where -installing this script in /usr/lib/shorewall/firewall solved your connection -problems. Beginning with version 1.3.10, it is safe to save the old version -of /usr/lib/shorewall/firewall before copying in the new one since /usr/lib/shorewall/firewall -is the real script now and not just a symbolic link to the real script.
        -
        • - +
      • This +copy of /etc/shorewall/rfc1918 reflects the recent allocation of 82.0.0.0/8.
        +
      - -

      Version 1.3.9a

      - +

      Version 1.3.11

      +
        -
      • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No then - the following message appears during "shorewall [re]start":
        • - +
      • When installing/upgrading using the .rpm, you may receive the following + warnings:
        +
        +      user teastep does not exist - using root
        +      group teastep does not exist - using root
        +
        + 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.
        • +
      • DNAT rules that exclude a source subzone (SOURCE column contains +! followed by a sub-zone list) result in an error message and Shorewall +fails to start.
        +
        + Install this + corrected script in /usr/lib/shorewall/firewall to correct this problem. +Thanks go to Roger Aich who analyzed this problem and provided a fix.
        +
        + This problem is corrected in version 1.3.11a.
        +
        • +
      +

      Version 1.3.10

      + +
        +
      • If you experience problems connecting to a PPTP server running +on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, + this + version of the firewall script may help. Please report any cases where + installing this script in /usr/lib/shorewall/firewall solved your connection + problems. Beginning with version 1.3.10, it is safe to save the old version + of /usr/lib/shorewall/firewall before copying in the new one since /usr/lib/shorewall/firewall + is the real script now and not just a symbolic link to the real script.
        +
        • + +
      + +

      Version 1.3.9a

      + +
        +
      • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
        • + +
      + 
                recalculate_interfacess: command not found
      - +
      The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall as described - above.
      -
      - + corrects this problem.Copy the script to /usr/lib/shorewall/firewall as + described above.
      + +
      Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
      -
      - + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
      + + - +

      Version 1.3.9

      - TUNNELS Broken in 1.3.9!!! There is an updated firewall script - at TUNNELS Broken in 1.3.9!!!       There is an updated firewall script + at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
      -
      - Version 1.3.8 + -- copy that file to /usr/lib/shorewall/firewall as described above.
      +
      + Version 1.3.8
        -
      • Use of shell variables in the LOG LEVEL or SYNPARMS columns -of the policy file doesn't work.
        • -
      • 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 -tcp 25 - 10.1.1.1")
        -
        • - +
      • Use of shell variables in the LOG LEVEL or SYNPARMS columns + of the policy file doesn't work.
        • +
      • 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 + tcp 25 - 10.1.1.1")
        +
        • +
      - Installing this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these problems. - + as described above corrects these problems. +

      Version 1.3.7b

      - +

      DNAT rules where the source zone is 'fw' ($FW) result in an error message. Installing this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

      - + as described above corrects this problem.

      +

      Version 1.3.7a

      - +

      "shorewall refresh" is not creating the proper rule for FORWARDPING=Yes. Consequently, after "shorewall refresh", the firewall will not forward @@ -177,353 +216,349 @@ tcp 25 - 10.1.1.1")
      this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

      - + as described above corrects this problem.

      +

      Version <= 1.3.7a

      - +

      If "norfc1918" and "dhcp" are both specified as options on a given interface then RFC 1918 checking is occurring before DHCP checking. This means that if a DHCP client broadcasts using an RFC 1918 source address, then the firewall will reject the broadcast (usually logging it). This - has two problems:

      - + has two problems:

      +
        -
      1. If the firewall is running a -DHCP server, the client won't be able -to obtain an IP address lease from that -server.
        2. -
      2. 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.
        3. - +
      3. If the firewall is running + a DHCP server, the client won't be able + to obtain an IP address lease from +that server.
        4. +
      4. 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.
        5. +
      - +

      This version of the 1.3.7a firewall script - corrects the problem. It must be installed - in /var/lib/shorewall as described above.

      - + corrects the problem. It must be installed + in /var/lib/shorewall as described above.

      +

      Version 1.3.7

      - +

      Version 1.3.7 dead on arrival -- please use version 1.3.7a and check your version against these md5sums -- if there's a difference, please download again.

      - + 
      	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
      	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
      	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
      - +

      In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

      - + and compare the result with what you see above.

      +

      I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

      - + .7 version in each sequence from now on.

      +

      Version 1.3.6

      - +
        -
      • - +
      • +

        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.

        -
        • -
      • - + an error occurs when the firewall script attempts to add +an SNAT alias.

        +
        • +
      • +

        The logunclean and dropunclean options cause errors during startup when Shorewall is run with iptables - 1.2.7.

        -
        • - + 1.2.7.

        + +
      - +

      These problems are fixed in this correct firewall script which must be installed in /var/lib/shorewall/ as described above. These problems are also corrected in version 1.3.7.

      - +

      Two-interface Samples 1.3.6 (file two-interfaces.tgz)

      - +

      A line was inadvertently deleted from the "interfaces file" -- this line should be added back in if the version that you - downloaded is missing it:

      - + downloaded is missing it:

      +

      net    eth0    detect    routefilter,dhcp,norfc1918

      - +

      If you downloaded two-interfaces-a.tgz then the above line should already be in the file.

      - +

      Version 1.3.5-1.3.5b

      - +

      The new 'proxyarp' interface option doesn't work :-( This is fixed in this corrected firewall script which must be installed in /var/lib/shorewall/ as described above.

      - +

      Versions 1.3.4-1.3.5a

      - +

      Prior to version 1.3.4, host file entries such as the following were allowed:

      - -
      + +
      	adm	eth0:1.2.4.5,eth0:5.6.7.8
      -
      - -
      +
      + +

      That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. This - problem is corrected by this - modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall - as instructed above.

      -
      - -
      + modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall + as instructed above.

      +
      + +

      This problem is corrected in version 1.3.5b.

      -
      - +
      +

      Version 1.3.5

      - +

      REDIRECT rules are broken in this version. Install this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version -1.3.5a.

      - + as instructed above. This problem is corrected in version + 1.3.5a.

      +

      Version 1.3.n, n < 4

      - +

      The "shorewall start" and "shorewall restart" commands to not verify that the zones named in the /etc/shorewall/policy file have been previously defined in the /etc/shorewall/zones file. The "shorewall check" command does perform this verification so it's a good idea to run that command after you have made configuration - changes.

      - + changes.

      +

      Version 1.3.n, n < 3

      - +

      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.

      - + 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.

      +

      Version 1.3.2

      - +

      Until approximately 2130 GMT on 17 June 2002, the download sites contained an incorrect version of the .lrp file. That file can be identified by its size (56284 bytes). The correct version has a size of 38126 bytes.

      - +
        -
      • The code to detect a duplicate interface entry in - /etc/shorewall/interfaces contained a typo that prevented it -from working correctly.
        • -
      • "NAT_BEFORE_RULES=No" was broken; it behaved just - like "NAT_BEFORE_RULES=Yes".
        • - +
      • The code to detect a duplicate interface entry + in /etc/shorewall/interfaces contained a typo that prevented +it from working correctly.
        • +
      • "NAT_BEFORE_RULES=No" was broken; it behaved +just like "NAT_BEFORE_RULES=Yes".
        • +
      - +

      Both problems are corrected in this script which should be installed in /var/lib/shorewall - as described above.

      - + as described above.

      +
        -
      • - +
      • +

        The IANA have just announced the allocation of subnet - 221.0.0.0/8. This updated rfc1918 file reflects that allocation.

        -
        • - + +
      - +

      Version 1.3.1

      - +
        -
      • 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).
        • -
      • An unnecessary jump to the policy chain is sometimes - generated for a CONTINUE policy.
        • -
      • 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:
        -
        - net    eth0    dhcp
        - loc    eth1    dhcp
        -
        - Shorewall will ignore the 'dhcp' on eth1.
        • -
      • 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.
        -
        - Users who downloaded the corrected script prior to 1850 - GMT today should download and install the corrected script - again to ensure that this second problem is corrected.
        • - +
      • 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).
        • +
      • An unnecessary jump to the policy chain is sometimes + generated for a CONTINUE policy.
        • +
      • 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:
        +
        + net    eth0    dhcp
        + loc    eth1    dhcp
        +
        + Shorewall will ignore the 'dhcp' on eth1.
        • +
      • 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.
        +
        + Users who downloaded the corrected script prior +to 1850 GMT today should download and install the corrected + script again to ensure that this second problem is corrected.
        • +
      - +

      These problems are corrected in this firewall script which should be installed in /etc/shorewall/firewall - as described above.

      - + as described above.

      +

      Version 1.3.0

      - + - -
      + +

      Upgrade Issues

      - +

      The upgrade issues have moved to a separate page.

      - -
      + +

      Problem with - iptables version 1.2.3

      - -
      + iptables version 1.2.3 + +

      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. 

      - + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

      +

      I have built a - corrected 1.2.3 rpm which you can download here  and I have also -built an   and I have also + built an iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs before - you upgrade to RedHat 7.2.

      - + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

      +

      Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can download - from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works fine.

      - + I have installed this RPM on my firewall and it works fine.

      +

      If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification - while this patch - corrects a problem in handling the  TOS target.

      - + corrects a problem in handling the  TOS target.

      +

      To install one of the above patches:

      - +
        -
      • cd iptables-1.2.3/extensions
        • -
      • patch -p0 < the-patch-file
        • - +
      • cd iptables-1.2.3/extensions
        • +
      • patch -p0 < the-patch-file
        • +
      -
      - +
      +

      Problems with kernels >= 2.4.18 and RedHat iptables

      - -
      + +

      Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

      - -
      + may experience the following:

      + +
      + 
      # shorewall start
      Processing /etc/shorewall/shorewall.conf ...
      Processing /etc/shorewall/params ...
      Starting Shorewall...
      Loading Modules...
      Initializing...
      Determining Zones...
      Zones: net
      Validating interfaces file...
      Validating hosts file...
      Determining Hosts in Zones...
      Net Zone: eth0:0.0.0.0/0
      iptables: libiptc/libip4tc.c:380: do_check: Assertion
      `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
      Aborted (core dumped)
      iptables: libiptc/libip4tc.c:380: do_check: Assertion
      `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
      Aborted (core dumped)
      -
      - +
      +

      The RedHat iptables RPM is compiled with debugging enabled but the user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by installing - - this iptables RPM. If you are already running a 1.2.5 version of - iptables, you will need to specify the --oldpackage option to rpm (e.g., - "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

      -
      + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option to rpm + (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

      +
      - +

      Problems installing/upgrading - RPM on SuSE

      - + RPM on SuSE +

      If you find that rpm complains about a conflict with kernel <= 2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps" option to rpm.

      - +

      Installing: rpm -ivh --nodeps <shorewall rpm>

      - +

      Upgrading: rpm -Uvh --nodeps <shorewall rpm>

      - +

      Problems with iptables version 1.2.7 and MULTIPORT=Yes

      - +

      The iptables 1.2.7 release of iptables has made an incompatible change to the syntax used to specify multiport match rules; as a consequence, if you install iptables 1.2.7 you must be running Shorewall 1.3.7a or later or:

      - + - +

      Problems with RH Kernel 2.4.18-10 and NAT
      -

      - /etc/shorewall/nat entries of the following form will result in Shorewall - being unable to start:
      -
      - -
      #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
      192.0.2.22      eth0            192.168.9.22    yes                     yes
      #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - Error message is:
      - -
      Setting up NAT...
      iptables: Invalid argument
      Terminated

      - 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 -http://www.shorewall.net/Documentation.htm#NAT
      - -

      Last updated 11/24/2002 - - Tom Eastep

      - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      -
      + + /etc/shorewall/nat entries of the following form will result in Shorewall + being unable to start:

      -
      -
      -
      -
      + +
      #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
      192.0.2.22      eth0            192.168.9.22    yes                     yes
      #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + Error message is:
      + +
      Setting up NAT...
      iptables: Invalid argument
      Terminated

      + 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 http://www.shorewall.net/Documentation.htm#NAT
      + +

      Last updated 12/3/2002 - + Tom Eastep

      + +

      Copyright + © 2001, 2002 Thomas M. Eastep.
      +




      diff --git a/Shorewall-docs/images/MDKlinux.jpg b/Shorewall-docs/images/MDKlinux.jpg new file mode 100644 index 0000000000000000000000000000000000000000..e8201c7317998234e6edcf5a0677458b7df4de4a GIT binary patch literal 15401 zcmbt)1z227v*wu@bl|~V2M-$D-6gm~(81j`XhIT#OK=GU2_Zmm2oQpM2*EA5I|K>3 zL-O74`|sWV?%rp&hUxQmRrTrWK1FxWJ99U6w+P@U%PYwPATS6}M7)5zJyc!|J6A7P zPdisP7!L<0ASkV*3fThg#SeIZD1Z9_0E7fAb$5Pu4v_>a!@$Uaki~l!kR8bG{)+8~ zAqR2-xH04uNB|801OnX~nXmy6;`Q$Y1X%r}j?Y5|X#T45=~%#i$FTQXfpZ@v;vV4t zxZc~4pucTMh|=%3@5%2v+V2uk{EH8w_xl221{V|1}>32rU5I&l%{qFXnv}8FpVsyb-nfbRZX#_R)F zQdX{()__$gq7CS77I+3=qM@OoqhX?>W8z{!F>nd7F)^_TN$~Lr@$pG;F@MWnmp_&N zT7sY$7*H%I4i**;0Tvb(!F_>6@TUpx|KtXDUjSS*!~onNAX)&73xeQ+?&cALMZN0; zNg$#`Mr7olq(sCFKoI``NXRItXy{N3M1uZjBO=!z|6#-dKu9167zvDwih_m=!Q??0 zaUn=FcwER*nilx9?qS?01POVS(scBMT5Xm*ydL2rGN=rR+J{R=a8Ev>{HmvnvPn8t za_w)u_=&&kE?Xa0KkFFvUOACxN-l_~dEGg-`m?aMYkcig&&KC@N>N?+#QK?lg1)Wq zi`3%!p2>}KTmTG4M2qx0CR7w;zTY9xaN!{#B55+khu(6@BRo+? zn-K2Fd&Gcp9{?&NU;B4N5O0aC7NkpW&ljc?>=z>3E*c|d7+-T zHkS;wbNTzh7j=~lb?@uK_nyw}u+{bN6jdCy7Tf`{@0%)?rxRYy*}i~JExR^;sX<8* z8J%r){a!zM{=P+R?(6Hx9$gpqUkySAF3e&isZxBJ&0z@3tS>nCu3YmfR+7 zRgCFMSbM9?%w@fYI`_8Z?*{Zbe<<&%pQsPwZ;5ejyaNVjcl6bFsEW%j$sA8Y{J^NG zV52zCsNt)H6}Rf+6?AS=C6qYS3#n~VZ#|(w_{;{kKy3jYy^G7{%^EX4e#sbi_-b&2 zSHQwk1=Xz}v9^Wc0r=5-P+1dMRPHmjkJuygKGwAXAzO8Z`WJGUE)OSIgkNZF3mTkH zj#V=@ahH}7-&_xjwVnrOmi-gTBbm_g^#uXSia zjUjpDY`m@ho!=dxtG{^K$AP=QQ?_*@=oOrqHtE0eb8xn5QIp9Sm-vW@*YXwf zm5F!Z-rjcH?DX$Ww2RhmoNtO>&Mi59vM!JMK)`7*7^WhyVpy|(lXRAAGPc1VR}+-q zDnB6Jv1M)TZC{|T@g$KTQ3+Oj_w7_CwZDYEc)Q?#dbykay;lBN@lgR3#J-03yIaOI zP?C``)6i0vS9&COuL3X?AKAOOf)Q)4vx}F9mVz|Qz|aVW`W3Nrp(Az-E&#BAd%CG= z%j?{)KuU5lFi(WjJ^n||CVsEQz$m+-1`PI({(ppU;cgyYe^zjS$I99hj=;|lEuDP5 z-0t;<2uxt}BnTh!X&0T;2RV>}~D5U=QHTFfJh>L71YouamWx7rTZ9+|k0r3MS*~ z>}KKO4*-A0eBTPdyPsPaVv_l}g!uW{xj7Ki|F`@fjemRnpTYgJ{o`?>`TLoHhz9@B z{nPdzoohZ~A4Z%vAo2g`EYks?J^}zpX8zI9zd@X)o&iAJ@V|_Q=ssWUyu93mA3pT; z_2sa)hI8Cc=-={xb@L-r=TcMA}9lt z2Py$of*L_>pgzzDXd1Kx+5#PeF2N8mCYS(B31$R81Pg+tz$#!JunE`}><$h9KLf{t z)4=)Q58yg*8+ZUb4qgQBfKMR+1Oq|@p@FbN1R*jIb%+tf2I2t;hP;BLK=L8wkWY{v z$S7nHvJ3fzgo1>R1Vds+5O>kvT0%NRxv`yxL_PC+h0u0`%b9!Fk7K0`r4Awpq75kOHyF+_1d2}FrT$wsL_`GPWn zvVwAoii%2#%8Dw6s*Y-b>V^6oH68T>YAfn@)HT!#Gz>IqG;TC`G$S+@v~aW(wD)MA z(Y~W?pk1NkpfjKgqpPD^q5Gr9p%;w(8KII;Bd8ZN z7Fq)Bfc}79VBuqNU@2i)VTE92V%1@N$J)n6$7aBm!ZyVYz)r!g#vaDr#X-km#F4?V zzzN35#A(Et#5u*q$K}FR$92Yy#(j_5hr5Y~ipPj2hi8TN4DT&o2i^)k1fLFH1|N?9 z6u$t!3xACOg@B1biNJv%ilB_(E5RWl9w9HG9-$v$CSeQVA`yg$kw}Tii71Y!ifDr9 zl9-ZMirAVslDM4sJMlRQIf*2RHOVWI3X*Y>OHvrA9H}E|0%<+zJQ)%h3z;UFFIf&* z7uha30l5e{octAe75NMWn1Y2uiz1NXEyW+L) z=#uH$=?>|s=~d~U(3jHBFrYICGT1SsGW0N}W2pck+5St5IKHDTaCc6~7 z4|^&55(g2-BaU#6dXD{v^bd_5COqtUc+1Jh>BL#UIm?B|rOXx1^@;14n}r+Boyk4M z1LcwD3E^qrIpSsIwdT#?o#MmiQ{{WX*UoptFTn4?U(UZJKrdh}kR>oFNFb;o7%kW< zge)X26e83t^h=mu*h{!d_&|hR#8KqE$fhWhsI_Q;=!zJvn1xuL*rGU0++6&P_@V@j zgoQ-D#Ihuvq?Kfm2n!jnIM@jvJhDX*;le(<&bClQX*Bz5wl6O*|Zh2O|spxldwy%+qIXm&#*soP;|(3ICoTcEOxwe(s!zGMsqfI zZgjzOadhc)rE>Li9dToId+xUAF6{o={m?_jqsSBFY2w-7MSwU=4SGNDj__Xc5%@aLLS9`yV}8n8l(#-_*9-ItdI|*#ONz*fqKa;cU5XdqX}#+#5hy8nPw_sk z6kO_Ey7l4lhi_%FWew%*<#`oE6;U67kKP}*E6pn>s#L1ls|BmeYZz*>YVm7d)q(2# z>kjMf>K7Xf8%7$H8{0pLe5!5YXew@|Y0hjRY>E2}{rv3nU28z==@+*zyKS~@EA3|O zvmFKj(G;>IV4+YlrxTYQOS-ts52? zZulnj?bC?p$mj18-`hrIN4v+A#sIs)O&`tp%v{Ze&LPje zn#Y+>`9bj`e}Q?SVv&EbWl45va9MkKb_Kq&v+B8ez4mM!x}LH@y-~8sz1h4azx8d~ zczbQfZRcwD`5x|G*8YS2nghv$!9#2SI?#X<;IooHR^TR4fD;XTb0|nJ7)wdv=7ky#jZ#q4g??wfCB+T{(StnKOrFG zH{k;QTObGoK|+)Wf&l4WkWr9-3knJ)1UMS_=rB%6a~fJYdR{^v z24a#wj0iFqF#t3qRD?U|e(bm?0D=@jmBQDgCBU&j5HksMglLi)dD501^h7W%9%4@O z@Wgys0X)Q{BK*-HC`ic2_nmwaN6H)FhDmBHNoyThde9+S zR`Dd}FUxrTAwxh24hX@O0SAls?f;EPQnT&Y4woF8F8=RE9HRE-h)!1z?xiCs2D0mj zv%sw@+a(dXssG&-$=~6D_$qfjdTX&nT=3}WNackL{qPwTqt#_S-TTDzZ~nvfE5iyY z;K#vPhECi7=xGwgsy`sXL&zwUcKpx%K$4d+CMhFk>F-taK9es$aV;ns{WR)-h22yWPXZqITlx@%n&LcX?A)FQ)QYhr}|a7PhWB#}7XxGN#>CHna9) z9K;SxEFDWZUR#RLy|2Ynjqusz`<1~jLf(GB|MK^&fC!ADB62m?F2j!Zi<-7wOoqmx z`pZF+^H@FuyIJbPJ1IB8IV>}}RdW;lZ@kF{>C<{^3+kHB+F9xegXTs%`XXW`jOX8} zLl-Lid5Jg8)IWS;|_~GIGDL3H&-XM0s z8L%g-P+uaxy{CFQ`)G&Vz9>o@S4Cmaa(>KtM(s#?mv40f}{U=BM3kpGGIvNO!;6{O8 zx3=k5q^-P)n>dfHzd5KAvz8_ezIYI24E0WD94JrPx4iDh)J+Vmdb?&V`0Zidj9!09 zq7nnGC;m*thZvLUlC^@zEd{I6{04JiKEY7Bgk=O_L>95R@Fj914!=9Myi+FRvM)^_-*U_a4*~~;) zgOi+}7sl_it4}bis5>uuDQ8zv1T7u09b!WlvMrGm@*pExN61k@aRqXMWsqm}X z(Ul?~V^2OVXoaxD06xtf8U}CG0%p`+78yJjT_oJMmX*kis(DXQ`ke`kNfPN~i(|D) z%zk~d5vJMbj0+-%we2$Yyq~D`ieypDntxG2ZZ|KmZN)*$@-Ck;`9f&~*_~#zz$&44 z3LJG{&t+7t0COw|y#Df|MDO*6@+Y*-fI*+MrF4HYhLfs|OH#>o`rV=&*+~A^8wk2C zF6P_PC@K3+iA5sj^((^gzD(Sa?1-nMR0D*fkvvCLGRO;uMG4mrwzLQ5nqw@E$xf>x zqqH-aD`<#JG8rJ$ah`hQp(GD6?f`MoY6Y#wgS4!#2M&>NfGi6N0rn5Ii`E39NL67b zw#>cgHmIna9llN6qJ{p1w!J@}D@m8I^`1ZCnbVFhZC4W_KZx5@l9xwX#fXAE*R4z} zTl_!|ZQWyV8;!L|wD>We=Iw~K)KCR=0e4H{j;^vMwkx|8`RjNL($nPV-o*UQQv{!n z$kQ82>IT#y@%)y>D95RaPuASf zX~|v$=ZdA`j7&c8QnS-obHy0e`K+4l#}Zs zP(GdAV4)CojM%+25x9cgYy-jog~UU zg({{opF*DNRDZ{ki&yBUe;b(YuEwvg;xD7)o19YQ_JS}@)ch-(CuUKaJRezZmRnvL zI1%Jn0q>z7%z3!@V3X~M3>n~E;Lz(I96f9Jh|Y{Y_(ygQ zGLekf*l_^;)F62WisUy!^lih<_t283B>BCzpFVn!jFNm@9pX`^YCigA&P~XXyP8l& z!qrn{pNo3khS)O%ZlTXhUzpL&l6{9mdztLsK8Q3|^vK1G4iJ+N4YR=g*gh_MbVMJH z+w7^?wT=uRNseI!`LpS=uhb{(rCFU5 zmv=ys-}TE+a7V{Ho7d)|3C)QGuRn{PpvDW!X)MP5rN_xA(|1%#`XnKF z1sAFxsN|Cyp^FPjTuCfz1u4U@Drnv`J>2=cYzTV)Gu0#qZ`0J}gF^;iMZ5E~p#=WU zXOk3mqMYh{;*gKcEKvrhma|M>t^#ZMp?c+C&cwbB4RV|C6&^aX#>MtGR9Q?(R$6|2 zHtm#-lPJ{8H3%1I51#k-Nx6DfO^dXfL=lm|C@O`wp2gKv|8k7j%OxRlc``RFu&~#tcN+P@_{N@AJ6(_7;XDcB#@oqsw31>?+17)N8`bqp8 zOlL#gDW%fA9yMgXo=#aW8bw4ZXMaQm?G0(pvEk!x7h9bSr50Wa)Sq#*?NSHU5gC^s zLWzy*>O-`>&Rx#Bvt}_G&hG%nx?AEHZ0xQ(K*VQ9QN-6^3)+$Gb>Of{**Z$Pjw_et zU@Sr@QFcZzlxeI(O(kJege8|suZSdRGo3=3bl$V?sn$O@S?p)PXH&9G_?6FbcJ2lL zi*k{Jh0pDdF{#nHPCL-gg*R0t37j!PRh;Cedp_r^P&0dxs2NqcbO+O{-97urQ_sD5 zz+Zf2pZJRZbmh&>i?NIfy)E|Ka`vXu1&WkvduOrvm()es$$Ros9X_ol0pT3ksuLO1 zmKMh3lvnXALE%aKw$3Y&TYGs_axPdB0GjBxpZY-_ zwT$C;#v9YkcPsGH=meJkq5r|k&!=UT1-mf}Wp&@3f*8uqT1*sFgm)Ait3GWNpUqv} zmTxvEQDQ%?`N%~v){X>W$@6*E%wq-`zI7O32NhaHVNwo60 zL@!D*P$~M<$L1kSEUA+>QX*W_0ZG8@YZAuDaif`*7Ve#=E)LtJB^I_O8Y4|~On1PN zOZ5q`-JLKYL?ko`WsS5R379QdvN4orm&(xCiDCWV%~~g*S)=!@p<1w9Y>7uw(-hn!g$)M+zVuyuT8*_e%d zs>wN-v1iQqm(P5}+g=NB*k{@XQ!ck6I|w{9ekRw4Zpz42?}1~9gc;?S(-7IIN9JPD zA2EycIILZBJ#tYdJgYP8%TK{bu?SBvwViAIht4e@pSQaq)v}oRGK)*OFBax*(^@-O zLvMfidkD#WjcR-(K z3i)$u*Z4cY{d%lrZE;x;+M>+)3F(c(_qMm1&%1==X&-ro%DmFXVwn?zJ$euFaZiVv zy$@4fUBaa$dn#bDS{QsVf*tihR-i~})kV*ha+4EPl7NqNZSJi|O2<$RZMXuF&{n|N zgFr{UPFq^a2++J%2m?94Br!e309PCN31p0mYiyjuxTRVvcaMtiSo{3*GK#!5Ef+6& zboCeWve{}V426oRQD!z!(Gv%=u<(i^oW!QA8-^b0&3|UGa!s)D5nG~9G58y5Zmv`# z2~<|TahX%I#Yf@|ULZ(jHj@_ijX3zI#qei`{1O&-9`=t5*5E8jf1Qmmt(Y%M&F%60 z%g*0O>QrAY# zZRes41{v2nFv@j=X+Ia+EuX?<8p8WUcKz-3H`-xonKcc{+2B)VWzbyUOYrI7e7J|(-D+9h%hmqXp^ zsIf71%>4`LG{nUM30w{7j6Jg7p5-(b*OENqeGa>6+w1MzS7m+C(I!-~l|A5w`??+T z<&CV3@5RP92E0yUR10Xm^$*RTtCkm)UHC5Y52J`=$rIttMfE(yQ<}-PFg1oDzdfVV z0lmqGKWZN(`XuhCmoQGPA%66b^sz!i&8V)?i{6%29(hR6NnME4o&MsdUGl1Y53526 zI~^0NWLC|t$NUt#-m0aqrs%45=cmzarG}g^w8!x;zd#7tVz;8!Y(N1 z)6TqFruo;3hUtAaem&7C>&1uQfF$%9CJjaU;wAchkxNfCz%>JY@(K);vM1I($ErXZ zcfQp;^dZrqc0#$C#XKpodxSF5vf~*#R6F6xCzLlMR~@@7A|-R7B*}alS$dI=u_r0B zOS+NeYev@toIC6_Qw}34M#*v$m)5Rvs==Mh8p#w&N3&gk5@|!1ve8Qi*Bx0}dPQoM zJhUJ={L8xaJAk1xpN@^HiTgmSky#K#I=n>yLc=bc|NH=2C_mK51I2typm?|>JQk-XT8n$NJTkX#%+xV6U|apNpg@>NB@aj}^|-bL!Qc*qNU9A0l! z!g(ao!zuKZ6l!}Sy#%X-Z% z11R1+dJ3wQHsd)Y{fcfLM-;Qg_M9=Uw5B!VEwQveq>vYI2pfnmJr~s^EjU zP$WU5s;se00yu3a)hTmto#2QxI6s$=Jf5QX0w=D>jGv@x!-A$(5R-eMH5_8D8A(Ee z7O}A2I`%|471<5*4&V(^hNz**6aENGaMDZx=+I*ycMq+UX(X#WJx7W6TBgx1;!1F* z5b)yqQc>Vb^A0?a2L7Bd*BHwD5)g+!Ax<{s8sH$hro2HZh9J5|QAzYpNl`?TFN`$pYXDQS6m!ksFH3)<_dEB;^pfI*6l(;mf8e(t9FlcjUV{^?w6D|%DA8vVLN`U!pYm&MG`Ar9H z#-5AhsLi=^?MD_Njdx9YuU09F`=?Q@suI|JM^$LIVi(n4*7b;xL^kj+SAi-3QmHQ* zTR+W|=SI@0?=5$|Kex!S(W)fLHmgrHmAy3!Ar&g3&*b{_W-@=%i^4g&l+uhQs#GNR zNK{$<><%#8kJ)e@A;wTvf}Lac+gQxvNcg&w-ORxSK0hY)6?pADJwH8At|Hpnnbl{k z=Mumk;;gXrrBOOR_sayIlK zu1HibUZtt%BEKg%HJX>n$FDHAsDP=nON~B1_-Lo5b9U9rYrZw0CGL7FYH<|j5yJ|H zjjUIl^ig=L+I@D0+tLIUATdLVxy1yZ8~QSG2!1GTG?i~eGsM?w=~da3e-oq7@vLX% zoQV787j9wfYe%;M9$Ndkc3zK8sC==SnbqsPeNhu*T)e6_zFy6-SXu7saJ1zP3r_-% z9W^P!xXdbG})*V1pu!*YO_Cy#Iganm5@37q6s7?alJ>$~zd5sV{FU^Xcm&f9AeH7xHu@`3(Vy~*P z-l#m(?&eq}*iqeEiyL3G_OZjKScB6TC$PN}d2!JoE~RMGA#4&o&XCz@i}c zBeFRf{GD*zfqNyVaWS)tZ$`Je>$D?xqgeI$>$fH(cR+yM%G$*f!8zkuE*1r2sODNE z#cgAty5*)&&XccMKPRK*c8lONY70ruy1ZOUJl#h{S|LCC`?0tE3Sx$T+ySXXoU_y< z?ysx9D|j*%{*Yk^!|VCcH9+a5AsFCpR>t0N2W;yaYV?2d6n-NdH{F>C-=A!u;3g?b zY>s02@Cx*xOKAkbJ}x~VkH`2$to= z5+2MY_a2<$570-IFsY52sBd%yR2w~K6~JIu-rufZ)@5rW$TpTk$`(V#lcG54;}s4Z zVFmY9s4WV`k~wPk7!llf^ta&zGrXiw@NudYEE!xDbgnu2ptd)nJ7A}D;n+2F2k?go zJpZ}~k1eOZaFHLf!+sL3gc+~E(nW(tp81xFJF}IUzRuNkejtR_Rjq3+k!3zvzcEw0 z*xQHBEcSCV?`yU$2VPI|K8(`PopB{CFS@0+M0>mkJ#=*O?2Si$S;~N$v?t+;B{iuG5EU_C&^6e}~KMZyD;hY1AirerdtN0q%V1vsENG z%`t~iK2gK!;9YNrFFjeY097dVaqMH!sa<&mnz(0S{Aw(FyBx(*Cpdf?hf7Qm9o;Ls zbTPl2-_u!jD-#NkfPajHiD*#00i$2vE`TmFh_I=)=XvFgzybP!nkhkIUa`!AGgsNf zTkpo^0t4CF6eZ2|%j<+LeP1qU1vAAYTsN3A@HkV@^)!gSwd4+jD(@F>O@-xge@-|> zdeT!&j_UkfafpIrou3Ft!Y9EzVJ%KlDCB1{cB>ly!ST(q@j}PB{9dortJ*YGrO=@n z>-eqmQat{GprHz>Zfu{umZMyg6KHAfNq#ePR5w+1IuihTp0`nz!ZcBH<3J31o?c^y_oR?>%x@si)dKTTWRli%;eX zf0sZeIHOQ{B4IDgk>R=0V@yuHDq6n7SI;ZwJRMI;l{*?(zY-6VgLPVK54_o`Amo?t z6kk7|>t-1@6l(S`c6A{z5ymenz5^6D)k&Rq8U$QS&r^(qQ;uhQXEWy<@s;xx;aW3n z5+WcHGW*H2$vDPU6w`fFhR^j3FD>VIA9vWpN|Csp$C^Ir%-N7=j)hHSLPF*S);~T> z65Lx#0J|=EWq$rJDQnJBQ$#9O%O>2nH5oIy)=KXxRAnkUEjSlGUQ55SFi_SoTE$Eo zLl=YEn0E&VSFj5mHCNAexLdjBP)+&Di>E*+MPI+|H5qM5QHV)STahlV5fEQv-O8gNdQP4A;}jKjG2Igqz+kTI+3RY5tX1KCJ0>Qg*^^GH-&m$Z!QDgW zo1zF^msMoUvy$2r8)daxW!c%+KX|_LelV6x~FJWR2;QTKi05n_AZ8(FU8^RbrO?W${l~cPCWxG>7U1j)jU|v^wr9P z`-7c{20M2^ToZy4I%|#5rp=Dw%k-9 zs$H74`a;>Kne363^r(*qh=}`i`PGy+EYj9=MOGlv{a_Jh;h$rdZez{1wZ6nBq@Ocn zNP7okjFC;@!=D{vF)b9{Ng7;YvF}$r*l-lfieM^K?`g0bdO{?OPWm|F+4bnaai~pN z%BV&j$lPgvsL-&mtH1lvS2C`W=p1J@WifHOn2Y#vyl5rvplNMVj-c(O!3txc*Euw? zjfBfIFD*{0ducu}(_`6v+qFAdSL08==DBAJ3F-A8*scP!hlxUo5OSR232 zmv6F#cb={|sX|m^nsT88Zp^aEQM?B8TtTlF4f+J1V@684nq=u=`mRL7S;xcFRqkZ{kI*KH^NV#9XoMV7Hzhhrf`uUl4GN4|R?Keff zJobX22KlDG=}>RUV$Y;UKe73Pg)dF81^Q_2JEjW!y|NcglWwyuysErEEz(Qn=(=d0 zqZd8Er57gJV=^JQ7VLDsB=5ks^)o+ApF4AOE-Sd4YH7kBW*s7G*?w>0pJRku%r1D6 z8?RFKtY`e~tG7;eOSeTzrds7fUKONklcu6i#c7#ss@0$q){0WLI8ru3jLxWHM11r& zbFR)UtpcjfO(}PPn^MYKg3G2K&%69AF#t)W1XEgQ?yH0fF&S-0%dnX6i2nRKW^*^he2U&^xS4ILRG zM_KFcSjgmv8+G=%47})PJ?=g#uq;=Lb6@+Azy(X{{rox0`dFM}-b+C46_@tVx|`n) z?m%#z*i`3%O%<14OP#X;=h}>)VRMU_%lCy$pZVh6g|9D%$0ibOGMYztSg{k#W=2n+ zwD8hJcP&sXGITmc6Dcl#6e13th@wxBB8YRSvDQDQ$?7gE*=LzY$rzg*nTcw`R<7as zLg8D&GU|(4{?^RTz4}RzFRsPD^W`vQaENFCg&vl&CIKAg_baumNpZCW8yAvHRFeDuIUUk zi^v`xpp;fP)U$hEHG1YX`r4S*iPso@=q}Wb(+uu{9J(cRxdON2caf$yafeb|=J_TS~uq!bf)p_6EnTn_hk$%ZSy=JTY|q z`do<4Vw+S6^`&#qN|t{HI+3hp=ykt0^=vni>t407JG5r^BFr8soc5+=266`om`@(A zV82)(_xbEd9d0@G{NBkjK1wtBY_QD2;5R0s+It|guR#cgJl&smC@OfkgCDZ5qMW${^@z~PKLy=Guya2-pSeA%{NZBxO~ zXU50ljWc5tWX)EjS?9cA%9|uPRR?(=H<-$XJIMQg<&x|$il~feW#%69Z=7*4<#(bpNQ>eC0Qj4?NuD3M5kzI ziJoo}pnP7E6gAabfRmp-xS(i-P>bN~rD&h3#i2!6XmZ+RfmI6eQvFp|Ce(^34aNG>S~9Qk$JOfQ@*zmK5g zoiH~iEJnV$ht&3HeYnTj=PR2^iUX$tdY07u9y+E&OPk27YJh{+w%?Q6jcHx_!ADZn z@u4Kvsj9qqyw)mSr=lF=W@MIZmdMGC^x6}#dVy#kqF8xK@!Cv6nbMGAvot!@mv;%$ zb`9gdeX!Txi|(KQ?sI#P>b@S#6eZa5w06@uL!W_XCOnxLEm0a^Ya^5r1_U!bTw(EZ*psMAT%y8>Lw?30000MbVXQnLvm$dbZKvHAXI5>WdJZSFEBALFfn%# zyC(nu2pUO5K~#90%~|Jyqr48a=>bePE#duN^Gb51B(upkd$am81Pne_J<_n-bKy?h!EcsL#{>EbV>;a#vn2`j(faxH!Y~MKf6O26F5S|$FElGa|moFt_+n=w##<(KF zFbUFT`Xy95nI&V*pD(|{$P+-=rti4Sdjj8oys`WO;}SBKr~R)XI&biv8ZR&w5Gui6 zF|iR)WAe`W6UMt>@-IY*FKI5`QR5L~4`&>s-vo3eefE|o?J@EPW9479^Cz;y$lLb< z?*Ak{#{S=gxWoAPHzE2M11L~`DJ%A$)Pu}iIE<-a<4@tTR7sLl^`GII?Ivq(^WhO} zmKHv{m~B$3LtD`;#wBL)4_qW_B@rR93;ig(TQIk&Ow2B|lnI%oX$2E{$uvCt)VQ=# z2;mZXlgpOgnI3{!QfM&tPyoBv5a$8l#c>QkThAvjquL)UJkzSG)CaQ)b`#@bZ#u%$ z2XtZ~Y|Vfhc&@2KW#qcdG}DaTY9oU7rfac4y#i_5*kLoc+;(PPtuQkz$xk ztZM|G&N+}smcTJ4`%Vgq>S-rddT12JEVk!=BCxw%(dR5S^>P}#H+f9J=rTtiM3PrJ zFYib1Ban=hcQtHiEb0g?%G%Z6TVaIz;Y*0M2a$Z&xDXsVwrT?7#X2~^F{=#rjD3Cr z?h>18fT+34%<@KGuq}gQiEf_)3FD81F7vfT81=6y^!goe7~|AEz6ZTH#DEe02n z$}{`Qgdp52VM%`EG)#Z+C80w$RCzz09>Ig8fq@>c_q{EGvQ)cExGSj9cpfl7ZO=w% z;29DR+0X3-2h%PG%qr_PphoRgU^3>+fhrjf z5Fx1x^_eL*;g8wcByen(hm$WVjG43>T}yF1!)9!nxMZG?Gih_6O5)>o9VKXeMoJ6K zT{wqmFxy`f21WsKNy&`vhC>O0Lke797zYfLzq><-V@a667nCYMp_rkjYQREcw4Jc0 zQNb|rTuyZ6SW%eu$b36<11p<#Fcgz`~`-(H|@5sLzgv{V0Gt`7?&ig6k#*&aHwObhJNTX~2v+mN4ri z&1iWn`sQhhV9OvRfOgtgyr&B2EKg^MEV+INwewCF$v%Ih8Wk7Aa+Ya`WuID)$4Yrp zBjjME^V=k0;aV;G=Wy`hY0tyPv+vx9tZ7yV&;6Gj7i$%PAc!338q-t&RdRB0#|V}y z78uD_qgWO?F6c>O_ZfHYh}>DlGLjs4agC{Ss9pc?@JX*Zvak%U*xNn2whtPRdQ048#uzs*o)?n(mM7VFBk(WFH#Sr2U8~I zSoL{$6Aq?2cc;N zph#%4hR$%}F37r!t!9_%mQmkcU#k&n;m8I*5lpG{IRy4s`rLPq-l27b9aY-uNc88_ zrWe8`quMUTu2%J@$bDZ5aTrwqdy1(;KHw|9)mecC`K4aSso2_4YRbw*mB~e-*)B)ryg2-|Dkm^ z2|pV>!Fc1UL!x%#h!8;%@e+4OB4@OdHR&vD(&lM=&T~t!YY%BNd7q7H`!)Vy>Z#`x zK~jO#*=4fN)->f0qVVpmi%2KNsnJ$`TYV?49t)55pV^g0Fn3MS< zj2}s%F{WzgRFzYQ@uBWVCyXKg7RE$3)CMEh|17^dj8#XekfmS2C?(F%!1}Q;7?GXe zFEvF#j5ywj5P9_#j3pFsj!dE)3`Y1NtIhP5gfUWc(Jx^PplZ}OChJ0t5!w8}5gHLn zvUQp@G+8LVg0aR~A(r;qV8p~8Dqo!pMk(pv7&7|~M);9KnQoD(5=IP;4hKQ1ZhCPo z)9>V-6sIsm&2ohi`Mv0(2${oZFb+A$7JZh(|2xK;;&$~-V|;k|5MzZf)*J+1{R+kc z`5>UnG{$W3Fd_%0xVB{IOBhK}Ep-vOeg+{TDUm~p3|z_i9!BhNfeI^(ioh-k2pU}! z{|3feO#g#W7;&7SsW?rnw{KyLfS=-j-WK=+o|aZs$8UWHe{Kxx literal 0 HcmV?d00001 diff --git a/Shorewall-docs/images/logo2.png b/Shorewall-docs/images/logo2.png new file mode 100644 index 0000000000000000000000000000000000000000..bc86987682ebc81a514c120eb9b9a70c0b2e3b62 GIT binary patch literal 17550 zcmV)cK&ZcoP)+|VNc000McNliru(ghq3 z029vdb}#?{AOJ~3K~#9!?7dl&WZ7{h=I-a*EtbrT+?UGQ_v$Ki^@i?7Z|DX<00ck* zgg7ITLy?q3jUHsC7yT4H$t1Hea%RY(Bn}~v0Ex!Z-2i*9uD!Amed* z0Ra-t0bl~Gj-{oAW!{Jz_a6U_yMO-qxhNv=OC7?HS}+J6fkprX3t#{=h#DM$000P& z#-s5oIrK02d;(yBEI0}j0-*E}B>*V+J)(1IXf6$pR=c@zRZ8o!c*e%XEs zz(F7*Bn-)(Z7%FB|0pUi0H-*BoCUBT0P<*d9*sw!`k7DZfJNJe_F~rjC~RD6SFVcf z_A@R9kVklWG#-V2A2$FbOd;H~?S-s+&Ed^X9mKTJnFIgf@wTVkB#E zXTv6Ik}i3w(G0bi4hjPh0zS&69*tjdP~GPPWIyZq$Abm--G`{bp$Gz2004*p0R-=V z0zQBt0ARTHc3|L6)>`K7l1erq-P7EaGys!;2m&Aw0KwpVvVW={k5}b^Bnti+PJ=&Y zp!--FII=q&qL%wW+((g|T?AFiMPfDtS(0wVwdA_xGY5C8}c zfYN6P5i9_K(2r9h00P`k)3AT+KY^pcTl&Y-FEs_dclMtOXNE@({8x#n!2Ybt!`Arl zqzhOhV98iy1i2fp({-1o>N414tRZoR5Z~?SGk-Q&u z3}zHXfjHZHz5o5+{pIYD1LM;p1ca6#jv%W7?*W%VdW44dQy~OR;DL3OA#DjWgs{WC zbq<#~T6b(4B?HR}!1u7*+5y`m00d$XgV}z`3V{)XKop1rqJRlRA?SS}6ZM_f1E$Fj zx;q3MpzfzS0r@!Qd++A_qT$33-v3AAS1G5GhbEREPVVphix{L*HUI8U|7K=({@BTb zet=pugqT&=ZMv+zE|ClF2v_TP9Y9 zlmQ7q5buEoGXMrq2t-0414k>1TAy^avsUGEXG{ zh!6QC7O{x^JOqtlOSH7v`re!GpE`Nu$lUm_izpV+0as&COsp~WE%c(ICkTX`&tRBz z5nUf#544YzQ=q`MY`l))s!Cf*82Y)FVj$5DyQ*p8EnPT7>?zcMWCa*4panz%=~MXx z=|IaaDFT8x0IL7}1wlYW1W-^=K&a1gJnYCGWM2RTAG~xx**~6{iAaQr=$B&RKTceV z2s10C?!EYVVwVLG9=`U$Fve)D`wBt$i=i7u1QGkce?399zi1)!dG-6jlvrT^C4{}$ z{OE(_O0)GFpPio^b{(()BqHdk(b?l^e6GH}5+=*T`JN{+vI`I(1)|U(uvXxB7923C zWL?Mhlpvu7BmfoyA#g|vev~%v>Y)?hdK!uflm)V&1Q@^o7{q{p7-9r128d!n1Ly+g z0bFYZkdY9OSeTGdPz0D684(fxkxe3^2=$KvK&1xYVJk$~pKoSC{6)|Gk2wkiKxP&Z z0JN5g2$4j7o+f_p>h8T35fLFGB4zEsVg6i!4EIoU?|%Ne;!5A=`Uc4b0w5v@2nzv% zAl_Y#-g$p%baL{sb92RS>PBT15(JsBvu2U zfUsiLK!`qo1ylemC;~*nLvG0R8xl<8XaY2jdRS{;p(~&O03iX(CQa-0jiI6OAXgHJ z+PkY+hGR3QQI8NIi|hw`Dzny64hRqd(1VM`Pp~dUdQj97U<=Hm6oL$B%wPPh|AYV) z5shKT(Z(1;K%}4Vw?IS@=mYhhpVw!LES^qz9;-O^;G?eE#8Zs1q1~9 zfe~p2Y;mYbNo7TYt6Nm)p0QD1kMnD#@MBe!PQ2bmJu2wtk zjLStYb##oz00=MwCWs-B9Y_|~15|)U&>{e_qpU{hXk_VRCRvqW9Q+w@ipm`&eS*A6 z@bf^U8ajF0PTEma@3gCBWs_o101@DX8Bhm`Tm~AHgc)>S?W9Q93h+aD<395z4`f_~ z(1)Uk5CH%Z;y;SJe(^k^01*+QWk7^1W2My37u|@1n!h{%DrO-<7H}QSEY`BtKTjD) zKRG0#enNHc^{*?a8mtCxE0qBDIK_-}X*h~1 zCr%OJ7P&(zmm_B$NRQ@f|Su91#|z zAKUo?abQw}11*-Zp!6WqAi^ZEj-yEZv%JF3pRG^|)6_bS$};{%$deErbWp(DM^ry5 zLlH1Wei7FGU^eyZ9R305f6Scnz}BD_+ojdLt*zbJ8FymTR~n54hp?}EmHs9ZXc>$O z3ZwH+a+vO|WsoI-AGy#Y%#?P4edc~0*A?(ln8Xku4>aitfPgfZ4q!;gIwgP(p$m~C zxS2Ul5_=4DDHnRSo+iHII$Ck9vRSUa9-8se%$Z_odTX!M3R$RN*teD#OgCy}arol1 z=MT;d(SWU11MUzYHC(Q?x3=o-PK1B}4v4Zg+S^;3m>7Eg*^5KP90CXf;yqd5!1e{q z{&G+MB>%t!0J5(S#{Ig$;G+hbt3g65AOKdxfRw9Qd9S^@we{}XKlpF|;CGH5ot1&$ z5uraZKLL--zzDP-$@5Rlie%qW$>5BVT4;8;UT^L0Y+b){WpZrj>tFw}*0hg0hJkDv z`#lPHpInjs3dBIv@{r0|1{t~?D9XfS(CwKtN&8GvF6Re1b`%l{h~@`ms1JP7{%$4m zaNz-edQvJ694Gsg0lXid?AI+s3M8dJJ%5yeXzhWi`=t;R6~p9>Sp<)OFNZH z+6vog;#AAs%I=cF`YSJT)JB}Xu@i$5FtI3& z5!>BfSnimm)mm+*okk{!(=1J0&r5Bh2!@NnOV6L4o5+vkT$ccl83BOl9weHeeA0i7=*MMo-WNlnf12P zMxB90+Bmp3L_&;=kOB5X#F7AIq#8ZgY^8fW-_m%YI6F0c zAdcd8&sBvXA@9(Ug9gV?jj~D}f9jLBH{0)DUcY(!I?0d(HsrQSVP$pixwARPCGJNZ z{q;(qTJPSxwe{hZrPb9IkY^d|_42EqI(c;d+}V@Up63X#asYrqL>L4JiTXC$ud-M{ z1=OeFnFSG%$lCo9kN~1WVc-lz1NHq9?)xt3Paz_p0u<}G)M-TvcW&R>sqQrkXvTYc z)k8C`>v_zgNTCo4;k`wZ``8-Tlz?Io9OS!nzk7OL=#QiT#Ig|_>;>2Db~m=yZ!K0< zYguG;+U}@GjZe(x^PUCEtPl~z1qFm`MF1>;LIDI4)G&w@k$PlY zr?s%Lb9=qITZ^h&&9E05n`y0C&j6&z(3lO#93Ae!@5K7Pz0; z5+H!uKY#!T5gA0l3Nw+Drr4|{tzJ~F_n4GniMpYQT92PQa%8?FVhNGZWs8W)a>gVC z&Y`zf@q)3# z69=DcMmI!doW_J1hy@e^M8}?MkgnXmi6jRDJ;*-AFw8H{lcrSy*Rbf*eXk{x~ZraMu{a+;FQZ% z)TaS$zb-5&0+^<}u~xl(bG^J*3nO;jQWV#6LHA2vJbUr%fuSH6$p;7mWCzS3xC9P7 zpy|5r-HibBqvd`wwqKVR1TF|J`26ReJM$F&)!$vca(%lSw`Yb+Bc&l>3zPu4APxwkc!(lk@xIOy5jEa7GYTS# zjOsfQbOfN>=v`Z=UAeKlu)MdvQ`_0ABvE7~vmBFFsgM_pp)yK)r6F%&>AhN~`fvZ} zGowSf;J%VW0PP@JL!|q4{Cgf_;I8^#k3qVZ)6)l@IdJsiF z2(Sy_ATnUuPnCs91Q$f?;gIh(!P3~+NU`VvB9cKc zsr4Q0L0_Rs8gYLW9e~vc7y(4^M1&v%HUK^gbRv6YaqInS+aG?ky}8+LwVGMhn4EBq zpP0)Jx$UsKzFn`jx=BWOHjfEWQ6$Q2|8GkRp`+Jc1(A3ma@Q z5Xek2KR-TP@{kC?u@HlbGOz@}fca(tn}R|h2cRFeS`jh=gh-&kWT4PkSXe24u(0vb z(%#LD9n-UpioW>iC%*963uB`WIbcxA&Ft;>S6~0$jVQ_3n5ftGoM`Fx>T_of58B8< z>^_%sUy+Fq(hdx~-|_<@Aeo`>|HGwQx6+#nm3A11N%h!~(SuWkobrmk9-s2bu@>?2 zjm_odq+U^X?=G&cFaGWyy2SupqMwSIk6#JbKan9qArQzilf(u@F;g$fGTWEk^241L z_usDsNSGust#y^wIO&2B0wsVVeQgBwXPy}QL5mXXuhgiVUN_jT2HWis7&<(E{Os8L zQ$u6ta>LW)>;BrL{oLs6j88sT3gnMX9<#!V2nj_DqSJ1Non|}m@Wk=)?Q$(Ed)+K- zcj9WJGdYn*U<1U0+vU#Hk5;$VcTPNhvNSqcsm4TAw$c3TF$a9fNc5oAWzjX_W(oDW zhME09d4W=z>di1q(o(@M=3V9_6994;buWQVx8o@sEd*L?VCuw@MAmauE~iN8!5-J7 z`yStdvVf_9uxB|51toEUPFJ!FS*)K^rLm&tDPfTQGOhhyERAleT`CrR5=c|DsRY{b zTulUkO289j1eG!NBHN8J*5bK3=WDUhtaTMbX~@sz6fg=(v(f7H!e*o9c-j2nQgO%? zMkAhR>?W-+?d0{?ke5RN5KForgK8197E|jcMpA%4W6^U^1Vs0G_Rezs_F8LUs~T$n zKR$b6>dRk#_Q}%|!v(DzjI*?x>Kx_nT)DHlT5q@Gzy;fj!>zVsgj@?C42q$@LiI`8 zeOEDvIb{$t?^o#s+(s{Mb)eBTq2Uzd#AB!b`#*YhcHH_zr9xqJBxh682|wxP@e+1-<*d(P4x1yJe2?d7|TFPEDD1N0_r%C%=A}6K@ef+ zr*`td9ug=58AH;Lc$ecnNjhkd&<7wCXHXC#)qhie2MS~g!T`+VG<#SN3*!f0nm+r= z@S($AZpw9rh0qQ{Y>kjpjtBjF2&{drfdH)KOaP-WX*RmeW_@B*A2~F3`_53kj*60Q znAVy-0koW1(s8O*RvXu@-p%Ly=byj0wyOmsPMc!lBXjeC=c5Z2G6Nj5bb4IgX>PA~ z)>kVcFg`UhK0TB#_&0B?Y_BhW?zLwxK6a4BYlqy8x!LXRR-@}zuOFMAe&zWyEV8k; zQ>mI(Q^GJjIOjh9>`_EOFbr0}5mc#QrIBuJ*SGI(F5OxPitf;guA@2kQ zR}eCmMkngV-07OVa&qOyty5=bo_qdOWiPIlJFRNFRjqvH(@#!KJA%aEnG9<6Y=QOf_c#cbsb6|St5@=7vYK0niLYNrtINt&zk@ zmL{oKqck!zDjY7AhKp|A!G8ar7~Ae9th_MHJKkKBE{WD4G&wUnF?C>iQc02)11C$t zSk=v>-t#wW;qqSD3V4*?t6QbDufWYg$3GI ziYRTzahmOBwGn1UTn{r#8{6^q>w8;UJ5N7%?Bt1qo3))x!pwGZfu0&0_k6N!t;Q7e z@<#dgLgj~Ve6VG9su(#_?qm1;x6Ft@W)pP%t2CP$AS&Z9CG$%2zuSl{kmxw`z;TkmfyERE#c z$+^Snpb+Trn`(aBP5?Bx$HUt3rTZP4o#H#ftTwT)b9BDmSUb9;SvqgLK* ztgkGlmVW17KZ6>w3>I&7Z(U!1=iPr;T)QzcHSFd`+T9yd6UPGW-@bY2)R75PPM>|T znY0?x>tvaYCdc*gn3rTJNwBjMet2`^(#`GFmEEwpH90!+!gHrl8wTnovcB1R@12!z zee=7%iv~>W1bN>(Hd*|GufKNm=tM6`%C%;cpwdIuriEN-XE*xRx3AP5o1Pvo4v!Rv zMttqV@L1t9pMT-;r_M*+NLw@PyPr6HTpSm>SgW}XRtQ^-1d&xU*FD&>Hx0)ADowgbG64Od$ zx8k%DFD91}QuhDmZ>}CcJenreo$cipKXvixCr=TfHSB46c>5y3f4QeZ00ym9B0>sr zpVMk}v+dp5;e!VmnP@;u_X%7Pg8suhIOc3ONfxv0j*@j(HLzb|W7&tg1(og-V;1h! zRux-G3izeTsnX$7n9p|*bHE@eK#Bk$KC&K^3Wxyl-eU>?kd#UaRm)Me(utGy>63F) z<0GY^0!mdox)VmVdPflnN;frkR~kS3(RJmR&wcL2oFAlFuM<@a_ohdR#CFkPQ&m1;Jr7$`+C^h#sF(Am({#Uov_!reS72h;WM#`lpYES-d?GH@c!cK-+i;P zyZ7|j3!i)Cc^$xCzy9{hwe41%Sz}A1g|YD>fNbyV-CSH;*^A<6qSwi3?OnRE@r}Rz zRv5N=O;)xT^%@^tzxgHeG>g3V{`%t8_TPW=J5f}5?&ULQE*@%x>diOSu3X+#Os!V! z#TSnIMWvT-Bj;&_OoC=Qy6BFZ(e{?Uh5_v(HUv#(qAW&^dcLiI3P zSS-Kw!#jWb%^w^&H1qtkrwc>5|M1O^_SV}=*Y3Rb!r4PdrvPo(saCdY1fy&mu};Fd zci(O8Y#|cQ2AjmKNL6~1(StOJbS9-J5H85Y{9`!5ALiqZ!MKSxVpT)S*h$* zl3o|Zpb~JDQz*K_#X`=1;|Djs`o*VSdiLbnM*ACo{br?xon$1&Qlp&$I{@j@?d7ez zcYS2j>(yV#x~=X`rQNYqO{8l%jL|{YWcqKv`Q~_u;&_{Fd;Y-m;}=dl3bdw&i}-_Z zjQ-`6`k-AAecx3YQL!m?UGQ z)y!&@u1UM6PaiA>K`{sdS3_u7u+j*Vlzm5UZ&%)a_wvT}=9fP6#Ia*D+qF&@b(5@X zC7qlYEfsT&kO{1<_uhMN=ZzmMt}a!cdh+D&{MRp^Jv(E;O~u{Vy}rKLbbXqb$PWs6 zxtzT4!jogu2fzFFoe!>Wt#8+pUXzS@_VGiXef6_3%j<6~eRQMQi@4e8)@m)WptP4+ zwY*;c;L_?FZ(UxxyZYjD7yiw^{>?K-$GVBsdUm_<(T%$`AuN>&`9cu*&aDlkU{_fVw4vRT{`d~NduI|(qR(AgWJMXlc)vx{5 z3!nMI$-}3o_F5`UCcoQS+FaWR3VQlLfgCHOn5ErLIxXyWGQ)QE!2Hn2+?~btpZ)1K zF5kR9b9BDmjT*J`iN{7~XGV-QCet?;w%>YZ>3eT{;1A{h_<#7F<6rseIRF4407*na zREKh56kcA*KKfv}vbSDsCP*?m?4LU^cj@YS)G~$KIAqZ7My4m*)z}Ka4;;r~<#Ddy z2YHvsj0#_W;hA&KoR53;m z5Ufd>z1onr&1%;|dvw_K9dgwme|u0KA|H$U`|05yBa-VmzVBvPf~0z3ys}mbBje_Y z8Q8F+`;wn~36hm~&vtJ}xTKPX!=%9%P?0sE(cReXMUG_*f_OMcN4(V0KuAC?U?yM$ zjn*QZN)nTZrwoE4;GhtI1rR_3iu#$H^b61falHk=Eagrs>$cNeP9K;Z^|enQ@Htv1t zwNL)$s}~N;jHJffuFyt#F;44&uS+9&5^*W0x9q~L?d#XpmX@|>rYC>v%P$>0G~|1L z8plS0iBc)=c4LOgu|nV}LYST$^GcJ~mfM@tS#5VQ?lsO|nD~R={f*I)e7Cw;&~o6w zp_g8GJnHps-duV2!@HG6`HAxfKKHp#96u5`+K%N5!#QVcG}zlo3OSgb8FCz9utsdV zll6L%BC_!ORqln*we>v-dL(^6<>Jn^tsdXffHO?C||j}`@x6H zd)4+I|KV>RKQTF;gSB=iALP5emKy-0C6bY1@cfe}c6O@YdE-W-(r z(leD9nsFhMDRhb+cPFx4DAbBR`HqX^qNF06WvQ@mYHenf1y3=9Ve}9*i2`6i3y=u_ zgC3OF@2Tf3L{VC;w4=yO&x{p|E&+{?js>3feAi^UQf)RG35dCMW2;=*ed$x@A3J|o z5p}!Wuop*R2Eb!ug`r^zkZtbl+*w?{yR>3Wc<#*cPdqk1oI?jCwMv7V#R=PVD4#z# zGp7U`Bm&?h7Q;ytBg@Rx*sGs@?(C@%2h%Wdh6-*FV4O9kN1ge(aYbYk-rMRdEml^R z_mWs1J9pyDsj1;1rGW}ZChbTXp-o+q@zRh6Rv@SeBe1a}DP>V-e8m0gZ@zl*>@ipK z*T4Mg&Xe8A$pcd(!wbuccW*a#wo+#EgmiWPFqrZYSgOi#=rpg=4D z?M|=V36s?1^FvDIE?-*t=$*U6BV%9u%4;Jt=G3XtxY3@Up2+)77Q@1gy^XbQqnVD5 zjep`3j|GleU+P@Bw0Gr$YkPYu&zzs0nHxs{EpqDcjsP9?E`Rxhn?cB9_szw}(nQMmzkH`aMeI?bL|>6ueAU;D~So|6Tj z0wNI;iLFGk*~&U$z12VvGn{k3@VTdpIY&She3c8((~QDm3@Wc*SKb$M;KwQcBJ5WJ z?x|@CqObs=J274==5?(W3p$H;wr?&}4$n^HwYZ4FJP;@W0K_)k&AKbOxXfWM?&z@V zH9A=}G+i1s`2&Ud$7iR`X@9s{zuReCE=P9+Yot>b`}DosKMjmL<%Yu z{XftHoeKM99tjWmz^mGwEpMYMdM!^2p{ruhmvNjbyiF)|c0A-CE8E@bZi2 zOT+mjGObn|c8yJ}r=c{Gb36*OWNWv&y;pBE+e*p#^G8PtN=t&)<4CHzQJhGeB%{82 zaCTN9C`VfZt(I-IQj-A@PmULl92|AYy4q^5sy-Aji&|K%5-Dddz^z~XnCNweAtJ6(rlIG>*#pYjL=EDN@y zPOH~4Ha47IdjHChnkaAg9M^Pu-J``}ui)`$(IKVK+uX@k*LusVwN5W748t35zIEeW zy>exB<<9oq`p(4*^I!eSi>FS`0wSWy=bV$r50xfn&YnJ1t+)3oYdhs~wMwm4Sg)5W z)k$?fnE}|IV3X6 zn3yjN&oq;h|aL_}vU-eS} zC{~!QqqVV?6p2_XsUYn&>~6Kv?UqlU_;la|TFK0Kel$RdLZHH48hrP9va`6cvA*z? z-+1cD<41_G)642j&BjYRt@$Z;dTQLF+e_8rQn%i4GgAaiFPuM_3xqfW>qnt!G_!V` z#nz6E6z672s1gI1f>#esqeG2Wj14E9VkzzqO1te>+8z!|z*z1`r%1#_SkVET;SVQf|>^5uN zw8m*WjT;qgZKo~ChACEWzIo-s`A=)@GO~75nBdY*W1||iLy4l)VB`DW|Gx`L@?1Q0 zWd8GC{><|)o}WKBFsOhtV93qIM^OG)bbc6GrCNQuPOK zFE4HPItiewvsAJ~wW_w)v0;*=nK%#>o!ps&hlV^?vj!wUCZdrcI(~3+vb5e#LJ-j@ z^>#ZdA;Lkbr929;7K^L^ zjpL8W}>zk$O96bmC4Y%K2U~ucv258Mzzv_9{DZ z#;IhYvXP0r#Yk%_Sr#Uy)oZlE8dEYoJ*gBU0U(B{)SFqm+hfT*U&h9BjuxfSW>9Y> zt*{-Lmh!^+!^4hifv6oN+m&)V?qnFbe&QDZ6);;w)$AtKW-GP{W8&xi(XnAvBABLD zdP&yqhGCNB@`VHQ(}7RGF-WdIVTceX+3sE|iW4gdD9_Jp*B6$=fOKO{IZHVu2c~An zlq14GDyX;WiTtFpG%dhFC-UQ^U~FtOUl`8&fsRx9!CTiG9cuS3{RDo^!+< z9UD#=HR>=7t##%OA5U;3dV6_wH;I#2BrX(v-*dX{b{waU%16Ca<$_)>6;$GYhy^f= zU_g;pxm-@G*od%Ae2-iQg@MQ;3YZgX5l9K4?Nba7Soc76#6qMa!%QA|#Y|8G0%}C= zOQ*#$DSEi_`!R$Sx-ZNW+*eu(Nb7zN5afM&>f)Kdd*i+OW;a7Ih#%hA_{(p8@Y$D7 zADSoz1X>AaX`|6zU2Qh2#o_U@QxnHVCXSY7&Vf6&S4%Iyef@ji|B>%I&piFi^zoBm`uzmSJskGft!8 za4wg30YS(rO{LL1DdQ-Lvt(syyTH{ie&yncQ`3H6EZ8VZx=}Am(##m;xKmT3j$;I( zZdi#^Ou3!Qsf@%RX{1bSJC5t!s>ReoeDLrAKkx)I1~Jw)nyoNwnyjbD9GIKzbDPXq zZ-@1EGqpVxL`Tj{t6(5G>BezlVk5EW7(B=bG!i0)Cd(k}B%N52*~4?_kf31@gHUgE z(@?-DMS6049DtGf9YabOkRVN@S?@+k>I4qCWC;=m5jG&TZnM#=M_CU&oIiR19mS*p zRh+6;2f95rmLGfU_=_)pqMOAlTeU2*8=L6|A8wzRpD4JAfS5FEH_MWBC5y<~Q^!xf z^1{&^g`<9f*wL;|42Z&38}6<|S8we0VmGxaN!wG)M!lFSbP#}Gqra`4hP#F87EkNZM)})3L<4S+ij(%SO4)*-{G5CC}Zc6>I zl(z5c6rgBC!!~gB;e*33J%91~fBH_6y4orABK@tuU#QnQpMB-xW5>pe8cA|q{>1cw z&y7vnvFUTA(dpEvoiBaCRQ<0y=xxLn?|HWi!szH{W@Aw>!-XBPI#Vc1iKT_xV^ zfg^?$0Wvto>NpZbIRIH*E032Zja3NH4ozYq&J1c@94TdjmK*}rjidGTov;<5kwVcw zFgHukkGfO9puZd|BxE8~RaAp?;4%iOg)rkxAYsD@vxg3Y>lgrIAvVxxBv~r1 zrn9FH9y&bq-18^ieEYIB)b7|f-duh4x#PL{ycLT``9d*@A^^(gMmN_Rfgg-`flGu8 zso-{{y|dda6lYh~8_kaDM#Rbk8ostz{>JN9Uwh^F)JUOEH?d&50avc=EwAh~8ZDw! zQ+GILK5>42cBXiEek_eHqs=R~V66AUw-+xwe)P_eMK4$4l1D8N>0UGVVpuRgQ7TmR1MHz2Z6=yuWnhqt#E7IrS2JNDR# z)6=8HygO#SPZ^hQ@7m2vOIur8mp{7HZZ=MxJoexH@$a2DesE%}n9rl@ph9IpG6-DX zDI9rbl5k_$-D$k7#ULk!Q{k-NY%PPR_QxND)9+Sd3kawcr2zE?hY=c!cTF zk|u?-vvZy%%|^4ur1zVj{ruVE$6R6trIfe5y^|&+?3fg%r)GRdD*-M3NNy|&w_Tl2 z;^ceZyLxD@H00spLhaJ!t#*T>4hMQ9i2)e8p(*5?UT9m*UK+(|9L~>9PL{?sq6qdn z$<9_gOFWKqf#)go7$8hC$9JYCrmrpRX~}_gzVX)|jE#J{RK(l2%I{pdv$E0>Tkw6? zWRBxtx64G-=|U2bWN8+)#}1Sx$49jenVInZ_HrcPD(SVl);gUg{oUVR`LDioftf$N zy7b}Y?M5vXn^Pphl%{CeSfI_Vo-l|>lV1JYskz}ipF1=C^wY=w{#)DH8M%FD?=SxH z=KuI7PkT9S6->;|Rok_0tU)<%{P6PQ7f(L>#JG!yCcU$`^MC#4znYyp{JX#VwWpqb z?B>7!PQ(RZc6_%J>hJ#G_MOGm+3DhNG4H9sCaPYER#q#k+q;c=b#G^>G(s;u|K!Ur zTqqTtQ^%&xofy7!WskE=gqBvCfBqLAy!y)HQ9g_(V6{TA#!+f+-2Lh+PeH@H_10o0!@Wk@?SygS zwmNriEHs94MVAC6&TMC=yjd=95tx(5=0E$|vrk?;J3TQpK3a5?MG^!nfGi5o6%xw1 zrNbAjcFK42_1d=`DEBhXOxAA?dH8W8_mo%I?|2mvM5xu;l~%aEC(TAE7NcJD{(IL> zA1OU{`nYyrVqy%1)36Ikd~mw-%BP+h$~*0LtJ&`E)zj_mMyJz_HUSM-3T;ScbakREw0rCJ=eh>y>TgQ?DeAZSAXl(Y9-y- z+G|#;CX5cvp3{92mayH))>qdmJ55SRk^lev`9B<)(!$+mKmDmw$7g=<*85?Xhx21M zFK_>Et#5l|D!aQG_%~Pfj2dQv#hc~-^zT2^+`D-3l+HP;cUN2W9g|dMrVlF=0VMJP z6tIX03XY8Ec|9t_8T)qD`#ufy|uM%mf6 zC6XdVT}VlmEnj3uwv{H19W;%Tw1I=fd1xQ{FZ8W{Q2P(`f(A&F!a)(Vu@NVAtk_X3 z+p_Kw@0a1soU`{@eb{GsvlG-t(T9TTfgr%a4CkD)&faIOZ~ZqSGW!I5Taj7XqIQU99_}dw%BVmd17Yl@>A!Z zdGf;3Pb|*ObjC*W(S{e6F_r=dMFCGy0Ek9)&35O+(={~j_g7XQy}cQV9mQw@#eBw% z!V+XMEzm_#zV+7IKl-VFy>{j7 z&)<4~eYM-&?62JaugUS&OD}${R-d?a=jNbS4*KEkw{CoNUCv#YTVMa`Z-4vV_3Q7f zt#v6lIWv(D%S6s=vr%rYd{~yUvQhl=KfJ#<-@5$F8Q3#do}K&M@6P@E&)!*Ey0MAk z!NcCnvG!N5UhPbtc(8i=-s(+-U4Q@j>a8~x<|h{x+FOr$A6);>rIjr)nLpVkBj8{) zm`~$-piNHXU%qMOMiOxh0Coxo;%h0>%V&WAAj`o zYrngvLOc2#jjCK6UQ?pNBKJ%Sdzq~j<-O4ggX*b-1U{rWY(fFwXmw_u@V)Q!OTX29p!t}2 zNy>EhsmDbTXslq5BFyrvUdtvY^3nDvgodKkC>9q^hEV2S+HHR6xwEsUjyFb{Fa61d zcAHez^G3}#Cpy~d)Q_K-a^71ko3sY?#Pm#~rVD3UuYdpQ?EL6Qx9=83x6{rqoICZx zb1#JGTCH&V-lL7J&4t<7+1ZK3^K)}^6Pug!-}~On#Xv>mt5+|Lwvgo0;}f-S{@Jtj z5pHe|EEK0_$IhPYJbrP0`gnfawO)JmxtVtD&drB0?sO)yOOGu)b@3uy&9WEX`|y*X zvD0+t=Z>8{IraDx$8Rq!efKY(?{;I&HLt$-c(dW4QVKDVFeNO{?9vlcuYdpf(`Va{ z?mlc~JU-F5aPjnoOBYr)ie{sK`|eURca!6?aC-96g$pO=Ccggi<)@!KZw1ayO}1OP zz;eimareX5zBW6NJ-q)Qmf5kXv6J)7ix+37+S$b8Gx-m`{`lFsPj1~SieAmx*l6?g ziJ8lfUtBzWVtlgYGHYaV<*AcnqhG)F{_S_K-Fa|#Yiq6OZ3P(M1Dnzr9U1S8PR)!i zEKHp{KYi--#QcfzX6C&L6b^2x-G23z7f+o$@yp+Qbn}z-<>l_?`gRx;Ub6bJW^1%Q zfBM+s`RS)Fo_=g$zS9yKppMj5U0(anSH5(4T_anK`jyL%U{Rd8T83sFlM}UL6URnJj@5IQks=0aHPe=A|8&FJe>4PYX2#&uAXy}K z`dfG3d$fIfeBpd+{ERX45Wm-c+k*sHrJM(V)wRt#4_2aN5duOaI_Xb#>eG`GUOX)O z;O2vVKvvIYCjEFLH_LiG-nzBiR~wkY!+D0H$ko*)o0;rPOax;bgxbnxv9z)g!k|6c z=!~^GBclc^uXH!Jd)wV^yEW1oZ%d}mp$xItD@-ZE$#$#R6hRQgpl+ipODh}O-AylH zW@@aSOFhf7ydIhN2e!T4-&kAU>Gj&z zxj52voonzUt$<}ylBo|MU3M)YL%fb3~ zf2SWp5nJ`vNTWW|7$WEiFhT-=5F|vu)s4%mTU$F_idpndYVCGyYO2w!OIa56%pCyn zf6n}(THpcH)Ba6l&T<>t+l-D9ppVzL*w@oly5CIZSgV@jdsCGOOw?OVt!=R;rQ`pavCzS?OuHh?%NE z=}QG@H7RIOHTSMLC`dtR3W=1cs)&+H&S+U)kU=ev>dR=}xkL$YLN!EXG&tvlrW#X8 zKUq0yR1xt65C}B{SQgO=LDh=PM@J(l%mA0n78Ir$N>hmU%8WFiA2oUasEhbS_Y$gD zKp;qnDl+HNGv+Se%n%GAHDF?Ng3Kal@Hrr51Va>6afG8e2{gc1Iz*_N*5R=eC9grC z4ke6MS{Mi&O#~2nB<#H=jv9<`5`_UYNX>LO(rpT%f=Vi+-yejcghrS$a}+|1aoBoqp=7f47Q=syM}iPI-wtUsxuEIk?nSA3YG{rOxS@WN!_iF zC)Y9>jAo+7pb1IAM0^p4%t2^FHSHJ7s5Drp*!Ngv2NmwD+zVM&6$0}jfYE5d(tZw9 zFbv^u*}ihZK5p>7!gxeULGN>Lp)nuw^Cuqaem zRHHa&h`}P0fC0`)26cOyg-V>33jSW0iNK*p6lPAfZg9rF2pw|l%3iIqP@_;ad4C#H zEs*=YLbclDn1W_>3Py+-rJ7<=SQOHfvY(>*xtqUxutFU!Puyqzkyaebpaum^%xH{d zBuFQT_hRs1hIEN1Pmo;!BKMLr-OLPBFRDX}5H2?nFl?W@c{)oX>&AFixbWmFR4I$hI<@RFz1 zrs64>5(13 z0Jw@Dlh9=qk5C=p8)T+B#eXgao#fu;UF7v6kQt_?mU@p=EOh_*f4?vB< zB%MJIIFbfufQdR-I_oru&?sgwh*UFqUXUhLGnck9Cc^6K0imMCk}y!n2&2FgB9Sl; ziImKVhq+))jZvHj)ldRTW+}O$fKnV)3nvE2fISKmcPn31Aeu%K&kA6kKs-Yz4+V!c zrudvginbrC0YdFCG|(jNClrVQ^x~aGWtxdXdVWeCrdlN@~jeBa1M`;GIt^6PcyFKpf($j1*c-O>#I=cO41DplM{x5!4vPOVnsE4)0GD ztrAJLG2}*>387I%oLPb^G0_BtS-L%$0)$8+iAB}Y(U~Cz`1HL^=?XB5G!^(HG^%KJ zq&R5QkhzQ$1cT6dnkKolX$<0o&Vh&)9NjK`)l$WjKG_I?piq?*7lMjdLc_ykxF<@- z#tUF-B*igM#UStiV*+E70dN8*Y6yy`)vZQSiP-ij+^T!j@J8j}61^x2$5{lV`knh` z@pd<{ir~c?4D@0?kur%I=qidP;6yCZjw+L@w2?M|EQeAoKbhR`nI0lRYJ9~T`QJhHZb3UKdR>+aZ+?EL`xlD5;L( pD30PNsgB|(j*{vqj^h7o{5K13_fi4fWB~vG002ovPDHLkV1jdG0#g70 literal 0 HcmV?d00001 diff --git a/Shorewall-docs/images/medbutton.png b/Shorewall-docs/images/medbutton.png new file mode 100644 index 0000000000000000000000000000000000000000..6241d500a470c5742d6d3466785d2d90fe19e1e3 GIT binary patch literal 11185 zcmW++cRbYpA3tXt$HU%)s8kdoBjZrAqa_M=%Bo}+GR{#bWbbsMC9-G6oxL5|iL=i> z9M0|EeSd#^KA*??^Lo5LpZ9pJ=kxV`XM4*OEC~hx0AO>o8+Vw`U(CyZ6Ue+zLU>5b z2b+hHwGp#5J#J&K#%xOjn%D>4^>Ggja`ATq7`gg9c9S!I;o{+T$IZnx#IMgy4**cQ zVSdBtUhv zAMKBpW843pTG*@1*{s?e^Kp86?hog9b|cBiui3UqoK3?yZnO1uPM?*T>otoZ zlSSC?i&YD5k9xmITih~NyMlbjn4YuMK()Jk{h2x0_$qbtSJcSRlQ-!2Txp6%piV0a zxOczq7gvX^u;z>0@!wBpe_8#A5Z|_*W)3*i&+5U@kHn`>wgx|NrrvTeVE6CS$Nf`$ z^U2ShC#uO3l$l382mzteLmkn}{!itM9Z<@0tXz*o~F+4m=MYhE4v(9%@ zKlIrRik2THkcZz<`0ocnF`I6Ib;P}zJY2>O*h$vZWg+xr;2U>{8SSaGA7(DU^ClG+6$E?ckB|7>I76%}C z|Jix7QJP28KX2wQ4$^QUGo>ARUgQLN3fR=}lF(QC=bH!)9H8w!@_XOe559~oD+{Mt z)+mm^@YclrGP$D{&ZRG(M3a;vE55M8E~X2vWjijRdwO^+1_l#+r^3kxLgFtx%32+3 zj=D=QSO*tP7AGHckR8BJGKyg@K(xtDgf$(yM)d`sE|0r$V0D5mQI zW)xLgdN<}VogB4mI6Q=G(SBFyqqa`uyZ4KS8Ceeblw?;1@VdwAw`q}po-zf#i{DSV zxp|O?MChXrwI9!@oCjY~FYMZFB4U@Ng7iZvBKBoeDh*?6`lY2;RNNQ605g7{%3z2` zRvxV!;lQE0-a7P17Q3i03Q4io`K*B<_m8&{3O1~kNx8*6n$ise9bI5$^_4db-_vyu ze5>0!!0VAH2E8SOxYJjnqMKy!FJh@p3+Cw|C7WF5jKQhD{i{uuR{-m_5>ESL7@|TO7k8% zCkW^&4Rk$M;Z~Fec1ff{0l+wRQ-}WEwl-jm%sOexr&V1IQFTG}5`o(nkn%G%xi#0! znTW7~&<&#wa2S-)tA3FS?q1u2hPz`P$g+PC6dWFEE+E7D!mnVtN`$R8!(`L_(+M4v z4nwfK-dSw&C`a|0?QcAPf6?M#E_|OW`*WLlUYnz7D(E8{!tjCh4ToIDadi^E11#~$ z&kN_y4|2K6>M(ewI}l&AHF@3L?UI$StrV92hJ?7lJ$gsbO6g$dAmARC#ukN$MWU!N z-CJ;u2!mIrU2e(!8RKVNs}>3MVTqTH6XsS@zcKLL1_Gy2<39>V>MY{QA)Ep?IbQL) z!y0IG8h(g^PhRO78oGFSnDs{YZ^7M6f3#sReNk8H^B2H@ux{@>7R7LGq=W7ASrpjU z1y~Gt*>xh$db6BmXNi#cK-N*DtJ6W}-hRiUUaAG9Q3LDbQq0;|&bTE9y5S*ZcQuh7GjqAzSJ zVp=6Rb)AW(c!UveAd3=rQ4yEf@z89!X_;Q^8D6tC&NI+vYUWHOu|o`&(i`Wf45yK# zKCv%;-OfE#@BX5>pXFAAp%Lto@LH*)SOM5;fbH5vAKl{x92TCeChgoCq^uXPHz;K0 ziI%iVfWqmBZ{lBkbpsYd=C*|xr!S=Q4%~wN)Er1ni|*<-1lxPCTo)8qM*rSkIeO4Sz>K>-0={&6v&B^Z zcUvk5YnCepA2x;W%E;6)81$ea{ea_RDeqf$8cj@1H~h(_IW-?n-=`1Q$dUI}ai1+Q zYhJD3ls}WgGy+BTOg8mYdSoAe?|cn$I3e)?f-CvmTY>CE`W3a0zxS&`Ci`TuM$tmf zuPpo@H=~SRT;|ZU%M4ePH8LJ*vyaKo;OYfVu1cy!Ia&L3?Ls#UK&!s}vs$HawiZE5#EYPTSC(oSaNT!so*gAv;@` z9-r2->2OL%kF4PZZ(h60$%*TK=i&7I!%J0**iWq#aOtwDRHR{2q&1y|M+0W+wbch= zp99J0)7a9h)U#?wQm96Uo05qiPnCCtWz@sOwSr(9zkqZ?spxl4MXMpfX>i`AL6A zP(8kN%vNM_N;pkuHDr&>U7=ljCDZ+}d)VIL@_c~J;L({?w-azp=lEClGQ9{sWiREU zGdhvrCm9Cj)R!d9M_;>~u->?XLBiqLj5hT* ztyQWjd_N3+@9)vJlCU$=Bdk64_tRHZDk5AF^|Ofm@cqjb>?fd0CcsOqwN(=I>t5^} z?JZ)+$=z0`Y#2|v`lu+xm(Im{#SN(4;n~X>#-NFf3)A?10{@i?e>oc*DbVaXaP&a7 zwGs_BDR5Et8l)+yTwWLloW2eubP2KGD>4hq=Zb_;Vik0lJ)9=*I^gT8EjE3LWKe#;zU} zUrRk0EwV&!`@ZULRh!6U}3h-n%49PIXhZ zQdYKFpkH9E5OVRj%o<4T3$XcK-paO_>B9EF;)hIbZ@CZr@w0k(7@cdnqg^%?z58b; zR+dhugGvupZ!{X6l~&E*PvQS^CU`9r_{3%N58)9;Z*9@tL=(8aiAT}vhV-vi zcbhnV)a`ZJQE9k-bU1^{)cGEvPJQChzI!VYAfL?pr7JkMx^#pM6-KIs%}oeRIRitJ z(1GYTKa48B`?_MIEJVfm#N~Tb^estc9esVzzA84l_JGft8(g~T0=rtr_;(lfHFWK7 zJg&Ue%yRGHx|y#JEJb(~ms)Q$aw1HTkn}oUz?VFo(jA6q_3@ zfYKlt1Ii&^vAozSPFQGlIN^%0*s?<{V;FLdW2NkTg0tC!JvJje{-|hwVhL503OIZ|^?HK;S>2(BcG!(Yq%XurZ97T;B zwC3dY0~0D(woEh_(a(g;JzpHG>^umr9T;v8+vDVWv&d7<|M!eJ)vavF=YM?1=}7g2OIy+aU4{tfpFD)2e%X8X+{?~(BjsFXkJ zXM44+->PAsFR<=gp`1`dBYAyQ5k`s3kA9nd+*U1yd~&fK&d$dZd96Ev2dybuu>sx= zPydo_5KeGoy!DX&VWLpM)kth#cAND+1KI*M4%E&63#D^?(TeA0`XH9?dap@eeV1Ia zF$h{F6FN{?>wX|6c<$t_V@XQou4jS~Zl&M98u$FE9@N|38%4vX4M);!SChq39)hrZH4`~S3-i%DOhstD~od3oR!N~}&ddtbcg!sah6%Q|P=8P45<$tdUNk8gX#_ysnR%9!x z!5hs0C;IwaZhn2_2H;;@=1l1B1-o#xyRt@TGo#zgQ&mVV(w}oC5AsIGq#=D#Ee8 z=mVw!g%l35m6DIL5Q~t^V=;9VEh$B1BRFMW%6{xDZHzs$In|h%fcOIyjsSV~+g5Uf z6flENQ#JtbDKSOhj}O}eSj}4G z6grnZFN0qEVw^-PEiL3A-o~A_V&c8i^7?8EHkN3h^t3{D^GcZWM*-DGS}PAhzkfKR zh;$+zC0O|H+utQ1u)uDGq@?n_yyZ=15~3Jv4~I6>y63IzZ22{=v6Tu((m2h`xf6!# zk#OmjJ>hI#x#&C;oTeYV%QfjQGyYR#ZCj<5!J0Q0X)02|{d#HgIrX|0`XS$R^9co~ zqAsPbD8)T;7fxrGmYfjed6rtPrkI{a9P|tuX`N4woZHh`mpiOcFqndVdUDRC=cd3FU z640K*TTq-7C(5tTfOf3dAv3|Rg8q2zxJe|MA4i-Ej-+j!1>yRrdKb>LWY^Rz zJr_-AY5iX%Y+P#$-<4;!<3dBN%2Nl(an1^x%sAS$9lNRte~v!C)JyM*EzMm_S%1hM zbKA7Vo)nMWGFlKVuiJF4W$jaRQ++D3bVcsEOMu#0y(4cv*X|uXQlV>9Fl(YbyI-W? zm5lZK0ZF$vJp8W|>iqym^e^oLOJl3Yx{oVN3`JVsEwcrzL zPFFuXMS!QRYV-VWC3>IwK5eby=4~is(qUxXQSY0a^M_UEwA1E*>Vfn?ZCunoqHofs z<-t_N)wRvoCO~@5C>SlrX=2U<`#w^QB~jWhD_dfV=d5%SdF4r6Z%+<{Wa?3>^_QG; zHMOmch4x_hi`>Tf$5$_?i%dL;QU8wQo?p#3VQ(=d!Z#xDJedP=E) zJLp&DCfHN3U;DygDOe9O; z8%I$WU&Tx3Oy%hgD)7dvPkf-VFAXy z9Tx_a0wN+9)Ww}N6(8h9%YE(H^Ro`?xp~hxxexsODwATiM}YYGmL|Vw!o0rbf1c(v zSXGTi-zOarbO%xMxf{Jb>E|BiJmcmfe27_71prt&ja{$o;jzdm8y`A(Z)DU;|I+3D z?mHeD+c81_PB~HeKY%eJ#s_N9@a00!BZvH*C0M8SwRP3)|5l3s2biwj4EG}rl;q_s z4x2c%={0{WGSXCLF$64{g9>uSAJ};NGD5HZIy;0JNEKg>V9RjO_4;*qO*KB4Fc#Z!QoML^#b7a4c4LdE7a(uE?!Kq{FCE)WN_`MjYgWQOgi*!G@DQL5 zT<$|(=;{5nhcsEh5cKs>yQ5DGlOx_RBY}!&0$YJfOG}H4^v*E#;d45u965I!q*+ll5;e|Q67=un;3%*0 zleUVA3O6^mnAj9lAgf4AR+8a3*nN=uE+ZQ8E+6p@tnp_LuhoIV%Lz7*E8#kMi!?H1 z8w_upkYG!o2b4s3B)h`vHn0pQ`1Hz51WnQ!6bNsOsMqj~EJBItIq*)&q7G9|*4#8=_l^9d}t^pZP z1Dt*yen<^y$oicwE~}vMwPZf>9O^Y?b#PV81{!V-o;<6d6P090iJ<>2v8;Fg9<#}e zUblCDBG>^eY~Uyq3QngUs9nN7Q$tAK7daoHL;1Ngfb?&IBC<_aVDR>Q6g!!@? zH9@IBoX&7LA*^D{Rp4|r>IscOQ5m`7g`KHk_)}e;gfbr3e7LGZ=V^Pn~$%Kteuj{X5p{+2NbrG#k7@1j>*2vKe_%^;EJeP&GKqyY&@uANPoeeH-$Ft>GtM zaI~acWVT#Jdlp7^VwElNXkx+7m(XSkyPlMmcIwwJ(4c-{VWCC;GcEfu@fj2J4y!U? zI+VJfx7aboz+f4nhh%JR{d>h6DLi3~_IQEbyVFgIP?ypLK_EUM+Bh5rd3i1@fI@GY z@|lOz$Rgip*qi~I%k!_{bn@0L5xU+_`)FIJpxAdk1bR4C4&8Tt?3DnOH3%vBiav}# z^s|9oi}Mw^n?-)PJTGP4$bi7H8 z>BW77l-m~o>Kr3)lCXxcOT_~OfVEt09FV+A+QOs#ckxJ{i&c8Pe<2an;Faw$B&3y2 zA)M+J6%s14`EOpn=c%lji%|Xi#Kl5%D!^a#?-U+h;ciq=pgiCZ16^PRUO{8wJW#k= zGr2z~OE(Sr*Xq78a9y^yMo4uhx(-4Y^LT<|yV*CJR8Zqy*hZpuV4%osyuoXq0#?bF z+JT#Gzd*9#LlTp+EI0Lvey577h6D0S3`3Ev)WD_oy9JU$rz)k0^XlsAI@x_J(Fe?p zeBgsxU4Tv634~CW#uA(G8X0d_znm<7=BXi`kiHXT;0vo{#+t%<82CQ>ZP+i+6{fxr zdEKj^DB884os3Vvf5<@;Pnz4|Sw5}5!zhV0;`Kk97e)yf>%h(oS9V0kR9;fSvLsle z6LAiZaY~Ptos>6WYZ=A$8ohzaBVrB0Ne(xXEp425bV$Hop-hUu9LtCR#uvijGlq|# zw_hQLlplm0ZHmm@0kHk&fhvlL6kO108M{l?A+GgNbs1`EEfGZU`q{zF#6{B0Zzw2Y z$PnfNn7KV1S2HS^tx2c51)t^rUbqA9>oLSeiK?Sh$KiXUK=d74`;ZosO0LvQzZOWE z=uu%XbseN3oed5ZbGn=Ic;vQ-qaR>e%*{4MjAPBXU_3!Y%+3on(0Ta4IPN)}ES2;L z{{A3YeL~bbFMz&7L85QQd{I@B<(tj#!7{U=AlhydjT?C5t&u6a-s|JmLdHp#RQXQg z8*d1mSMnTF&5UmDt#p0o)|zAK9vjetLYrTsBCu)ovJt*j>ScK=g#Cf?m|{g6=dj}Q zL;E-t0v4WNh`Z!feK&axWCymv0=Rb=9r%I7G6KrQmUc3eFb8l+AQ>)TuIV&XYC&4r3N%*t4W=#I$r z$~fK}k?1R2`g3q_fWFM3XIhwnM3eD}yl&%?B2dda5r)t-_9vwiHjDy$`$cyu3#zd??bigzAQ6R_YdyH zXXPEu`n)obIi6_R&36`{t_@Kh@fkQalOD$5Fc{=T^d0at`gbs4;wTj9Jr_z^8zE*|W@94s+fHo&yFCvvHz(W~gdB-F}Yys#oJP5^rT( zdK26yct%?LeHTd zw}x$yL=2utqkp>IW;Cx>Q`R;Dz3BJ3_3xd(_ag+dDypD-(9W5VneSD_AN?;q<<(Z5 z`~A3XawRa+Q{w_PErz^UkSmy?&KSMr>q|N8BlYvMeJoc?=@0kh)kIaj6nb3T&9SC; zSi?h4Y{JqC*qZIW3LW>?|S>2fJqEBUn)?wkAvb86#Pq9UX)y2 zXjgvTR9O=G^hes}#zLf{-qSnxzBPW{Gkf0}@y(d7DsAbMz5VKbYTdVk%Egi6QKxOq zxh@9l#E4OAZ$-UwiUb&^SG+e5*vMXOh~#L ztCzBD^J<>{UfMBcRzEqr^i!?XFHg-%2jQAxt!ZvnE%tRWMSaUHpTLag%c_2o)~D}% zIoulm5ft{uR2+7tD+I+ZxBTp(U|ivkzxN)BMvEVQhGpL5m*ns+G?5d&7yq!%bM&`$ zUWDzsO|D}xan@h6)DD%sMjRC{q@k(eO z@U2iZ{&}VGz9-(~<|Vrs(gdMDthrCnps3D{Uy1VY=rh&&<@clcoc@v$fR>L#`JcAK zk(}t)`OO_~j&m4SSMhLm8lo^)UC3#n4Tdz`{(R0Y_B-*d;LMz4Eb`>M)XO;@lg3c} zrmzbZoA$Px9MK3vx%?1d&u5@PB}n7yHt*ch#XPHosIwb`c|DgJoG$y+KN_pq+Rjpj zV=jY|x&OT*$MudBh}FiqRrceabhbMwEGD0SpJK)~)vDimcY^%yG2~STU4$g@;3jwp zabjsy%&(F7v!gipnpbD%WBK!MJM+BG5-nDK)&|}2RSms((W|VBE~;;E|J_LLW3`(d zVWnZA+{$5WtmSv;Pe zZJyYuw!SwlbKS2#yp)$h3Zh3Q#i*7SoGlHr`Ttl^1q_wZH>Gryq6?+_&7%ylx$9=C zm&SfXpcQln+WhIii#!1kZoN z>%Ru|hw(5nR=OG+8xanK)lir;^=<|zqYrIGSeXcdMQ%NR9~U3b%F28GU}?344{8|u zoF)2gR+gB(d@E^>+dg6I2PbPSpfLy;7J9UnmPTjHV#H-pF4ugI!`&0kRq*SFZtQ+9 zM~TzvoHb&0sX{9_ci^+wH`@O71kevPT2F6pY0+hb4m+#vc)oz0X7tT1Vc``KVc|&c zCdzs=0FP5aq5zK$;B*@M&V?tg?lJio!0*f`iO~hXHyG>>>NT!K4qH9Thh=R6coF78 zyLd~>5f@|{IhYCEIoOiR6SwpX0i!KPmgDT43mL^bM4?gIhy~%Y zlX_zK$AVn*uQS!ZZoTEiB1?Tuo<4p0^5s!|dpbC%+ts53c`k*6 z?K}0zoP#cCj#F$)$6R6fImqTP@s#5g3uP^=8sGw)Np3F%R(S~J5qv7n#H11bwfEqI7@z4+pzM5ZjdtP72UGr zYD@9YtU)6k6vRbD89VvZy24)0V!=%!v-HhG6|BPAq034QV#kcFdMpI4j^O6!|6?U`|Zl`&5OHOr@(Str=W5x-CVmcASBnz3Sdnv*U04_@>-czNt5R}8@l z@@dH&gl%PLhn^beWdG(+pol;m9PDVp*nK?ECFfPxg&V^t1{E8;gFS=F(r7tmUQ8hk zBrRt#h8+S{cY2^8OmhU2ZcTfj%!F$bQ~WyNM{`NC(A6_+kr$cgp+e|uAlTc3^$BDw z1_f*iD946#hyqR#%ALaZ2%TLIw06S*H>o5kS++M2DuY7%a|&j;6#KsUeDfj4Ic=Ce zm3GYv z_V1%I6cu&rlGme?236vpEln@%m&BWNq>c%OiQwuUj<_aFre$)#sh zv=o(8+avSy>+z`abyYa|fLoQDMq{;L@iCyD&}pEsHqZ*-G;E)Ddz(r=dUWT_GHDBA zI2vjrk^3EKmm>Dp@34;*c7a<>>fW#IYyKXSn^IzBC@Nw3MS~EZkPxAt719c)G_5W~ zCn4*HUl3wUK}-gXN+D!r#S0PcnZgbMC5!JnRmL)*2Cr6W%mYD4RB&Tn%7*N^eF@x1 zQ@%{}K(LT%3Qp%KWR*AxEZGWjrc;g_?i;a)XQ5CLZf;aEZmQ@0ELK1KsHkN`P2I2}biYNa-as$x zP+rk-|9D4>nYeD}1Tpy$XpCeOIwlP;B`a{++3X&IciHtxJduChIS|*EMm(kN{FUvZ z-s_XKp>kR4F`F>@J~C$!Gljvg-pG-2`YbNC`}Ps?7dB*dq?nRcvNKR*lIM+A=)Jdsn9J#q$`g5v0L`*2(v8y_R`=?YiyMm#8pT5Bo%r3dVt!3kLmq` z6S>p)9pi~AWjy`1pi=EK_8h*VFEw_y>7wFMa&pn;wkyd=i@rZ{TJNdU&w>Fkmxq%Y zA$K3jKhOI1R6E4G&$zlVxOSEpeoNr~{Ypo{&)NP?VnJ!zv#DD=i$Fo^J73RUl>~Dx zeb6%krEqnqYIK~||E)WFPuw9>=L3NsWm{PO;DLa)aN6p__g7|1w|?V778rAj7@Wk1 zaA6Za>47R`b3w7@{a_x|g_I}ToMom(0{d(ZXc!k@7CF2Y|6uOjne&nSNrQDT$(T;9 z3)VSR=f60LwGMX7zr1$phtZhEkPplH?5| z{qy33C(Bv-;zKtyUWO#Za48Q1tVE<#Uq1BK&fEpj0Qat_l<;@+%{};3HO~9yK(WHfU1?ebQb4}axJov&~0u3GpCizPkhsMzZ0*!4)m@UABBD$6uD7T zm0ah43K>!mZ;8~9Tf2QY@W9LS6>R+9opXLtZ+p~=_!Vz~t4kdm-$#E3JT6_IKi9cm zt)U380r6=J^2qSTXcQTCm;{@SpYCwxKeG2=lLIG51Mads6hF;pT3A_`n{>{y*|{`k zVKiz(paCy8{Ou@N^-Pr9^%}M!4saw<7Yq2t$}AUVH5Wnh5{^ literal 0 HcmV?d00001 diff --git a/Shorewall-docs/images/obrasinf.gif b/Shorewall-docs/images/obrasinf.gif new file mode 100644 index 0000000000000000000000000000000000000000..e42c91b84526cf1e304309c05715069b2316e665 GIT binary patch literal 7298 zcmeI0S5p&O+lCWJAcPDCBot|Z0EQj~l$H=`=u!kkdI#w}G!4~IrG?&0=tvb%)KH~K zQIMh{2q*%wQ9yw$_`2Ue@SVH|-@(3To>@n0&2zM_xi5mQwt}K#03ZNxC;<5V8}NG) zF!>uW`A-0o1%OF6K*1!Spa4+d25>6?xcw7=n=C-q4IukZ0I~qUf9KEfe@E~)vys+K zGYvIkt*g=)df=ZMg6Dh$PdD`tPj463KqN+54(Sw*v-S!>M~)fS6!Rt`xWjgefMp5JdoYW~vgasxnNNq*)8N=&FRv)&!R`79#NtOaM&(ZNuekyvpi ze5Ybjt4!>sh@+FK*=2kcMKY-LSX8#S50mUGG^^XWS&_h;z$QN4iB3_wQmE%M&O{ln zFzfiF++dU?)qK-7bbkIw;uepJXY57SJ(SgLw+^b-&CTs9fwR&aCB(1|f7s#pn%tdl zQWU$pd{aBy3j#4Vuph73Qjg+qbvfd&tRB9U4=QhPMPp#C3gK~~bWJX0zjqgAE7xZu zb+aMk04OZKNvg&mxwnIUR4F&LV$jxGolSE&X^jy?tZ;6>9*~j;0VmXfil6cNjk1P7qyn?&AE8x=9PNL-a{D7qN-YyJg9A*dL2fQFs>)y?CI zDCI&Siqq6T;4FtItLbuAG8WT>pby91jGDRk{djR(=!~6Mn`} z6ddB+Ywl?4`EyA`^*!V*BdbezVS%zO13LhlE}Ub37V?5Q7tD)Elz=!a@z`hkEV;tT z(LfUBQ>(lIki;RbPtT&Vv{mREuNW_-6g9Mbfl)=MP@`4nlnYr zTp014Ezew~ZZF!I0Pfmr{*drFPtasZ>RVxe34Oj@JMC%iuMM}&Nn5DxaeA!rLMV7U za#ZDvztxwc1*iR1MXW)Z2y)e)i23?pbN*fDYa2l)?Q}DlFU)VO zyt?orCLzuC5t+>sQVUKy!IC@*)URz?3iq>H-x5?y3^Pn$KP`JNaN6{9#U^~a`NKWS zV2oel%dbBwxhrji)>00zZL8|&bD{N|b?C`vR^zR6e2#z)Z69a1*^JB_I{o;jHN|sE z?tUusXU+mrhHLMen1vUNTM_<*ldpHeriw?aMj2XLS1Jt4_oEJ-H39FGu6|WXr+sVy zlmMnd+0BemLjvWm1&51X7gb^(_b%kGHShBX*! z1ij^5$h-1IDEzInoi5$2BvY;}!!u&;uU`v_S83|T{SK6=I%68Du0iliK4%sj9rs(l z0r+dCY;sh+MDN#*30F>eB|G`DvG=ylYQ!XE*PTU@Z%@_j=B<7pT{krQB=on96j**BPjVm_vP4C=|kv|?~dCaURvNriJUC-?yP8QG!nCi6{ah+6BXt<$l`37tm``Ndw7zv8Bz zvdMdCN4wZxhp@73OJSoZH8$BN3(vt8EmUD|>AwlxG@*wrUOir~`HK_>IiySdz~Uov z)=S-q@}kvJ#ja`v%hSn7?5KB>SN%1(eu>W`!=y@nQ_l+cA0qy*fVUk2gJDMI{gEjf zj~VSSR#Lw>aL}^WDC}LlEaYyu zR$dm!B$EmN!yqv4JUAQ#VR8v7{sX;;9>*{$HSiDf9>JI%{(;`)*u=}}(eW{560E>9 z%8W)3F7=26+1CuTXTN>^%uE`h%CuaF1F;ek2~++ua8-1&*`LwdnXs9ZyQ3aBGXMC4>~z=G93nPh8Q|t zlvsxBulOkc>pY8mE)Y>JLMn` zoKCnC}t9Ue8l!x~o7TjOvBMw7|{u?BS&kbY0@DrTs#^Jm3@lON=|W9~*mFwUi;9RB8n zJCowUFl2cH-jijM3$AFa39`QZgdxY=V@Er7!(7lf=oQCCNvg-20DcWKE}Kn5nfZ1L zjyo}5)~cn+mb(vtJ+C!-f$aI!!XFXq1OB{4JA{^?48h&%x46;U1H_7D4nC1Wa%Cso zr_Qu-`E)IrN1&ZLhF7{T#7uI>uR`4CT%-*;vAb-shZ%K?STN-Ep~)eP~Vs-0wKQ{>_ag zpG&%&FNfh{!aD!AX<>nhK=!ZtEYG2}W@m#yuS^5ck&tA)C@Nrc&<@9uCmkxcZS|L@ z*|#6=7r)N?p^r!o9?LHM6~=HDv%v%nH#I&91$~Y?SBGmW!{W_+=xrZ)@^1CaQ@(C` zGTP9?xTe&gi--+YSkV;4pQ@m_aT#!3l2P^2I+Y*ZngG!ea;D9x<$7rOXdAFn0jpP` zdO|$sRbpwgO~iOEhk!69tD#zj&0*cGMnn1?8!KPpi0DX-ahTqN@MSd9B0L2uSwGNH zeYrQ07=Y!TO*G;dQ{HS%5eU6Ggy0X-&ZKOzMA8*7AbOu&jbF=DSE)p7DUf6bw4yDM z1nTiI5bWaz6V<3>eyY`>+XjtSM&?{bBwn$2_9CK>TNlm$Bjr;GKwU;qy|n#E!x8=c z{s+{hW7sQt*K!~`IfectHB_DEauq76Std+>#SpA;CDhsYHB5q{zl?psVYNs$8kmtG zVRhlNil1$93Nk`3Wudn5Bw`)+p#O@K@flRwr!eErm-H0R|W>DLx z1t!en7!i0x&7@vkaq?+@G40po^S}fBeKbZ{AOj#i;m^nU<{>g(y!3wj*v!sSx~QPM zzCzf{3-9Afq;T_sCr+_V0e9#HHzr}(zr-;d$A#Gl+bLWhpZA0^nCyU{iIA>*$i5na z(RB+&<CO$4 zti2i&>)ql#bQNu73YV3==gaZF}02FWvld`OL-MupA6WQD<8g@^fDjizQdSBCpJ4f?@4-k} z|7BmHTE|_Iw-5nbW7($;s_f4w{-^Z8{@`yM);2a-Kg~2cJ_}Qhf`J3OI-e7S3ldF| z;JN+HDHhR1(osOj{`=?M`8SG#aDNIPNV5V5L%rChkFzozJqZZdpYBG3c9{a(QGiwy ztBt(E);OgkaVvPZUU<{?0R!kv$fj@+>?~rxJ34HDauk^;x;zrDuMlKrD5Vg0Rd8r0 zHK!~lUfg!v$uPCXIFGFaG3z$hC?D**jbd%Q86`95i+DBP2yGU23}n+!X`FBLIO+$P z8(Y3N`LZ{f_4ntmSq9z*oAP8Tt$`tuxcQYpDw1t;)h9ut@Ha^P^$hp=>Q3mdE3Ayr zjhknd6bR6!Z1;-ucnYJm275BVw1QP+0d^B5xLYSj`c8or5fP)x%i|xV=8c`r@mCGx>KL7niDdv4aWew(tJux<}RBO=J zY-I__W6N@H@wnd36 zeNQIftVlPFpT0k#3mn>9b9SkceLW~J$$a(p*E;Rwrb?L7(W~qM%i~`MWa8f3cM}Bx zK7TElAC8@`)xue&L);Av>8c#&(#E!%f_0^<*B?8!guU3K-H9ySYX(=rQqsM?LQ|@ z-TOO(Bw>M*!w7}A?UkkNU+T0}zEH5&yX_qYEi=e-&MVq*z5mRA7hi4&ZL2@v4_Z+R zePOg5hCE)|^CxsEzFbKPoDphq(PK)Uok;653BdeC2W)B|yQEVSbsqc{HEcI2?8g!D zOss4rzDd1iza9eoDAQi(_GGnmb${ep;Tb?I-QUP3R*mTm?1o$?Pyfw*clI+eCw>+l zFr0TZZn)kz)|E__z;Kby9shz~dNP1w7i@UU&EkfHu~nyEe2($_7--*K3TN{NG%@*K zH`Zsa{v*LSeDxuWc+TojMCNCTh_~8dPCn8^Gj0oN+k85Cpw32*zDo-~Kdg$SA|2GV zjH}GYJP=|7DCPG+lC0f^#^0@PBwx;qFiyRKUHFyxgu~W2)VjW^C8J&Z6=f>}N3s#R zzNpAAy&G1#UrDJx2I@YQdhqff;cf6jD{D4-Q>b2^l_6rl55i z#4k1TPmWXvT5TmOjJE@9CIcfYT_3f;~K|OR$|<1VqXTeBf{- zo5CrKd0ZgM1|TQZZ7nj+E2G=X=e}%Y$UzZ|iVs;>R}TOZfpf~1rRa-21!3^ zv&PLIX4<+>Ac>1(x|oh4DNj>uq$sD(H97uWNzWLag>j?M&c^p1Uh)OAi%_Aq!oDV- ux5ID^L1&dGh-6NL;{ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - - - +

      + +


      + Powered by Postfix    

      + + + +
      - +
      +

      Vexira Logo - - + - - Shorewall Mailing Lists

      - + Shorewall Mailing ListsCourier-Imap + + +


      -Powered by Postfix     

      -
      - +

      Note: The list server limits posts to 120kb.

      - +       - +

      If you experience problems with any of these lists, please - let me know

      - + let me know

      +

      Not able to Post Mail to shorewall.net?

      - +

      You can report such problems by sending mail to tom dot eastep - at hp dot com.

      - + at hp dot com.

      +

      A Word about SPAM Filters -  

      - +   +

      Before subscribing please read my policy about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
      -

      - + at shorewall.net checks incoming mail:
      +

      +
        -
      1. against the open relay databases at against the open relay databases at ordb.org.
        2. -
      2. to ensure that the sender address is fully qualified.
        3. -
      3. to verify that the sender's domain has an A or MX record in DNS.
        4. -
      4. to ensure that the host name in the HELO/EHLO command is a valid -fully-qualified DNS name.
        -
        5. - +
      5. to ensure that the sender address is fully qualified.
        6. +
      6. to verify that the sender's domain has an A or MX record in DNS.
        7. +
      7. to ensure that the host name in the HELO/EHLO command is a valid + fully-qualified DNS name.
        8. +
      - +

      Please post in plain text

      +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"!!
      +
      +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.
      +
      +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.
      +
      +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.
      +

      - +

      Mailing Lists Archive Search

      - +
      - -

      Match: + +

      Match: - Format: + Format: - Sort by: + Sort by: -
      - Search:

      - - + + +

      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.
      +

      +

      Shorewall CA Certificate

      - If you want to trust X.509 certificates issued by Shoreline Firewall -(such as the one used on my web site), you may download and install my CA certificate - 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.
      - + 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.
      +

      Shorewall Users Mailing List

      - +

      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.

      - + to get answers to questions and to report problems. Information of general + interest to the Shorewall user community is also posted to this list.

      +

      Before posting a problem report to this list, please see - the problem reporting guidelines.

      - + the problem reporting guidelines.

      +

      To subscribe to the mailing list, go to http://www.shorewall.net/mailman/listinfo/shorewall-users - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-users

      - +

      To post to the list, post to shorewall-users@shorewall.net.

      - +

      The list archives are at http://www.shorewall.net/pipermail/shorewall-users.

      - +

      Note that prior to 1/1/2002, the mailing list was hosted at Sourceforge. The archives from that list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

      - +

      Shorewall Announce Mailing List

      - +

      This list is for announcements of general interest to the - Shorewall community. To subscribe, go to http://www.shorewall.net/mailman/listinfo/shorewall-announce - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-announce.
      -
      - The list archives are at
      + The list archives are at       http://www.shorewall.net/pipermail/shorewall-announce.

      - +

      Shorewall Development Mailing List

      - +

      The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

      - + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

      +

      To subscribe to the mailing list, go to http://www.shorewall.net/mailman/listinfo/shorewall-devel - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-devel.
      - To post to the list, post to shorewall-devel@shorewall.net. 

      - +

      The list archives are at http://www.shorewall.net/pipermail/shorewall-devel.

      - +

      How to Unsubscribe from one of - the Mailing Lists

      - + the Mailing Lists +

      There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists. To unsubscribe:

      - + from Mailman-managed lists. To unsubscribe:

      +
        -
      • +

      • Follow the same link above that you used to subscribe - to the list.

        -
        • -
      • + to the list.

        +
        • +

      • 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, or unsubscribe from <name -of list>), enter your subscription email address:". Enter your email -address in the box and click on the "Edit Options" button.

        -
        • -
      • + "To change your subscription (set options like digest and delivery +modes, get a reminder of your password, or unsubscribe from +<name of list>), enter your subscription email address:". Enter +your email address in the box and click on the "Edit Options" button.

        +
        • +

      • 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.

        -
        • - + and click on "Unsubscribe"; if you have forgotten your password, there + is another button that will cause your password to be emailed to you.

        + +
      - -
      + +

      Frustrated by having to Rebuild Mailman to use it with Postfix?

      - +

      Check out these instructions

      - -

      Last updated 11/22/2002 - Last updated 12/27/2002 - Tom Eastep

      - +

      Copyright © 2001, 2002 Thomas M. Eastep.

      -
      -
      -
      -
      -
      -
      + size="2">Copyright       © 2001, 2002 Thomas M. Eastep.

      +


      diff --git a/Shorewall-docs/mailing_list_problems.htm b/Shorewall-docs/mailing_list_problems.htm index bda792a3f..ed5c51230 100644 --- a/Shorewall-docs/mailing_list_problems.htm +++ b/Shorewall-docs/mailing_list_problems.htm @@ -1,50 +1,53 @@ - + - + - + - + Mailing List Problems - + - - - + + - - - + + + +
      - +
      +

      Mailing List Problems

      -
      - -

      Shorewall.net is currently experiencing mail delivery problems - to at least one address in each of the following domains:

      - -
      -
      - 
      2020ca - delivery to this domain has been disabled (cause unknown)
      arosy.de - delivery to this domain has been disabled (Relay access denied)
      arundel.homelinux.org - delivery to this domain has been disabled (connection timed out, connection refused)
      asurfer.com - (Mailbox full)
      bol.com.br - delivery to this domain has been disabled (Mailbox Full)
      cuscominc.com - delivery to this domain has been disabled (bouncing mail from all sources with "Mail rejected because the server you are sending to is misconfigured").
      excite.com - delivery to this domain has been disabled (cause unknown)
      epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
      freefish.dyndns.org - delivery to this domain has been disabled (Name Server Problem -- Host not found)
      gmx.net - delivery to this domain has been disabled (cause unknown)
      hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
      intercom.net - delivery to this domain has been disabled (cause unknown)
      ionsphere.org - (connection timed out)
      initialcs.com - delivery to this domain has been disabled (cause unknown)
      intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
      khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
      kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
      lariera.com - delivery to this domain has been disabled (Unknown User)
      littleblue.de - (connection timed out)
      mfocus.com.my - delivery to this domain has been disabled (MTA at mailx.mfocus.com.my not delivering and not giving a reason)
      navair.navy.mil - delivery to this domain has been disabled (A restriction in the system prevented delivery of the message)
      opermail.net - delivery to this domain has been disabled (cause unknown)
      opus.homeip.net - (SpamAssassin is missing the HiRes Time module)
      penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
      scip-online.de - delivery to this domain has been disabled (cause unknown)
      spctnet.com - connection timed out - delivery to this domain has been disabled
      telusplanet.net - delivery to this domain has been disabled (cause unknown)
      yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
      -
      -
      - -

      Last updated 11/24/2002 18:44 GMT - Shorewall.net is currently experiencing mail delivery problems + to at least one address in each of the following domains: + +

      +
      + 
      2020ca - delivery to this domain has been disabled (cause unknown)
      arosy.de - delivery to this domain has been disabled (Relay access denied)
      arundel.homelinux.org - delivery to this domain has been disabled (connection timed out, connection refused)
      asurfer.com - (Mailbox full)
      bol.com.br - delivery to this domain has been disabled (Mailbox Full)
      cuscominc.com - delivery to this domain has been disabled (bouncing mail from all sources with "Mail rejected because the server you are sending to is misconfigured").
      cvnet.psi.br - (DNS configuration error -- MX is cvn-srv1.cvnet.psi.br.cvnet.psi.br)
      datakota.com - (DNS Timeouts)
      excite.com - delivery to this domain has been disabled (cause unknown)
      epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
      freefish.dyndns.org - delivery to this domain has been disabled (Name Server Problem -- Host not found)
      gmx.net - delivery to this domain has been disabled (cause unknown)
      hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
      intercom.net - delivery to this domain has been disabled (cause unknown)
      nitialcs.com - delivery to this domain has been disabled (cause unknown)
      intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
      khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
      kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
      lariera.com - delivery to this domain has been disabled (Unknown User)
      mfocus.com.my - delivery to this domain has been disabled (MTA at mailx.mfocus.com.my not delivering and not giving a reason)
      navair.navy.mil - delivery to this domain has been disabled (A restriction in the system prevented delivery of the message)
      opermail.net - delivery to this domain has been disabled (cause unknown)
      penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
      scip-online.de - delivery to this domain has been disabled (cause unknown)
      spctnet.com - connection timed out - delivery to this domain has been disabled
      telusplanet.net - delivery to this domain has been disabled (cause unknown)
      the-techy.com - delivery to this domain has been disabled  (clueless administrator - continuous DNS problems) 
      yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
      +
      +
      + +

      Last updated 12/17/2002 02:51 GMT - Tom Eastep

      - +

      Copyright © 2002 Thomas M. Eastep.

      - +

       

      +
      +

      +



      diff --git a/Shorewall-docs/ping.html b/Shorewall-docs/ping.html new file mode 100644 index 000000000..c282ee562 --- /dev/null +++ b/Shorewall-docs/ping.html @@ -0,0 +1,90 @@ + + + + ICMP Echo-request (Ping) + + + + + + + + + + + +
      +

      ICMP Echo-request (Ping)

      +
      +
      +Shorewall 'Ping' management has evolved over time in a less than consistant +way. This page describes how it now works.
      +
      +There are several aspects to Shorewall Ping management:
      +
        +
      1. The noping and filterping interface options in /etc/shorewall/interfaces.
        2. +
      2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
        3. +
      3. Explicit rules in /etc/shorewall/rules.
        4. +
      +There are two cases to consider:
      +
        +
      1. Ping requests addressed to the firewall itself; and
        2. +
      2. Ping requests being forwarded to another system. Included here are +all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple +routing.
        3. +
      +These cases will be covered separately.
      +

      Ping Requests Addressed to the Firewall Itself

      +For ping requests addressed to the firewall, the sequence is as follows:
      +
        +
      1. If neither noping nor filterping are specified for the +interface that receives the ping request then the request will be responded +to with an ICMP echo-reply.
        2. +
      2. If noping is specified for the interface that receives the ping +request then the request is ignored.
        3. +
      3. If filterping is specified for the interface then the request +is passed to the rules/policy evaluation.
        4. +
      +

      Ping Requests Forwarded by the Firewall

      +These requests are always passed to rules/policy evaluation.
      +

      Rules Evaluation

      +Ping requests are ICMP type 8. So the general rule format is:
      +
      +    Target    Source    Destination    +icmp    8
      +
      +Example 1. Accept pings from the net to the dmz (pings are responded to with +an ICMP echo-reply):
      +
      +    ACCEPT    net    dmz    +icmp    8
      +
      +Example 2. Drop pings from the net to the firewall
      +
      +    DROP    net    fw    +icmp    8
      +

      Policy Evaluation

      +If no applicable rule is found, then the policy for the source to the destination +is applied.
      +
        +
      1. If the relevant policy is ACCEPT then the request is responded to with +an ICMP echo-reply.
        2. +
      2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf +then the request is responded to with an ICMP echo-reply.
        3. +
      3. Otherwise, the relevant REJECT or DROP policy is used and the request +is either rejected or simply ignored.
        4. +
      +

      Updated 12/13/2002 - Tom Eastep

      + +

      Copyright + © 2001, 2002 Thomas M. Eastep.

      +
      + + diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index a5014f5cd..e643bc6a8 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -4,73 +4,86 @@ - + Shoreline Firewall (Shorewall) 1.3 - + + - + - - - + + + + + + + + + + + +
      + +
      + + + + + + + +

      Shorwall Logo + + Shorewall 1.3 - + "iptables made easy"

      + + + + + + + + +
      + +
      + + + +
      + +
      + + + + + + + - - - - - -
      + + -

      Shorwall Logo - Shorewall 1.3 - "iptables - made easy"

      - - - - - - - -
      -
      - - - -
      - -
      - - - - + + + + -

      9/30/2002 - TUNNELS Broken in 1.3.9!!! -

      - Brown Paper Bag - There is an updated firewall script at - ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
      - - - - -


      -

      - - - - -


      -

      - - - - -


      - 9/28/2002 - Shorewall 1.3.9        -

      - - - - - -

      In this version:
      -

      - - - - - -
        -
      • DNS Names are now - allowed in Shorewall config files (although I recommend against - using them).
        • -
      • The connection SOURCE -may now be qualified by both interface and IP address in -a Shorewall rule.
        • -
      • Shorewall startup is -now disabled after initial installation until the file -/etc/shorewall/startup_disabled is removed. This avoids nasty - surprises at reboot for users who install Shorewall but don't -configure it.
        • -
      • The 'functions' and 'version' - files and the 'firewall' symbolic link have been moved -from /var/lib/shorewall to /usr/lib/shorewall to appease -the LFS police at Debian.
        -
        • +
      + +
      - - - - -

      What is it?

      @@ -78,41 +91,50 @@ - -

      The Shoreline Firewall, more commonly known as "Shorewall", is a - Netfilter (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.

      + + + +

      The Shoreline Firewall, more commonly known as "Shorewall", is +a Netfilter (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.

      - -

      This program is free software; you can redistribute it and/or modify - it under the terms of Version 2 of the GNU General -Public License as published by the Free Software Foundation.
      -
      - 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.
      -
      - 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

      + + + +

      This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the GNU +General Public License as published by the Free Software Foundation.
      + +
      + + 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.
      + +
      + + 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

      - + + +

      Copyright 2001, 2002 Thomas M. Eastep

      @@ -120,23 +142,27 @@ Public License as published by the Free Software Foundation.
      - + + +

      - Jacques - Nilo and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution called - Bering that features Shorewall-1.3.10 and Kernel-2.4.18. - You can find their work at: http://leaf.sourceforge.net/devel/jnilo
      -

      - -

      Congratulations to Jacques and Eric on the recent release of Bering -1.0 Final!!!
      -

      - -

      This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)

      + + Jacques Nilo and Eric Wolzak have a LEAF +(router/firewall/gateway on a floppy, CD or compact flash) distribution + called Bering that features Shorewall-1.3.10 +and Kernel-2.4.18. You can find their work at: + http://leaf.sourceforge.net/devel/jnilo
      +

      + + +

      Congratulations to Jacques and Eric on the recent release of +Bering 1.0 Final!!!
      +

      + + +

      This is a mirror of the main Shorewall web site at SourceForge +(http://shorewall.sf.net)

      @@ -145,7 +171,9 @@ Public License as published by the Free Software Foundation.
      - + + +

      News

      @@ -153,334 +181,276 @@ Public License as published by the Free Software Foundation.
      - + +

      - -

      11/24/2002 - Shorewall 1.3.11 (New) -

      + + + +

      12/27/2002 - Shorewall 1.3.12 Released (New) +

      -

      In this version:

      +

      Features include:
      +

      -
        -
      • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. -This option causes Shorewall to make a set of sanity check on TCP packet -header flags.
        • -
      • It is now allowed to use 'all' in the SOURCE or DEST column in -a rule. -When used, 'all' must appear by itself (in may not be qualified) and it does -not enable intra-zone traffic. For example, the rule
        -
        -     ACCEPT loc all tcp 80
        -
        - does not enable http traffic from 'loc' to 'loc'.
        • -
      • Shorewall's use of the 'echo' command is now compatible with -bash clones such as ash and dash.
        • -
      • fw->fw policies now generate a startup error. fw->fw rules -generate a warning and are ignored
        • -
      +
        +
      1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
        2. +
      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.
        3. +
      3. "shorewall [re]start" has been speeded up by more than 40% with + my configuration. Your milage may vary.
        4. +
      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"
        5. +
      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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
        6. +
      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_CHAIN=Yes in shorewall.conf. This allows for marking + input packets based on their destination even when you are using Masquerading + or SNAT.
        7. +
      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.
        8. +
      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.
        +
        9. +
      -

      11/14/2002 - Shorewall Documentation in PDF Format -

      - -

      Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 - documenation. the PDF may be downloaded from

      - -

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      -     http://slovakia.shorewall.net/pub/shorewall/pdf/
      -

      - -

      11/09/2002 - Shorewall is Back at SourceForge -

      +

      12/20/2002 - Shorewall 1.3.12 Beta 3
      +

      + 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.
      + +

      You may download the Beta from:
      +

      + +
      http://www.shorewall.net/pub/shorewall/Beta
      + ftp://ftp.shorewall.net/pub/shorewall/Beta
      +
      + +

      12/20/2002 - Shorewall 1.3.12 Beta 2 +

      + The first public Beta version of Shorewall 1.3.12 is now available (Beta + 1 was made available to a limited audience).
      +
      + Features include:
      +
      + +
        +
      1. "shorewall refresh" now reloads the traffic shaping rules + (tcrules and tcstart).
        2. +
      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.
        3. +
      3. "shorewall [re]start" has been speeded up by more than 40% + with my configuration. Your milage may vary.
        4. +
      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"
        5. +
      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 + http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
        6. +
      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_CHAIN=Yes in shorewall.conf. +This allows for marking input packets based on their destination even when +you are using Masquerading or SNAT.
        7. +
      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.
        8. + +
      + You may download the Beta from:
      + +
      http://www.shorewall.net/pub/shorewall/Beta
      + ftp://ftp.shorewall.net/pub/shorewall/Beta
      +
      + +

      12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux +

      + Shorewall is at the center of MandrakeSoft's recently-announced Multi + Network Firewall (MNF) product. Here is the press + release.
      + +

      12/7/2002 - Shorewall Support for Mandrake 9.0 +

      -

      The main Shorewall web site is now back at SourceForge at http://shorewall.sf.net.
      -

      - - -

      11/09/2002 - Shorewall 1.3.10 -

      +

      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.

      - -

      In this version:

      + +

      12/6/2002 -  Debian 1.3.11a Packages Available
      +

      - - - If you have installed the 1.3.10 Beta 1 RPM and are now upgrading - to version 1.3.10, you will need to use the '--force' option:
      - - -
      - - 
      rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
      -
      - - -

      10/24/2002 - Shorewall is now in Gentoo Linux
      -

      - Alexandru Hartmann reports that his Shorewall package -is now a part of the Gentoo -Linux distribution. Thanks Alex!
      - - - -

      10/23/2002 - Shorewall 1.3.10 Beta 1

      - In this version:
      - - - - - You may download the Beta from:
      - - - - - - - -

      10/10/2002 -  Debian 1.3.9b Packages Available  -
      -

      - - - - +

      Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

      + +

      12/3/2002 - Shorewall 1.3.11a +

      - -

      10/9/2002 - Shorewall 1.3.9b (New) -

      - This release rolls up fixes to the installer -and to the firewall script.
      -
      - 10/6/2002 - Shorewall.net now running on RH8.0 -       (New) -
      -
      - The firewall and server here at shorewall.net - are now running RedHat release 8.0.
      + +

      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.

      + + +

      11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format +

      + + +

      Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11 + documenation. the PDF may be downloaded from

      + + +

          ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
      +     http://slovakia.shorewall.net/pub/shorewall/pdf/
      +

      + + +

      11/24/2002 - Shorewall 1.3.11  +

      + + +

      In this version:

      + + +
        +
      • A 'tcpflags' option has been added to entries +in /etc/shorewall/interfaces. + This option causes Shorewall to make a set of sanity check on TCP packet +header flags.
        • +
      • It is now allowed to use 'all' in the SOURCE or + DEST column in a rule. When +used, 'all' must appear by itself (in may not be qualified) and it does + not enable intra-zone traffic. For example, the rule
        +
        +     ACCEPT loc all tcp 80
        +
        + does not enable http traffic from 'loc' to 'loc'.
        • +
      • Shorewall's use of the 'echo' command is now compatible + with bash clones such as ash and dash.
        • +
      • fw->fw policies now generate a startup error. + fw->fw rules generate a warning and are ignored
        • + + +
      - -

      9/30/2002 - Shorewall 1.3.9a -

      - Roles up the fix for broken tunnels.
      + +

      More News

      + + + + + + + + + +

      Donations

      + +       		M
      +
      +
      -

      Not getting List Mail? -- Check Here

    - - - - - - - - -

    More News

    - - - - - - - -

    Donations

    - - - M - - - - - - - - - - - - - - + + + - - - + +

    Shorewall is free +but if you try it and find it useful, please consider making a donation + to Starlight +Children's Foundation. Thanks!

    + + + + + + + + +
    +
    - + + +

    -  

    +   +

    - -

    Shorewall is free but -if you try it and find it useful, please consider making a donation - to Starlight Children's Foundation. Thanks!

    -
    - -

    Updated 11/24/2002 - Tom Eastep -
    -

    -
    -
    + +

    Updated 12/27/2002 - Tom Eastep + +
    +


    diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm index ddb722719..88ed7007e 100644 --- a/Shorewall-docs/shoreline.htm +++ b/Shorewall-docs/shoreline.htm @@ -1,118 +1,124 @@ - + About the Shorewall Author - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Tom Eastep

    -
    - +

    Tom on the PCT - 1991 -

    - +

    +

    Tarry & Tom -- August 2002
    -
    -

    - +
    +

    + - +

    I am currently a member of the design team for the next-generation operating system from the NonStop Enterprise Division of HP.

    - +

    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 Seattle Firewall. Expanding - on what I learned from Seattle Firewall, I then designed and wrote - Shorewall.

    - + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known as + Seattle Firewall. Expanding + on what I learned from Seattle Firewall, I then designed and wrote + Shorewall.

    +

    I telework from our home in Shoreline, - Washington where I live with my wife Tarry.

    - + Washington where I live with my wife Tarry.

    +

    Our current home network consists of:

    - +
      -
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 8GB IDE -HDs and LNE100TX (Tulip) NIC - My personal Windows system. Also has -RedHat 8.0 installed.
      • -
    • 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 VMware installed - and can run both Debian Woody -and SuSE 8.1 in virtual machines.
      • -
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  - Mail - (Postfix & Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), DNS server - (Bind).
      • -
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX  - (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.9a  and a DHCP - server.  Also runs PoPToP for road warrior access.
      • -
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My wife's - personal system.
      • -
    • PII/400 Laptop, Win2k SP2, 224MB RAM, 12GB HD, onboard EEPRO100 - and EEPRO100 in expansion base and LinkSys WAC11 - My main work system.
      • - +
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 20GB +IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Also +has Mandrake 9.0 installed.
      • +
    • 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 VMware + installed and can run both Debian + Woody and SuSE 8.1 in virtual + machines.
      • +
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  - +Email (Postfix & Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), DNS +server (Bind).
      • +
    • 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.
      • +
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My +wife's personal system.
      • +
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard +EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main +work system.
      • +
    - +

    For more about our network see my Shorewall Configuration.

    - +

    All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs.

    - +

    - - - -

    - -

    Last updated 10/28/2002 - + Powered by Mandrake + Protected by Shorewall +

    + +

    Last updated 12/7/2002 - Tom Eastep

    - Copyright - © 2001, 2002 Thomas M. Eastep.
    -
    -
    -
    -
    + Copyright © 2001, 2002 Thomas M. Eastep.
    +

    diff --git a/Shorewall-docs/shorewall_extension_scripts.htm b/Shorewall-docs/shorewall_extension_scripts.htm index c8689cdbe..650be5874 100644 --- a/Shorewall-docs/shorewall_extension_scripts.htm +++ b/Shorewall-docs/shorewall_extension_scripts.htm @@ -1,113 +1,133 @@ + - - - - - -Shorewall Extension Scripts + + + + + + + + + Shorewall Extension Scripts - - - - - - - -
    -

    Extension Scripts

    -
    - -

    - Extension scripts are user-provided - scripts that are invoked at various points during firewall start, restart, - stop and clear. The scripts are placed in /etc/shorewall and are processed - using the Bourne shell "source" mechanism. The following scripts can be - supplied:

    -
      -
    • init -- invoked early in "shorewall start" and "shorewall restart"
      • -
    • start -- invoked after the firewall has been started or restarted.
      • -
    • stop -- invoked as a first step when the firewall is being stopped.
      • -
    • stopped -- invoked after the firewall has been stopped.
      • -
    • clear -- invoked after the firewall has been cleared.
      • -
    • refresh -- invoked while the firewall is being refreshed but before the - common and/or blacklst chains have been rebuilt.
      • -
    • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' chain - has been created but before any rules have been added to it.
      • + + + + + + + + + + + + + + +
      + +

      Extension Scripts

      + +
      + + +

      Extension scripts are user-provided scripts that are invoked at various +points during firewall start, restart, stop and clear. The scripts are +placed in /etc/shorewall and are processed using the Bourne shell "source" +mechanism. The following scripts can be supplied:

      + +
        +
      • init -- invoked early in "shorewall start" and "shorewall restart"
        • +
      • start -- invoked after the firewall has been started or restarted.
        • +
      • stop -- invoked as a first step when the firewall is being stopped.
        • +
      • stopped -- invoked after the firewall has been stopped.
        • +
      • clear -- invoked after the firewall has been cleared.
        • +
      • refresh -- invoked while the firewall is being refreshed but before +the common and/or blacklst chains have been rebuilt.
        • +
      • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' +chain has been created but before any rules have been added to it.
        • +
      - -

      - You can also supply a script with the same name as any of the filter -chains in the firewall and the script will be invoked after the /etc/shorewall/rules - file has been processed but before the /etc/shorewall/policy file has -been processed.

      + + +

      If your version of Shorewall doesn't have the file that you want +to use from the above list, you can simply create the file yourself.

      +

      You can also supply a script with the same name as any of the filter + chains in the firewall and the script will be invoked after the /etc/shorewall/rules + file has been processed but before the /etc/shorewall/policy file has been + processed.

      - -

      The /etc/shorewall/common file receives special treatment. If this file is present, the rules that it - defines will totally replace the default rules in the common chain. These - default rules are contained in the file /etc/shorewall/common.def which - may be used as a starting point for making your own customized file.

      + + +

      The /etc/shorewall/common file receives special treatment. If this file +is present, the rules that it defines will totally replace the default +rules in the common chain. These default rules are contained in the +file /etc/shorewall/common.def which may be used as a starting point +for making your own customized file.

      - -

      - Rather than running iptables directly, you should run it using the function - run_iptables. Similarly, rather than running "ip" directly, you should -use run_ip. These functions accept the same arguments as the underlying -command but cause the firewall to be stopped if an error occurs during -processing of the command.

      + + +

      Rather than running iptables directly, you should run it using the + function run_iptables. Similarly, rather than running "ip" directly, + you should use run_ip. These functions accept the same arguments as the + underlying command but cause the firewall to be stopped if an error occurs + during processing of the command.

      + + +

      If you decide to create /etc/shorewall/common it is a good idea to +use the following technique

      + + + + +

      /etc/shorewall/common:

      + + + + +
      -

      - If you decide to create /etc/shorewall/common it is a good idea to use the - following technique

      + 
      . /etc/shorewall/common.def
      <add your rules here>
      +
      + +

      If you need to supercede a rule in the released common.def file, you can +add the superceding rule before the '.' command. Using this technique allows + you to add new rules while still getting the benefit of the latest common.def + file.

      - -

      - /etc/shorewall/common:

      + +

      Remember that /etc/shorewall/common defines rules that are only applied +if the applicable policy is DROP or REJECT. These rules are NOT applied +if the policy is ACCEPT or CONTINUE.

      - -
      - 
      . /etc/shorewall/common.def
-<add your rules here>
      -
      -

      If you need to supercede a rule in the released common.def file, you can add - the superceding rule before the '.' command. Using this technique allows - you to add new rules while still getting the benefit of the latest common.def - file.

      + +

      If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will +be rejected by the firewall. It is recommended with this setting that you +create the file /etc/shorewall/icmpdef and in it place the following commands:

      - -

      Remember that /etc/shorewall/common defines rules - that are only applied if the applicable policy is DROP or REJECT. These rules - are NOT applied if the policy is ACCEPT or CONTINUE.

      + +
      	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
      - -

      If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will be - rejected by the firewall. It is recommended with this setting that you create - the file /etc/shorewall/icmpdef and in it place the following commands:

      - - - - 
      	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
-
      -

      Last updated -8/22/2002 - Tom -Eastep

      - -

      Copyright 2002 Thomas M. Eastep

      - + +

      Last updated 12/22/2002 - Tom Eastep

      + +

      Copyright 2002 Thomas +M. Eastep

      +
      - - \ No newline at end of file + diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm index 88372508b..564fbaf64 100644 --- a/Shorewall-docs/shorewall_quickstart_guide.htm +++ b/Shorewall-docs/shorewall_quickstart_guide.htm @@ -1,227 +1,269 @@ - + - + - + - + Shorewall QuickStart Guide - + + - + - - - + + - - - + Version 3.1 + + + +
      - +
      +

      Shorewall QuickStart Guides
      - Version 3.1

      -
      - -

      With thanks to Richard who reminded me once again that we -must all first walk before we can run.

      - + +

      With thanks to Richard who reminded me once again that +we must all first walk before we can run.

      +

      The Guides

      - -

      These guides provide step-by-step instructions for configuring Shorewall - in common firewall setups.

      - + +

      These guides provide step-by-step instructions for configuring Shorewall + in common firewall setups.

      +

      The following guides are for users who have a single public IP address:

      - +
        -
      • Standalone Linux System
        • -
      • Two-interface Linux System -acting as a firewall/router for a small local network
        • -
      • Three-interface Linux System - acting as a firewall/router for a small local network and a DMZ.
        • - +
      • Standalone Linux System
        • +
      • Two-interface Linux System + acting as a firewall/router for a small local network
        • +
      • Three-interface Linux + System acting as a firewall/router for a small local network and +a DMZ.
        • +
      - -

      The above guides are designed to get your first firewall up and running - quickly in the three most common Shorewall configurations.

      - -

      The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple public - IP addresses involved or if you want to learn more about Shorewall than - is explained in the single-address guides above.

      - + +

      The above guides are designed to get your first firewall up and running + quickly in the three most common Shorewall configurations.

      + +

      The Shorewall Setup Guide outlines + the steps necessary to set up a firewall where there are multiple + public IP addresses involved or if you want to learn more about Shorewall + than is explained in the single-address guides above.

      +
        -
      • 1.0 Introduction
        • -
      • 2.0 Shorewall -Concepts
        • -
      • 3.0 Network -Interfaces
        • -
      • 4.0 Addressing, - Subnets and Routing +
      • 1.0 Introduction
        • +
      • 2.0 Shorewall + Concepts
        • +
      • 3.0 Network + Interfaces
        • +
      • 4.0 Addressing, + Subnets and Routing + - - -
        • -
      • 5.0 Setting up -your Network - - - - +

        Documentation Index

        - -

        The following documentation covers a variety of topics and supplements - the QuickStart Guides described - above. Please review the appropriate guide before trying to use this - documentation directly.

        - + +

        The following documentation covers a variety of topics and supplements + the QuickStart Guides +described above. Please review the appropriate guide before trying +to use this documentation directly.

        + - +

        If you use one of these guides and have a suggestion for improvement please let me know.

        - -

        Last modified 11/19/2002 - Tom Eastep

        - + +

        Last modified 12/13/2002 - Tom Eastep

        +

        Copyright 2002 Thomas M. Eastep
        -

        +

        +
        +
        +
        +
        +
        diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index c73ff0c9e..9a72e16e0 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -1,418 +1,206 @@ - + - + - + - + Shorewall Setup Guide - + - +

        Shorewall Setup Guide

        - +

        1.0 Introduction
        - 2.0 Shorewall Concepts
        - 3.0 Network Interfaces
        - 4.0 Addressing, Subnets and Routing

        - -
        + 2.0 Shorewall Concepts
        + 3.0 Network Interfaces
        + 4.0 Addressing, Subnets and Routing

        + +

        4.1 IP Addresses
        - 4.2 Subnets
        - 4.3 Routing
        - 4.4 Address Resolution Protocol
        - 4.5 RFC 1918

        -
        - -

        5.0 Setting up your Network

        - -
        -

        5.1 Routed
        - 5.2 Non-routed

        - -
        -

        5.2.1 SNAT
        - 5.2.2 DNAT
        - 5.2.3 Proxy ARP
        - 5.2.4 Static NAT

        + 4.2 Subnets
        + 4.3 Routing
        + 4.4 Address Resolution Protocol
        + 4.5 RFC 1918

        - + +

        5.0 Setting up your Network

        + +
        +

        5.1 Routed
        + 5.2 Non-routed

        + +
        +

        5.2.1 SNAT
        + 5.2.2 DNAT
        + 5.2.3 Proxy ARP
        + 5.2.4 Static NAT

        +
        +

        5.3 Rules
        - 5.4 Odds and Ends

        -
        - + 5.4 Odds and Ends

        +
        +

        6.0 DNS
        - 7.0 Starting and Stopping the Firewall

        - + 7.0 Starting and Stopping the Firewall

        +

        1.0 Introduction

        - +

        This guide is intended for users who are setting up Shorewall in an environment -where a set of public IP addresses must be managed or who want to know more -about Shorewall than is contained in the single-address guides. Because -the range of possible applications is so broad, the Guide will give you + the range of possible applications is so broad, the Guide will give you general guidelines and will point you to other resources as necessary.

        - +

        -    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.

        - +     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.

        +

        This guide assumes that you have the iproute/iproute2 package installed -(on RedHat, the package is called iproute). You can tell if -this package is installed by the presence of an ip program on your -firewall system. As root, you can use the 'which' command to check for this -program:

        - + (on RedHat, the package is called iproute). You can tell +if this package is installed by the presence of an ip program on +your firewall system. As root, you can use the 'which' command to check +for this program:

        + 
             [root@gateway root]# which ip
             /sbin/ip
             [root@gateway root]#
        +

        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 -.

        - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with + .

        +

        -    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.

        - +     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.

        + - +

        2.0 Shorewall Concepts

        - +

        The configuration files for Shorewall are contained in the directory /etc/shorewall -- for most setups, you will only need to deal with a few of these as described in this guide. Skeleton files are created during the Shorewall Installation Process.

        - +

        As each file is introduced, I suggest that you look through the actual -file on your system -- each file contains detailed configuration instructions -and some contain default entries.

        - + file on your system -- each file contains detailed configuration instructions + and some contain default entries.

        +

        Shorewall views the network where it is running as being composed of a -set of zones. In the default installation, the following zone names -are used:

        - + set of zones. In the default installation, the following zone names + are used:

        + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        NameDescription
        netThe Internet
        locYour Local Network
        dmzDemilitarized Zone
        NameDescription
        netThe Internet
        locYour Local Network
        dmzDemilitarized Zone
        - +

        Zones are defined in the /etc/shorewall/zones -file.

        - + file.

        +

        Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed in the -/etc/shorewall/shorewall.conf file. -In this guide, the default name (fw) will be used.

        - + the firewall itself is known as fw but that may be changed in the + /etc/shorewall/shorewall.conf file. + In this guide, the default name (fw) will be used.

        +

        With the exception of fw, 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".

        - + 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".

        +

        -    Edit the /etc/shorewall/zones file and make any changes necessary.

        - +     Edit the /etc/shorewall/zones file and make any changes necessary.

        +

        Rules about what traffic to allow and what traffic to deny are expressed -in terms of zones.

        - + in terms of zones.

        + - +

        Shorewall is built on top of the Netfilter -kernel facility. Netfilter implements a connection -tracking function that allows what is often referred to as stateful -inspection of packets. This stateful property allows firewall rules -to be defined in terms of connections rather than in terms of packets. -With Shorewall, you:

        - + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms of +packets. With Shorewall, you:

        +
          -
        1. Identify the source zone.
          2. -
        2. Identify the destination zone.
          3. -
        3. 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.
          4. -
        4. 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.
          5. - +
        5. Identify the source zone.
          6. +
        6. Identify the destination zone.
          7. +
        7. 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.
          8. +
        8. 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.
          9. +
        - +

        Just because connections of a particular type are allowed from zone A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed -from zone A to zone B. It rather means that you can have -a proxy running on the firewall that accepts a connection from zone A and -then establishes its own separate connection from the firewall to zone -B.

        - + from zone A to zone B        . It rather means that you can have + a proxy running on the firewall that accepts a connection from zone A +and then establishes its own separate connection from the firewall to +zone B.

        +

        For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file matches - the connection request then the first policy in /etc/shorewall/policy that - matches the request is applied. If that policy is REJECT or DROP  the request -is first checked against the rules in /etc/shorewall/common.def.

        - + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common.def.

        +

        The default /etc/shorewall/policy file has the following policies:

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT  
        netallDROPinfo 
        allallREJECTinfo 
        -
        - -

        The above policy will:

        - -
          -
        1. allow all connection requests from your local network to the internet
          2. -
        2. drop (ignore) all connection requests from the internet to your firewall - or local network and log a message at the info level (see "man -syslog").
          3. -
        3. reject all other connection requests and log a message at the info - 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.
          4. - -
        - -

        -    At this point, edit your /etc/shorewall/policy and make any changes that -you wish.

        - -

        3.0 Network Interfaces

        - -

        For the remainder of this guide, we'll refer to the following - diagram. While it may not look like your own network, it can be used to - illustrate the important aspects of Shorewall configuration.

        - -

        In this diagram:

        - -
          -
        • 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 that -if one of those servers is compromised, you still have the firewall between -the compromised system and your local systems.
          • -
        • The Local Zone consists of systems Local 1, Local 2 and Local 3.
          • -
        • All systems from the ISP outward comprise the Internet Zone.
          • - -
        - -

        -

        - -

        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 /etc/shorewall/interfaces - file.

        - -

        The firewall illustrated above has three network interfaces. - Where Internet connectivity is through a cable or DSL "Modem", the External - Interface will be the Ethernet adapter that is connected to that "Modem" - (e.g., eth0)  unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the External Interface -will be a ppp interface (e.g., ppp0). If you connect via a regular -modem, your External Interface will also be ppp0. If you connect -using ISDN, you external interface will be ippp0.

        - -

        -    If your external interface is ppp0 or ippp0 then you will -want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

        - -

        Your Local Interface 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 cross-over - cable).

        - -

        Your DMZ Interface 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 cross-over cable).

        - -

        -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 -all.

        - -

        For the remainder of this Guide, we will assume that:

        - -
          -
        • -

          The external interface is eth0.

          -
          • -
        • -

          The Local interface is eth1.

          -
          • -
        • -

          The DMZ interface is eth2.

          -
          • - -
        - -

        The Shorewall default configuration does not define the contents - of any zone. To define the above configuration using the /etc/shorewall/interfaces -file, that file would might contain:

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918
        loceth1detect 
        dmzeth2detect 
        -
        - -

        -    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.

        - -

        Example:

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918
        loceth1detect 
        loceth2detectdhcp
        -
        - -
        -

        When you have more than one interface to a zone, you will - usually want a policy that permits intra-zone traffic:

        -
        - -
        -
        + +
        - + @@ -421,80 +209,297 @@ one entry for each interface and repeat the zone name as many times as necessar - + - - + + + + + + + + + + + + + + + +
        Source Zone Destination Zone Policy
        loclocnet ACCEPT    
        netallDROPinfo 
        allallREJECTinfo 
        -
        - + +

        The above policy will:

        + +
          +
        1. allow all connection requests from your local network to the internet
          2. +
        2. drop (ignore) all connection requests from the internet to your +firewall or local network and log a message at the info level +(here is a description +of log levels).
          3. +
        3. reject all other connection requests and log a message at the info + 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.
          4. + +
        + +

        +     At this point, edit your /etc/shorewall/policy and make any changes +that you wish.

        + +

        3.0 Network Interfaces

        + +

        For the remainder of this guide, we'll refer to the following + diagram. While it may not look like your own network, it can be used to + illustrate the important aspects of Shorewall configuration.

        + +

        In this diagram:

        + +
          +
        • 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 +that if one of those servers is compromised, you still have the firewall +between the compromised system and your local systems.
          • +
        • The Local Zone consists of systems Local 1, Local 2 and Local 3. +
          • +
        • All systems from the ISP outward comprise the Internet Zone.
          • + +
        + +

        +

        + +

        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 /etc/shorewall/interfaces + file.

        + +

        The firewall illustrated above has three network interfaces. + Where Internet connectivity is through a cable or DSL "Modem", the External + Interface will be the Ethernet adapter that is connected to that "Modem" + (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External Interface + will be a ppp interface (e.g., ppp0). If you connect via a regular + modem, your External Interface will also be ppp0. If you connect +using ISDN, you external interface will be ippp0.

        + +

        +     If your external interface is ppp0 or ippp0 then you +will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

        + +

        Your Local Interface 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 cross-over + cable).

        + +

        Your DMZ Interface 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 cross-over cable).

        + +

        + 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 +all.

        + +

        For the remainder of this Guide, we will assume that:

        + +
          +
        • +

          The external interface is eth0.

          +
          • +
        • +

          The Local interface is eth1.

          +
          • +
        • +

          The DMZ interface is eth2.

          +
          • + +
        + +

        The Shorewall default configuration does not define the contents + of any zone. To define the above configuration using the /etc/shorewall/interfaces + file, that file would might contain:

        + +
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918
        loceth1detect 
        dmzeth2detect 
        +
        +

        -    You may define more complicated zones using the + +

        Example:

        + +
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918
        loceth1detect 
        loceth2detectdhcp
        +
        + +
        +

        When you have more than one interface to a zone, you will + usually want a policy that permits intra-zone traffic:

        +
        + +
        +
        + + + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        loclocACCEPT  
        +
        +
        + +

        +     You may define more complicated zones using the /etc/shorewall/hosts file but in most - cases, that isn't necessary.

        - + cases, that isn't necessary.

        +

        4.0 Addressing, Subnets and Routing

        - +

        Normally, your ISP will assign you a set of Public -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 + 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.

        - + though, some background is in order.

        +

        If you are thoroughly familiar with IP addressing and routing, - you may go to the next section.

        - + you may go to the next section.

        +

        The following discussion barely scratches the surface of addressing and routing. If you are interested in learning more about this subject, I highly recommend "IP Fundamentals: What Everyone Needs to Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        - +

        4.1 IP Addresses

        - +

        IP version 4 (IPv4) addresses are 32-bit numbers. -The notation w.x.y.z refers to an address where the high-order byte has value -"w", the next byte has value "x", etc. If we take the address 192.0.2.14 -and express it in hexadecimal, we get:

        - -
        + The notation w.x.y.z refers to an address where the high-order byte has +value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + and express it in hexadecimal, we get:

        + +

        C0.00.02.0E

        -
        - +
        +

        or looking at it as a 32-bit integer

        - -
        + +

        C000020E

        -
        - +
        +

        4.2 Subnets

        - +

        You will still hear the terms "Class A network", "Class B - network" and "Class C network". In the early days of IP, networks only + 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):

        - -
        + +

        Class A - netmask 255.0.0.0, size = 2 ** 24

        - +

        Class B - netmask 255.255.0.0, size = 2 ** 16

        - +

        Class C - netmask 255.255.255.0, size = 256

        -
        - +
        +

        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 netmask. The netmask is + of the high order byte of its address so you could look at an IP address + and immediately determine the associated netmask. The netmask is a number that when logically ANDed with an address isolates the network -number; the remainder of the address is the host number. For + number; the remainder of the address is the host number. For example, in the Class C address 192.0.2.14, the network number is hex C00002 and the host number is hex 0E.

        - +

        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 corporations and universities were assigned their own class A network!). @@ -502,1928 +507,1951 @@ After some false starts, the current technique of subnetting these networks into smaller subnetworks evolved; that technique is referred to as Classless InterDomain Routing (CIDR). Today, any system that you are likely to work with will understand CIDR and Class-based networking -is largely a thing of the past.

        - + is largely a thing of the past.

        +

        A subnetwork (often referred to as a subnet) is - a contiguous set of IP addresses such that:

        - + a contiguous set of IP addresses such that:

        +
          -
        1. +

        2. The number of addresses in the set is a power of 2; and

          -
          3. -
        3. +
          4. +

        4. The first address in the set is a multiple of the set -size.

          -
          5. -
        5. + size.

          +
          6. +

        6. The first address in the subnet is reserved and is referred -to as the subnet address.

          -
          7. -
        7. + to as the subnet address.

          +
          8. +

        8. The last address in the subnet is reserved as the subnet's -broadcast address.

          -
          9. - + broadcast address.

          + +
        - +

        As you can see by this definition, in each subnet of size -n there are (n - 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. -

        - + n there are (n - 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. +

        +

        Since n is a power of two, we can easily calculate -the Natural Logarithm (log2) of n. For the more common -subnet sizes, the size and its natural logarithm are given in the following -table:

        - -
        + the Natural Logarithm (log2) of n. For the more common + subnet sizes, the size and its natural logarithm are given in the following + table:

        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        nlog2 n(32 - log2 n)
        8329
        16428
        32527
        64626
        128725
        256824
        512923
        10241022
        20481121
        40961220
        81921319
        163841418
        327681517
        655361616
        nlog2 n(32 - log2 n)
        8329
        16428
        32527
        64626
        128725
        256824
        512923
        10241022
        20481121
        40961220
        81921319
        163841418
        327681517
        655361616
        -
        - +
        +

        You will notice that the above table also contains a column - for (32 - log2 n). That number is the Variable Length Subnet -Mask for a network of size n. From the above table, we can + for (32 - log2 n). That number is the Variable Length Subnet + Mask for a network of size n. From the above table, we can derive the following one which is a little easier to use.

        - -
        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Size of SubnetVLSMSubnet Mask
        8/29255.255.255.248
        16/28255.255.255.240
        32/27255.255.255.224
        64/26255.255.255.192
        128/25255.255.255.128
        256/24255.255.255.0
        512/23255.255.254.0
        1024/22255.255.252.0
        2048/21255.255.248.0
        4096/20255.255.240.0
        8192/19255.255.224.0
        16384/18255.255.192.0
        32768/17255.255.128.0
        65536/16255.255.0.0
        2 ** 24/8255.0.0.0
        Size of SubnetVLSMSubnet Mask
        8/29255.255.255.248
        16/28255.255.255.240
        32/27255.255.255.224
        64/26255.255.255.192
        128/25255.255.255.128
        256/24255.255.255.0
        512/23255.255.254.0
        1024/22255.255.252.0
        2048/21255.255.248.0
        4096/20255.255.240.0
        8192/19255.255.224.0
        16384/18255.255.192.0
        32768/17255.255.128.0
        65536/16255.255.0.0
        2 ** 24/8255.0.0.0
        -
        - +
        +

        Notice that the VLSM is written with a slash ("/") -- you -will often hear a subnet of size 64 referred to as a "slash 26" subnet -and one of size 8 referred to as a "slash 29".

        - + will often hear a subnet of size 64 referred to as a "slash 26" subnet + and one of size 8 referred to as a "slash 29".

        +

        The subnet's mask (also referred to as its netmask) is -simply a 32-bit number with the first "VLSM" bits set to one and the remaining -bits set to zero. For example, for a subnet of size 64, the subnet mask -has 26 leading one bits:

        - -
        + simply a 32-bit number with the first "VLSM" bits set to one and the +remaining bits set to zero. For example, for a subnet of size 64, the +subnet mask has 26 leading one bits:

        + +

        11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 -= 255.255.255.192

        -
        - + = 255.255.255.192

        +
        +

        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 + 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.

        - +

        For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork as + Variable Length Subnet Mask is /v, we denote the subnetwork as "a.b.c.d/v" using CIDR Notation. 

        - +

        Example:

        - -
        + +
        - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
        Subnet:10.10.10.0 - 10.10.10.127
        Subnet Size:128
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.127
        CIDR Notation:10.10.10.0/25
        Subnet:10.10.10.0 - 10.10.10.127
        Subnet Size:128
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.127
        CIDR Notation:10.10.10.0/25
        -
        - +
        +

        There are two degenerate subnets that need mentioning; namely, -the subnet with one member and the subnet with 2 ** 32 members.

        - -
        + the subnet with one member and the subnet with 2 ** 32 members.

        + +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
        132255.255.255.255a.b.c.d/32
        2 ** 3200.0.0.00.0.0.0/0
        Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
        132255.255.255.255a.b.c.d/32
        2 ** 3200.0.0.00.0.0.0/0
        -
        - -

        So any address a.b.c.d may also be written a.b.c.d/32 -and the set of all possible IP addresses is written 0.0.0.0/0.

        - -

        Later in this guide, you will see the notation a.b.c.d/v - used to describe the ip configuration of a network interface (the 'ip' utility - also uses this syntax). This simply means that the interface is configured -with ip address a.b.c.d and with the netmask that corresponds to -VLSM /v.

        - -

        Example: 192.0.2.65/29

        - -

            The interface is configured with IP address 192.0.2.65 -and netmask 255.255.255.248.

        - -

        4.3 Routing

        - -

        One of the purposes of subnetting is that it forms the basis - for routing. Here's the routing table on my firewall:

        - -
        -
        - 
        [root@gateway root]# netstat -nr
        Kernel IP routing table
        Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
        192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
        206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
        206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
        192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
        192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
        192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
        206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
        192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
        127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
        0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
        [root@gateway root]#
        -
        - + +

        So any address a.b.c.d may also be written a.b.c.d/32 + and the set of all possible IP addresses is written 0.0.0.0/0.

        + +

        Later in this guide, you will see the notation a.b.c.d/v + used to describe the ip configuration of a network interface (the 'ip' +utility also uses this syntax). This simply means that the interface is +configured with ip address a.b.c.d and with the netmask that corresponds +to VLSM /v.

        + +

        Example: 192.0.2.65/29

        + +

            The interface is configured with IP address 192.0.2.65 + and netmask 255.255.255.248.

        + +

        4.3 Routing

        + +

        One of the purposes of subnetting is that it forms the basis + for routing. Here's the routing table on my firewall:

        + +
        +
        + 
        [root@gateway root]# netstat -nr
        Kernel IP routing table
        Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
        192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
        206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
        206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
        192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
        192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
        192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
        206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
        192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
        127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
        0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
        [root@gateway root]#
        +
        +
        +

        The device texas is a GRE tunnel to a peer site in -the Dallas, Texas area.
        -
        - The first three routes are host routes 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 packets to a subnetwork. -The last route is the default route and the gateway mentioned in -that route is called the default gateway.

        - + the Dallas, Texas area.
        +
        + The first three routes are host routes 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 +packets to a subnetwork. The last route is the default route and +the gateway mentioned in that route is called the default gateway.

        +

        When the kernel is trying to send a packet to IP address A, it starts at the top of the routing table and:

        - +
          -
        • +

        • A is logically ANDed with the 'Genmask' value in the table entry.

          -
          • -
        • +
          • +

        • The result is compared with the 'Destination' value in -the table entry.

          -
          • -
        • + the table entry.

          +
          • +

        • If the result and the 'Destination' value are the same, -then:

          - + then:

          +
            -
          • +

          • If the 'Gateway' column is non-zero, the packet is -sent to the gateway over the interface named in the 'Iface' column.

            -
            • -
          • + sent to the gateway over the interface named in the 'Iface' column.

            +
            • +

          • Otherwise, the packet is sent directly to A over -the interface named in the 'iface' column.

            -
            • - + the interface named in the 'iface' column.

            + +
          -
          • -
        • +
          • +

        • Otherwise, the above steps are repeated on the next entry -in the table.

          -
          • - + in the table.

          + +
        - +

        Since the default route matches any IP address (A land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table entries are sent to the default gateway which is usually a router at your ISP.

        - +

        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:

        - -
        -
        + 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:

        + +
        +
        192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
        -
        - +
        +

        So to route a packet to 192.168.1.5, the packet is sent directly over eth2.

        -
        - + +

        One more thing needs to be emphasized -- all outgoing packet -are sent using the routing table and reply packets are not a special case. -There seems to be a common mis-conception whereby people think that request -packets are like salmon and contain a genetic code that is magically transferred -to reply packets so that the replies follow the reverse route taken by the -request. That isn't the case; the replies may take a totally different route -back to the client than was taken by the requests -- they are totally independent.

        - + are sent using the routing table and reply packets are not a special case. + There seems to be a common mis-conception whereby people think that request + packets are like salmon and contain a genetic code that is magically transferred + to reply packets so that the replies follow the reverse route taken by +the request. That isn't the case; the replies may take a totally different +route back to the client than was taken by the requests -- they are totally +independent.

        +

        4.4 Address Resolution Protocol

        - +

        When sending packets over Ethernet, IP addresses aren't used. - Rather Ethernet addressing is based on Media Access Control (MAC) - addresses. Each Ethernet device has it's own unique  MAC address which is - burned into a PROM on the device during manufacture. You can obtain the -MAC of an Ethernet device using the 'ip' utility:

        - -
        -
        + Rather Ethernet addressing is based on Media Access Control (MAC) + addresses. Each Ethernet device has it's own unique  MAC address which +is burned into a PROM on the device during manufacture. You can obtain +the MAC of an Ethernet device using the 'ip' utility:

        + +
        + 
        [root@gateway root]# ip addr show eth0
        2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
        link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
        inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
        inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
        inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
        [root@gateway root]#
        -
        -
        - -
        +
        +
        + +

        As you can see from the above output, the MAC is 6 bytes (48 bits) wide. A card's MAC is usually also printed on a label attached to the card itself.

        -
        - -
        +
        + +

        Because IP uses IP addresses and Ethernet uses MAC addresses, - a mechanism is required to translate an IP address into a MAC address; -that is the purpose of the Address Resolution Protocol (ARP). Here -is ARP in action:

        -
        - -
        -
        -
        + a mechanism is required to translate an IP address into a MAC address; + that is the purpose of the Address Resolution Protocol (ARP). +Here is ARP in action:

        +
        + +
        +
        + 
        [root@gateway root]# tcpdump -nei eth2 arp
        tcpdump: listening on eth2
        09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
        09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

        2 packets received by filter
        0 packets dropped by kernel
        [root@gateway root]#
        +
        +
        +
        + +

        In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants + to know the MAC of the device with IP address 192.168.1.19. The system +having that IP address is responding that the MAC address of the device +with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

        + +

        In order to avoid having to exchange ARP information each + time that an IP packet is to be sent, systems maintain an ARP cache + of IP<->MAC correspondences. You can see the ARP cache on your system + (including your Windows system) using the 'arp' command:

        + +
        +
        + 
        [root@gateway root]# arp -na
        ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
        ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
        ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
        ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
        ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
        -
        - -

        In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants -to know the MAC of the device with IP address 192.168.1.19. The system having -that IP address is responding that the MAC address of the device with IP -address 192.168.1.19 is 0:6:25:aa:8a:f0.

        - -

        In order to avoid having to exchange ARP information each -time that an IP packet is to be sent, systems maintain an ARP cache -of IP<->MAC correspondences. You can see the ARP cache on your system -(including your Windows system) using the 'arp' command:

        - -
        -
        - 
        [root@gateway root]# arp -na
        ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
        ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
        ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
        ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
        ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
        -
        -
        - +

        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->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 + the 'n' option (Windows 'arp' doesn't allow that option) which causes the + 'arp' program to forego IP->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.

        - +

        4.5 RFC 1918

        - +

        IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet + who delegates allocations on a geographic basis to Regional Internet Registries (RIRs). For example, allocation for the Americas and for sub-Sahara Africa is delegated to the American - Registry for Internet Numbers (ARIN). These RIRs may in turn delegate -to national registries. Most of us don't deal with these registrars but + Registry for Internet Numbers (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.

        - +

        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 use of Private IP addresses. RFC 1918 reserves several IP address ranges for this purpose:

        - -
        + +
             10.0.0.0    - 10.255.255.255
             172.16.0.0  - 172.31.255.255
             192.168.0.0 - 192.168.255.255
        -
        - -
        +
        + +

        The addresses reserved by RFC 1918 are sometimes referred -to as non-routable because the Internet backbone routers don't + to as non-routable because the Internet backbone routers don't forward packets which have an RFC-1918 destination address. This is understandable - given that anyone can select any of these addresses for their private + given that anyone can select any of these addresses for their private use.

        -
        - -
        +
        + +

        When selecting addresses from these ranges, there's a couple - of things to keep in mind:

        -
        - -
        + of things to keep in mind:

        +
        + +
          -
        • +

        • As the IPv4 address space becomes depleted, more and more organizations (including ISPs) are beginning to use RFC 1918 addresses -in their infrastructure.

          -
          • -
        • + in their infrastructure.

          +
          • +

        • You don't want to use addresses that are being used by - your ISP or by another organization with whom you want to establish + your ISP or by another organization with whom you want to establish a VPN relationship.

          -
          • + +
        -
        - -
        +
        + +

        So it's a good idea to check with your ISP to see if they -are using (or are planning to use) private addresses before you decide -the addresses that you are going to use.

        -
        - -
        + are using (or are planning to use) private addresses before you decide + the addresses that you are going to use.

        +
        + +

        5.0 Setting up your Network

        -
        - -
        +
        + +

        The choice of how to set up your network depends primarily -on how many Public IP addresses you have vs. how many addressable entities -you have in your network. Regardless of how many addresses you have, your -ISP will handle that set of addresses in one of two ways:

        -
        - -
        + on how many Public IP addresses you have vs. how many addressable entities + you have in your network. Regardless of how many addresses you have, +your ISP will handle that set of addresses in one of two ways:

        +
        + +
          -
        1. +

        2. Routed - Traffic to any of your addresses will -be routed through a single gateway address. 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.

          -
          3. -
        3. + be routed through a single gateway address. 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.

          +
          4. +

        4. Non-routed - Your ISP will send traffic to each -of your addresses directly.

          -
          5. + of your addresses directly.

          + +
        -
        - -
        +
        + +

        In the subsections that follow, we'll look at each of these - separately.

        -
        - -
        + separately.
        +

        +

        Before we begin, there is one thing for you to check:

        +

        +     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:
        +

        +
          +
        • NAT_ENABLED=Yes
          • +
        • IP_FORWARDING=On
          +
          • +
        +
        + +

        5.1 Routed

        -
        - -
        +
        + +

        Let's assume that your ISP has assigned you the subnet 192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses - 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address is - 192.0.2.65. Your ISP has also told you that you should use a netmask of - 255.255.255.0 (so your /28 is part of a larger /24). With this many IP - addresses, you are able to subnet your /28 into two /29's and set up your - network as shown in the following diagram.

        -
        - -
        + 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address +is 192.0.2.65. Your ISP has also told you that you should use a netmask +of 255.255.255.0 (so your /28 is part of a larger /24). With this many +IP addresses, you are able to subnet your /28 into two /29's and set +up your network as shown in the following diagram.

        +
        + +

        -

        -
        - -
        +

        +
        + +

        Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ would be configured to 192.0.2.66 and the default gateway for hosts in the local network would be 192.0.2.73.

        -
        - -
        +
        + +

        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.

        -
        - -
        + 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.

        +
        + +

        The astute reader may have noticed that the Firewall/Router's - external interface is actually part of the DMZ subnet (192.0.2.64/29). -What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The routing -table on DMZ 1 will look like this:

        -
        - -
        -
        + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The +routing table on DMZ 1 will look like this:

        +
        + +
        +
        Kernel IP routing table
        Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
        192.0.2.64 	0.0.0.0 	255.255.255.248 U     40  0         0 eth0
        0.0.0.0 	192.0.2.66	0.0.0.0 	UG    40  0         0 eth0
        -
        -
        - -
        +
        + + +

        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 DMZ Interface!! DMZ 1 can then send Ethernet frames addressed -to that MAC address and the frames will be received (correctly) by the -firewall/router.

        -
        - -
        + 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 DMZ Interface!! DMZ 1 can then send Ethernet frames addressed + to that MAC address and the frames will be received (correctly) by the + firewall/router.

        +
        + +

        It is this rather unexpected ARP behavior on the part of 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.

        -
        - -
        + interfaces that connect to the hub/switch can respond! It is then a race + as to which "here-is" response reaches the sender first.

        +
        + +

        5.2 Non-routed

        -
        - -
        +
        + +

        If you have the above situation but it is non-routed, you can configure your network exactly as described above with one additional -twist; simply specify the "proxyarp" option on all three firewall interfaces -in the /etc/shorewall/interfaces file.

        -
        - -
        + twist; simply specify the "proxyarp" option on all three firewall interfaces + in the /etc/shorewall/interfaces file.

        +
        + +

        Most of us don't have the luxury of having enough public IP addresses to set up our networks as shown in the preceding example (even if the setup is routed).

        -
        - -
        +
        + +

        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 + 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.

        -
        - -
        +
        + +

        Clearly, that set of addresses doesn't comprise a subnetwork - and there aren't enough addresses for all of the network interfaces. There -are four different techniques that can be used to work around this problem.

        -
        - -
        + and there aren't enough addresses for all of the network interfaces. +There are four different techniques that can be used to work around this +problem.

        +
        + +
          -
        • +

        • Source Network Address Translation (SNAT). -

          -
          • -
        • +

          +
          • +

        • Destination Network Address Translation (DNAT) -also known as Port Forwarding.

          -
          • -
        • + also known as Port Forwarding.

          +
          • +

        • Proxy ARP.

          -
          • -
        • +
          • +

        • Network Address Translation (NAT) also referred -to as Static NAT.

          -
          • + to as Static NAT.

          + +
        -
        - -
        +
        + +

        Often a combination of these techniques is used. Each of these will be discussed in the sections that follow.

        -
        - -
        +
        + +

         5.2.1 SNAT

        -
        - -
        +
        + +

        With SNAT, an internal LAN segment is configured using RFC -1918 addresses. When a host A on this internal segment initiates -a connection to host 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 responds and the response is received -by the firewall, the firewall changes the destination address back to + 1918 addresses. When a host A on this internal segment initiates + a connection to host 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 responds and the response is received + by the firewall, the firewall changes the destination address back to the RFC 1918 address of A and forwards the response back to A.

        -
        - -
        +
        + +

        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 + 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.

        -
        - -
        +
        + +

        -

        -
        - + + +
        The local zone has been subnetted as 192.168.201.0/29 -(netmask 255.255.255.248).
        - + (netmask 255.255.255.248). +
         
        - +
        -    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).
        - +     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). +
         
        - +
        -    SNAT is configured in Shorewall using the /etc/shorewall/masq file.
        - -
        -
        + +
        +
        - - - - - - - - - - - - - + + + + + + + + + + + + +
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        -
        -
        - -
        +
        +
        + +

        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 + 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.

        -
        - -
        +
        + +

        5.2.2 DNAT

        -
        - -
        +
        + +

        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.

        -
        - -
        + 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.

        +
        + +

        -     Suppose that your daughter wants to run a web server on her system -"Local 3". You could allow connections to the internet to her server by -adding the following entry in /etc/shorewall/rules:

        -
        - -
        -
        +      Suppose that your daughter wants to run a web server on her system + "Local 3". You could allow connections to the internet to her server +by adding the following entry in /etc/shorewall/rules:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
        DNATnetloc:192.168.201.4tcpwww-192.0.2.176
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
        DNATnetloc:192.168.201.4tcpwww-192.0.2.176
        -
        -
        - -
        +
        + + +

        If one of your daughter's friends at address A wants -to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external -IP address) and the firewall will rewrite the destination IP address to -192.168.201.4 (your daughter's system) and forward the request. When your -daughter's server responds, the firewall will rewrite the source address -back to 192.0.2.176 and send the response back to A.

        -
        - -
        + IP address) and the firewall will rewrite the destination IP address +to 192.168.201.4 (your daughter's system) and forward the request. When +your daughter's server responds, the firewall will rewrite the source +address back to 192.0.2.176 and send the response back to A.

        +
        + +

        This example used the firewall's external IP address for DNAT. You can use another of your public IP addresses but Shorewall will not add that address to the firewall's external interface for you.

        -
        - -
        +
        + +

        5.2.3 Proxy ARP

        -
        - -
        +
        + +

        The idea behind proxy ARP is that:

        -
        - -
        +
        + +
          -
        • +

        • A host H behind your firewall is assigned one of your public IP addresses (A) and is assigned the same netmask (M) as the firewall's external interface.

          -
          • -
        • +
          • +

        • The firewall responds to ARP "who has" requests for A. -

          -
          • -
        • +

          +
          • +

        • When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will respond (with the MAC if the firewall interface to H).

          -
          • + +
        -
        - -
        +
        + +

        Let suppose that we decide to use Proxy ARP on the DMZ in -our example network.

        -
        - -
        + our example network.

        +
        + +

        -

        -
        - +

        + +
        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 + 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.
        - +
         
        - +
        -    The Shorewall configuration of Proxy ARP is done using the /etc/shorewall/proxyarp file.
        - -
        -
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ADDRESSINTERFACEEXTERNALHAVE ROUTE
        192.0.2.177eth2eth0No
        192.0.2.178eth2eth0No
        ADDRESSINTERFACEEXTERNALHAVE ROUTE
        192.0.2.177eth2eth0No
        192.0.2.178eth2eth0No
        -
        -
        - -
        +
        +
        + +

        Because the HAVE ROUTE column contains No, Shorewall will -add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

        -
        - -
        + add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

        +
        + +

        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 + 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:

        -
        - -
        + 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:

        +
        + +
        	tcpdump -nei eth0 icmp
        -
        - -
        +
        + +

        Now from 192.0.2.177, ping the default gateway (which we are assuming is 192.0.2.254):

        -
        - -
        +
        + +
        	ping 192.0.2.254
        -
        - -
        +
        + +

        We can now observe the tcpdump output:

        -
        - -
        +
        + +
        	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
        	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
        -
        - -
        +
        + +

        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 DMZ 1. In other words, the gateway's ARP cache + 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.

        -
        - -
        +
        + +

        5.2.4 Static NAT

        -
        - -
        +
        + +

        With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public -IP addresses. For outgoing connections SNAT occurs and on incoming connections - DNAT occurs. Let's go back to our earlier example involving your daughter's -web server running on system Local 3.

        -
        - -
        + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT occurs and on incoming connections + DNAT occurs. Let's go back to our earlier example involving your daughter's + web server running on system Local 3.

        +
        + +

        -

        -
        - -
        +

        +
        + +

        Recall that in this setup, the local network is using SNAT -and is sharing the firewall external IP (192.0.2.176) for outbound connections. - This is done with the following entry in /etc/shorewall/masq:

        -
        - -
        -
        + and is sharing the firewall external IP (192.0.2.176) for outbound connections. + This is done with the following entry in /etc/shorewall/masq:

        +
        + +
        +
        - - - - - - - - - - - - - + + + + + + + + + + + + +
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        -
        -
        - -
        + +
        + +

        -    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 /etc/shorewall/nat.

        -
        - -
        -
        +     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 /etc/shorewall/nat.

        +
        + +
        +
        - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
        EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
        192.0.2.179eth0192.168.201.4NoNo
        EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
        192.0.2.179eth0192.168.201.4NoNo
        -
        -
        - -
        + +
        + +

        With this entry in place, you daughter has her own IP address - and the other two local systems share the firewall's IP address.

        -
        - -
        + and the other two local systems share the firewall's IP address.

        +
        + +

        -    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:

        -
        - -
        -
        +     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:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
        ACCEPTnetloc:192.168.201.4tcpwww  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
        ACCEPTnetloc:192.168.201.4tcpwww  
        -
        -
        - -
        + +
        + +

        5.3 Rules

        -
        - -
        +
        + +

        -    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 DNAT rules which -cause address translation and allow the translated connection request +     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 DNAT rules 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.

        -
        - -
        + your firewall is to use ACCEPT rules.

        +
        + +

        NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't - used in this section, they won't be shown

        -
        - -
        + used in this section, they won't be shown

        +
        + +

        You probably want to allow ping between your zones:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORT
        ACCEPTnetdmzicmpecho-request
        ACCEPTnetlocicmpecho-request
        ACCEPTdmzlocicmpecho-request
        ACCEPTlocdmzicmpecho-request
        ACTIONSOURCEDESTINATIONPROTOCOLPORT
        ACCEPTnetdmzicmpecho-request
        ACCEPTnetlocicmpecho-request
        ACCEPTdmzlocicmpecho-request
        ACCEPTlocdmzicmpecho-request
        -
        -
        - -
        + +
        + +

        Let's suppose that you run mail and pop3 servers on DMZ 2 -and a Web Server on DMZ 1. The rules that you would need are:

        -
        - -
        -
        + and a Web Server on DMZ 1. The rules that you would need are:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
        ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
        ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
        ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
        ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
        ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
        ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
        ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
        ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
        ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
        ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
        ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
        ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
        ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
        ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
        ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
        ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
        -
        -
        - -
        + +
        + +

        If you run a public DNS server on 192.0.2.177, you would need to add the following rules:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
        ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
        ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
        ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
        ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
        ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
        ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
        ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
        ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
        ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
        ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
        ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
        ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
        ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
        ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
        -
        -
        - -
        + +
        + +

        You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through -its scp utility can also do publishing and software update distribution.

        -
        - -
        -
        + and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTlocdmztcpssh# SSH to the DMZ
        ACCEPTlocfwtcpssh# SSH to the Firewall
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTlocdmztcpssh# SSH to the DMZ
        ACCEPTlocfwtcpssh# SSH to the Firewall
        -
        -
        - -
        + +
        + +

        5.4 Odds and Ends

        -
        - -
        +
        + +

        The above discussion reflects my personal preference for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer to use NAT only in cases where a system that is part of an RFC 1918 subnet needs to have it's own public IP. 

        -
        - -
        +
        + +

        -    If you haven't already, it would be a good idea to browse through - /etc/shorewall/shorewall.conf 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.

        -
        - -
        +     If you haven't already, it would be a good idea to browse through + /etc/shorewall/shorewall.conf 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.

        +
        + +

        In case you haven't been keeping score, here's the final set of configuration files for our sample network. Only those that were modified from the original installation are shown.

        -
        - -
        +
        + +

        /etc/shorewall/interfaces (The "options" will be very site-specific).

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918,routefilter
        loceth1detect 
        dmzeth2detect 
        ZoneInterfaceBroadcastOptions
        neteth0detectnorfc1918,routefilter
        loceth1detect 
        dmzeth2detect 
        -
        -
        - -
        + +
        + +

        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.

        -
        - -
        -
        + 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.

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ZoneInterfaceBroadcastOptions
        neteth0192.0.2.255norfc1918,routefilter
        loceth1192.168.201.7 
        dmzeth2192.168.202.7 
        ZoneInterfaceBroadcastOptions
        neteth0192.0.2.255norfc1918,routefilter
        loceth1192.168.201.7 
        dmzeth2192.168.202.7 
        -
        -
        - -
        + +
        + +

        /etc/shorewall/masq - Local subnet

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - + + + + + + + + + + + + +
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        INTERFACESUBNETADDRESS
        eth0192.168.201.0/29192.0.2.176
        -
        -
        - -
        + +
        + +

        /etc/shorewall/proxyarp - DMZ

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ADDRESSINTERFACEEXTERNALHAVE ROUTE
        192.0.2.177eth2eth0No
        192.0.2.178eth2eth0No
        ADDRESSINTERFACEEXTERNALHAVE ROUTE
        192.0.2.177eth2eth0No
        192.0.2.178eth2eth0No
        -
        -
        - -
        + +
        + +

        /etc/shorewall/nat- Daughter's System

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
        EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
        192.0.2.179eth0192.168.201.4NoNo
        EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
        192.0.2.179eth0192.168.201.4NoNo
        -
        -
        - -
        + +
        + +

        /etc/shorewall/rules

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
        ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
        ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
        ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
        ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
        ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
        ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
        ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
        ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
        ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
        ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
        ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
        ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
        ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
        ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
        ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
        ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
        ACCEPTnetdmzicmpecho-request# Ping
        ACCEPTnetlocicmpecho-request#  "
        ACCEPTdmzlocicmpecho-request# "
        ACCEPTlocdmzicmpecho-request# "
        ACCEPTlocdmztcpssh# SSH to the DMZ
        ACCEPTlocfwtcpssh# SSH to the Firewall
        ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
        ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
        ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
        ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
        ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
        ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
        ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
        ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
        ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
        ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
        ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
        ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
        ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
        ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
        ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
        ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
        ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
        ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
        ACCEPTnetdmzicmpecho-request# Ping
        ACCEPTnetlocicmpecho-request#  "
        ACCEPTdmzlocicmpecho-request# "
        ACCEPTlocdmzicmpecho-request# "
        ACCEPTlocdmztcpssh# SSH to the DMZ
        ACCEPTlocfwtcpssh# SSH to the Firewall
        -
        -
        - -
        + +
        + +

        6.0 DNS

        -
        - -
        +
        + +

        Given the collection of RFC 1918 and public addresses in this setup, it only makes sense to have separate internal and external DNS servers. You can combine the two into a single BIND 9 server using Views. If you are not interested in Bind 9 views, you can go to the next section.

        -
        - -
        -

        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 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.

        -
        - -
        -

        The /etc/named.conf file would look like this:

        -
        - -
        -
        -
        - 
        options {
        	directory "/var/named";
        	listen-on { 127.0.0.1 ; 192.0.2.177; };
        };

        logging {
        	channel xfer-log {
        		file "/var/log/named/bind-xfer.log";
        		print-category yes;
        		print-severity yes;
        		print-time yes;
        		severity info;
        	};
        	category xfer-in { xfer-log; };
        	category xfer-out { xfer-log; };
        	category notify { xfer-log; };
        };
        -
        +
        -
        +
        +

        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 +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.

        +
        + +
        +

        The /etc/named.conf file would look like this:

        +
        + +
        +
        +
        + 
        options {
        	directory "/var/named";
        	listen-on { 127.0.0.1 ; 192.0.2.177; };
        };

        logging {
        	channel xfer-log {
        		file "/var/log/named/bind-xfer.log";
        		print-category yes;
        		print-severity yes;
        		print-time yes;
        		severity info;
        	};
        	category xfer-in { xfer-log; };
        	category xfer-out { xfer-log; };
        	category notify { xfer-log; };
        };
        +
        + + 
        #
        # This is the view presented to our internal systems
        #

        view "internal" {
        	#
        	# These are the clients that see this view
        	#
        	match-clients { 192.168.201.0/29;
        			192.168.202.0/29;
        			127.0.0/24;
        			192.0.2.176/32; 
        			192.0.2.178/32;
        			192.0.2.179/32;
        			192.0.2.180/32; };
        	#
        	# If this server can't complete the request, it should use outside
        	# servers to do so
        	#
        	recursion yes;

        	zone "." in {
        		type hint;
        		file "int/root.cache";
        	};

        	zone "foobar.net" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "int/db.foobar";
        	};

        	zone "0.0.127.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "int/db.127.0.0";	
        	};

        	zone "201.168.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "int/db.192.168.201";
        	};

        	zone "202.168.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "int/db.192.168.202";
        	};

        	zone "176.2.0.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "db.192.0.2.176";
        	};

        	zone "177.2.0.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "db.192.0.2.177";
        	};

        	zone "178.2.0.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "db.192.0.2.178";
        	};

        	zone "179.2.0.192.in-addr.arpa" in {
        		type master;
        		notify no;
        		allow-update { none; };
        		file "db.206.124.146.179";
        	};

        };
        #
        # This is the view that we present to the outside world
        #
        view "external" {
        	match-clients { any; };
        	#
        	# If we can't answer the query, we tell the client so
        	#
        	recursion no;

        	zone "foobar.net" in {
        		type master;
        		notify yes;
        		allow-update {none; };
        		allow-transfer { <secondary NS IP>; };
        		file "ext/db.foobar";
        	};

        	zone "176.2.0.192.in-addr.arpa" in {
         		type master;
        		notify yes;
        		allow-update { none; };
        		allow-transfer { <secondary NS IP>; };
        		file "db.192.0.2.176";
        	};

        	zone "177.2.0.192.in-addr.arpa" in {
        		type master;
        		notify yes;
        		allow-update { none; };
        		allow-transfer { <secondary NS IP>; };
        		file "db.192.0.2.177";
        	};

        	zone "178.2.0.192.in-addr.arpa" in {
        		type master;
        		notify yes;
        		allow-update { none; };
        		allow-transfer { <secondary NS IP>; };
        		file "db.192.0.2.178";
        	};

        	zone "179.2.0.192.in-addr.arpa" in {
        		type master;
        		notify yes;
        		allow-update { none; };
        		allow-transfer { <secondary NS IP>; };
        		file "db.192.0.2.179";
        	};
        };
        -
        -
        -
        - -
        +
        + +
        + +

        Here are the files in /var/named (those not shown are usually - included in your bind disbribution).

        + included in your bind disbribution).

        +

        db.192.0.2.176 - This is the reverse zone for the firewall's -external interface

        -
        + external interface

        + +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
        ; Filename: db.192.0.2.176
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2001102303 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ) ; minimum (1 day)
        ;
        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800	IN NS	ns1.foobar.net.
        @	604800	IN NS	<name of secondary ns>.
        ;
        ; ############################################################
        ; Iverse Address Arpa Records (PTR's) 
        ; ############################################################
        176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
        -
        -
        - -
        + +
        + +
        db.192.0.2.177 - This is the reverse zone for the www/DNS -server -
        + server +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
        ; Filename: db.192.0.2.177
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2001102303 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ) ; minimum (1 day)
        ;
        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800	IN NS	ns1.foobar.net.
        @	604800	IN NS	<name of secondary ns>.
        ;
        ; ############################################################
        ; Iverse Address Arpa Records (PTR's) 
        ; ############################################################
        177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
        -
        -
        -
        - -
        + +
        + + +
        db.192.0.2.178 - This is the reverse zone for the mail -server -
        + server +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
        ; Filename: db.192.0.2.178
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2001102303 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ) ; minimum (1 day)
        ;
        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800	IN NS	ns1.foobar.net.
        @	604800	IN NS	<name of secondary ns>.
        ;
        ; ############################################################
        ; Iverse Address Arpa Records (PTR's) 
        ; ############################################################
        178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
        -
        -
        -
        - -
        + +
        + + +
        db.192.0.2.179 - This is the reverse zone for daughter's -web server's public IP -
        + web server's public IP +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
        ; Filename: db.192.0.2.179
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2001102303 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ) ; minimum (1 day)
        ;
        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800	IN NS	ns1.foobar.net.
        @	604800	IN NS	<name of secondary ns>.
        ;
        ; ############################################################
        ; Iverse Address Arpa Records (PTR's) 
        ; ############################################################
        179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
        -
        -
        -
        - -
        + +
        + + +

        int/db.127.0.0 - The reverse zone for localhost

        -
        - -
        -
        +
        + +
        +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
        ; Filename: db.127.0.0
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        				2001092901 ; serial
        				10800 ; refresh (3 hour)
        				3600 ; retry (1 hour)
        				604800 ; expire (7 days)
        				86400 ) ; minimum (1 day)
        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800		IN NS	ns1.foobar.net.

        ; ############################################################
        ; Iverse Address Arpa Records (PTR's)
        ; ############################################################
        1	86400		IN PTR	localhost.foobar.net.
        -
        -
        - -
        + +
        + +

        int/db.192.168.201 - Reverse zone for the local net. This -is only shown to internal clients

        -
        - -
        -
        + is only shown to internal clients

        +
        + +
        +
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
        ; Filename: db.192.168.201
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
        				2002032501 ; serial
        				10800 ; refresh (3 hour)
        				3600 ; retry (1 hour)
        				604800 ; expire (7 days)
        				86400 ) ; minimum (1 day)

        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @	604800		IN NS	ns1.foobar.net.

        ; ############################################################
        ; Iverse Address Arpa Records (PTR's)
        ; ############################################################
        1	86400		IN PTR 	gateway.foobar.net.
        2	86400		IN PTR	winken.foobar.net.
        3	86400		IN PTR	blinken.foobar.net.
        4	86400		IN PTR	nod.foobar.net.
        -
        -
        - -
        + +
        + +

        int/db.192.168.202 - Reverse zone for the firewall's DMZ interface

        -
        - -
        -
        -
        +
        + +
        +
        + 
        ; ############################################################
        ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
        ; Filename: db.192.168.202
        ; ############################################################
        @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
        				2002032501 ; serial
        				10800 ; refresh (3 hour)
        				3600 ; retry (1 hour)
        				604800 ; expire (7 days)
        				86400 ) ; minimum (1 day)

        ; ############################################################
        ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
        ; ############################################################
        @		604800	IN NS	ns1.foobar.net.

        ; ############################################################
        ; Iverse Address Arpa Records (PTR's)
        ; ############################################################
        1 		86400 IN PTR	dmz.foobar.net.
        -
        -
        -
        - -
        +
        +
        +
        + +

        int/db.foobar - Forward zone for use by internal clients.

        -
        - -
        -
        +
        + +
        +
        ;##############################################################
        ; Start of Authority for foobar.net.
        ; Filename: db.foobar
        ;##############################################################
        @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2002071501 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ); minimum (1 day)
        ;############################################################
        ; foobar.net Nameserver Records (NS)
        ;############################################################
        @ 		604800	IN NS	ns1.foobar.net.

        ;############################################################
        ; Foobar.net Office Records (ADDRESS)
        ;############################################################
        localhost	86400 	IN A 	127.0.0.1

        firewall	86400	IN A	192.0.2.176
        www		86400	IN A	192.0.2.177
        ns1 		86400	IN A 	192.0.2.177
        www		86400	IN A	192.0.2.177

        gateway		86400	IN A 	192.168.201.1
        winken		86400	IN A 	192.168.201.2
        blinken		86400	IN A	192.168.201.3
        nod		86400	IN A	192.168.201.4
        -
        -
        - -
        + +
        + +

        ext/db.foobar - Forward zone for external clients

        -
        - -
        -
        -
        +
        + +
        +
        + 
        ;##############################################################
        ; Start of Authority for foobar.net.
        ; Filename: db.foobar
        ;##############################################################
        @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
        			2002052901 ; serial
        			10800 ; refresh (3 hour)
        			3600 ; retry (1 hour)
        			604800 ; expire (7 days)
        			86400 ); minimum (1 day)
        ;############################################################
        ; Foobar.net Nameserver Records (NS)
        ;############################################################
        @		86400	IN NS	ns1.foobar.net.
        @		86400	IN NS	<secondary NS>.
        ;############################################################
        ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
        ;############################################################
        localhost	86400	IN A	127.0.0.1
        ;
        ; The firewall itself
        ;
        firewall	86400	IN A	192.0.2.176
        ;
        ; The DMZ
        ;
        ns1		86400	IN A	192.0.2.177
        www		86400	IN A	192.0.2.177
        mail		86400	IN A	192.0.2.178
        ;
        ; The Local Network
        ;
        nod		86400	IN A	192.0.2.179

        ;############################################################
        ; Current Aliases for foobar.net (CNAME)
        ;############################################################

        ;############################################################
        ; foobar.net MX Records (MAIL EXCHANGER)
        ;############################################################
        foobar.net.	86400	IN A	192.0.2.177
        		86400 	IN MX 0 mail.foobar.net.
        		86400	IN MX 1 <backup MX>.
        -
        -
        -
        - -
        +
        +
        +
        + +

        7.0 Starting and Stopping -Your Firewall

        -
        - -
        + Your Firewall +
        + +

        The installation procedure configures -your system to start Shorewall at system boot.

        -
        - -
        + your system to start Shorewall at system boot.

        +
        + +

        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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. -If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

        -
        - -
        + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

        +
        + +

        -    Edit the /etc/shorewall/routestopped file and configure those systems -that you want to be able to access the firewall when it is stopped.

        -
        - -
        +     Edit the /etc/shorewall/routestopped file and configure those systems + that you want to be able to access the firewall when it is stopped.

        +
        + +

        WARNING: If you are connected to your firewall from -the internet, do not issue a "shorewall stop" command unless you have + 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 /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create -an alternate configuration -and test it using the "shorewall + an alternate configuration + and test it using the "shorewall try" command.

        -
        - -

        Last updated 9/19/2002 - + +

        Last updated 12/13/2002 - Tom Eastep

        - +

        Copyright 2002 Thomas -M. Eastep

        -
        + M. Eastep

        +
        +
        +
        diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 5b52a6219..3e41dbd76 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -4,74 +4,30 @@ - + + Shoreline Firewall (Shorewall) 1.3 - + + - + - - - + - - - -

        Shorwall Logo - Shorewall 1.3 - "iptables - made easy" -

        - - - - - - - - - - - - -
        +
        - - - -
        - -
        - - - - - - + + + + + -

        This program is free software; you can redistribute it and/or modify - it under the terms of Version 2 of the GNU -General Public License as published by the Free Software Foundation.
        -
        - 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.
        -
        - 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

        +
        - - - - - - -

        What is it?

        +         		@@ -80,10 +36,14 @@ -

        The Shoreline Firewall, more commonly known as "Shorewall", is -a Netfilter (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.

        +

        Shorwall Logo + + Shorewall 1.3 + - "iptables made easy"

        @@ -91,24 +51,32 @@ firewall that can be used on a dedicated firewall system, a multi-functio + + +
        + + + +
        + +
        + + + + + + + + - - - - - - - - -
        @@ -116,7 +84,61 @@ Cambridge, MA 02139, USA

        - + +

        What is it?

        + + + + + + + + + + +

        The Shoreline Firewall, more commonly known as "Shorewall", is a + Netfilter (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.

        + + + + + + + + + + +

        This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the GNU General +Public License as published by the Free Software Foundation.
        + +
        + + 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.
        + +
        + + 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

        + + + + + + + + + +

        Copyright 2001, 2002 Thomas M. Eastep

        @@ -125,18 +147,23 @@ Cambridge, MA 02139, USA

        - + + +

        - Jacques - Nilo and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution called - Bering that features Shorewall-1.3.10 and -Kernel-2.4.18. You can find their work at: Jacques Nilo and Eric Wolzak have + a LEAF (router/firewall/gateway on a floppy, CD or compact + flash) distribution called Bering that + features Shorewall-1.3.10 and Kernel-2.4.18. You + can find their work at: http://leaf.sourceforge.net/devel/jnilo

        - Congratulations to Jacques and Eric on the recent release of Bering -1.0 Final!!!
        -         + Congratulations to Jacques and Eric on the recent + release of Bering 1.0 Final!!!
        +         + +

        News

        @@ -147,287 +174,225 @@ Kernel-2.4.18. You can find their work at: 11/24/2002 - Shorewall 1.3.11 (New) -

        - -

        In this version:

        - -
          -
        • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. -This option causes Shorewall to make a set of sanity check on TCP packet -header flags.
          • -
        • It is now allowed to use 'all' in the SOURCE or DEST column in -a rule. -When used, 'all' must appear by itself (in may not be qualified) and it does -not enable intra-zone traffic. For example, the rule
          -
          -     ACCEPT loc all tcp 80
          -
          - does not enable http traffic from 'loc' to 'loc'.
          • -
        • Shorewall's use of the 'echo' command is now compatible with -bash clones such as ash and dash.
          • -
        • fw->fw policies now generate a startup error. fw->fw rules -generate a warning and are ignored
          • -
        -

        11/14/2002 - Shorewall Documentation in PDF Format 12/27/2002 - Shorewall 1.3.12 Released (New) -

        - -

        Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 - documenation. the PDF may be downloaded from

        - -

            ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
        -     http://slovakia.shorewall.net/pub/shorewall/pdf/
        +

        + +

        Features include:
        +

        + +
          +
        1. "shorewall refresh" now reloads the traffic shaping rules (tcrules + and tcstart).
          2. +
        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.
          3. +
        3. "shorewall [re]start" has been speeded up by more than 40% with + my configuration. Your milage may vary.
          4. +
        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"
          5. +
        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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
          6. +
        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_CHAIN=Yes in shorewall.conf. This allows for marking + input packets based on their destination even when you are using Masquerading + or SNAT.
          7. +
        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.
          8. +
        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.
          9. + +
        + +

        12/20/2002 - Shorewall 1.3.12 Beta 3

        - -

        11/09/2002 - Shorewall is Back at SourceForge (New) -

        - - -

        The main Shorewall web site is now at SourceForge at http://shorewall.sf.net.
        -

        - - -

        11/09/2002 - Shorewall 1.3.10 (New) -

        - - - -

        In this version:

        - - - - - If you have installed the 1.3.10 Beta 1 RPM and are now -upgrading to version 1.3.10, you will need to use the '--force' option:
        - - -
        - - - 
        rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
        -
        - - - -

        10/24/2002 - Shorewall is now in Gentoo Linux
        -

        - Alexandru Hartmann reports that his Shorewall package - is now a part of the Gentoo - Linux distribution. Thanks Alex!
        - - - -

        10/23/2002 - Shorewall 1.3.10 Beta 1

        - In this version:
        - - - - - - You may download the Beta from:
        - - - - - - - - -

        10/10/2002 - Debian 1.3.9b Packages Available -
        -

        - + 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.
        + +

        You may download the Beta from:
        +

        + +
        http://www.shorewall.net/pub/shorewall/Beta
        + ftp://ftp.shorewall.net/pub/shorewall/Beta
        +
        + +

        12/20/2002 - Shorewall 1.3.12 Beta 2 +

        + The first public Beta version of Shorewall 1.3.12 is now available +(Beta 1 was made available only to a limited audience).
        +
        + Features include:
        +
        + +
          +
        1. "shorewall refresh" now reloads the traffic shaping rules + (tcrules and tcstart).
          2. +
        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.
          3. +
        3. "shorewall [re]start" has been speeded up by more than +40% with my configuration. Your milage may vary.
          4. +
        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"
          5. +
        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 + http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
          6. +
        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_CHAIN=Yes in shorewall.conf. +This allows for marking input packets based on their destination even when +you are using Masquerading or SNAT.
          7. +
        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.
          8. + +
        + You may download the Beta from:
        + +
        http://www.shorewall.net/pub/shorewall/Beta
        + ftp://ftp.shorewall.net/pub/shorewall/Beta
        +
        + +

        12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux +

        + Shorewall is at the center of MandrakeSofts's recently-announced + Multi + Network Firewall (MNF) product. Here is the press + release.
        + +

        12/7/2002 - Shorewall Support for Mandrake 9.0 +

        + +

        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.

        + +

        12/6/2002 -  Debian 1.3.11a Packages Available
        +

        +

        Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

        + +

        12/3/2002 - Shorewall 1.3.11a +

        + + +

        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.

        + + +

        11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format +

        - -

        10/9/2002 - Shorewall 1.3.9b (New) -

        - This release rolls up fixes to the installer - and to the firewall script.
        -
        - 10/6/2002 - Shorewall.net now running -on RH8.0         (New) -
        -
        - The firewall and server here at shorewall.net - are now running RedHat release 8.0.
        + +

        Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11 + documenation. the PDF may be downloaded from

        + +

            ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
        +     http://slovakia.shorewall.net/pub/shorewall/pdf/
        +

        - -

        9/30/2002 - Shorewall 1.3.9a -

        - Roles up the fix for broken tunnels.
        - - - - - -

        9/30/2002 - TUNNELS Broken in 1.3.9!!! + +

        11/24/2002 - Shorewall 1.3.11

        - Brown Paper Bag - There is an updated firewall script - at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
        + +

        In this version:

        - - - -


        -

        - - - - - -


        -

        - - - - - -


        - 9/28/2002 - Shorewall 1.3.9         -

        - - - - - - -

        In this version:
        -

        - - - - - - + +
          +
        • A 'tcpflags' option has been added to entries + in /etc/shorewall/interfaces. + This option causes Shorewall to make a set of sanity check on TCP packet + header flags.
          • +
        • It is now allowed to use 'all' in the SOURCE +or DEST column in a rule. When + used, 'all' must appear by itself (in may not be qualified) and it +does not enable intra-zone traffic. For example, the rule
          +
          +     ACCEPT loc all tcp 80
          +
          + does not enable http traffic from 'loc' to 'loc'.
          • +
        • Shorewall's use of the 'echo' command is now +compatible with bash clones such as ash and dash.
          • +
        • fw->fw policies now generate a startup error. + fw->fw rules generate a warning and are ignored
          • + + +
        + + +

        11/14/2002 - Shorewall Documentation in PDF Format +

        + + + +

        Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 + documenation. the PDF may be downloaded from

        + + + +

            ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
        +     http://slovakia.shorewall.net/pub/shorewall/pdf/
        +

        + + + +

        +
          -
        • DNS Names are now - allowed in Shorewall config files (although I recommend - against using them).
          • -
        • The connection -SOURCE may now be qualified by both interface and IP -address in a Shorewall rule.
          • -
        • Shorewall startup - is now disabled after initial installation until the - file /etc/shorewall/startup_disabled is removed. This avoids - nasty surprises at reboot for users who install Shorewall - but don't configure it.
          • -
        • The 'functions' -and 'version' files and the 'firewall' symbolic link -have been moved from /var/lib/shorewall to /usr/lib/shorewall - to appease the LFS police at Debian.
          -
          • - - +
        - - - - - -

        More News

        + +

        More News

        @@ -435,86 +400,109 @@ have been moved from /var/lib/shorewall to /usr/lib/shorewall - -

        - - -

        SourceForge Logo -

        - - -

        - -

        This site is hosted by the generous folks at SourceForge.net

        - - -

        Donations

        - -         		-
        -
        -
        -
        - - - - - - - - - - +

        + + + +

        SourceForge Logo +

        + + + +

        + + + +

        This site is hosted by the generous folks at SourceForge.net

        + + + + +

        Donations

        + + + + + + + + + + + + + +
        - - - - - - -

        -

        - - - - - - - -

        Shorewall is free -but if you try it and find it useful, please consider making a donation - to Starlight -Children's Foundation. Thanks!

        -

        +
        + +
        + +
        + + + + + + + + + + + + + + + + + + +
        + + + + + + + + +

        + +

        + + + + + + + + + +

        Shorewall is free but +if you try it and find it useful, please consider making a donation + to Starlight Children's +Foundation. Thanks!

        + +
        - -

        Updated 11/24/2002 - Tom Eastep - -
        -

        -
        + +

        Updated 12/22/2002 - Tom Eastep + +
        +



        diff --git a/Shorewall-docs/standalone.htm b/Shorewall-docs/standalone.htm index f514705e2..6aca3a303 100644 --- a/Shorewall-docs/standalone.htm +++ b/Shorewall-docs/standalone.htm @@ -1,427 +1,430 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
        +

        Standalone Firewall

        -
        - +

        Version 2.0.1

        - -

        Setting up Shorewall on a standalone Linux system is very - easy if you understand the basics and follow the documentation.

        - -

        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 -in one of its most common configurations:

        - + +

        Setting up Shorewall on a standalone Linux system is very + easy if you understand the basics and follow the documentation.

        + +

        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 + in one of its most common configurations:

        +
          -
        • Linux system
          • -
        • Single external IP address
          • -
        • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
          • - +
        • Linux system
          • +
        • Single external IP address
          • +
        • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
          • +
        - -

        This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell if - this package is installed by the presence of an ip program on your - firewall system. As root, you can use the 'which' command to check for -this program:

        - + +

        This guide assumes that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell +if this package is installed by the presence of an ip program on +your firewall system. As root, you can use the 'which' command to check +for this program:

        + 
             [root@gateway root]# which ip
             /sbin/ip
             [root@gateway root]#
        - -

        I recommend that you read through the guide first 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 - .

        +

        I recommend that you read through the guide first 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 + .

        +

        -     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.

        - +     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.

        + - +

        Shorewall Concepts

        - -

        The configuration files for Shorewall are contained in the directory -/etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed -Shorewall, download the one-interface sample, -un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall - (they will replace files with the same names that were placed in /etc/shorewall - during Shorewall installation).

        - -

        As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

        - -

        Shorewall views the network where it is running as being composed of a - set of zones. In the one-interface sample configuration, only one - zone is defined:

        - + +

        +    The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you only need to deal with a few of + these as described in this guide. After you have installed +Shorewall, download the one-interface sample, +un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall + during Shorewall installation).

        + +

        As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

        + +

        Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only one + zone is defined:

        + - + + + + + - - - - - - - - - + + + + +
        NameDescription
        NameDescription
        netThe Internet
        netThe Internet
        - +

        Shorewall zones are defined in /etc/shorewall/zones.

        - -

        Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

        - -

        Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

        - + +

        Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

        + +

        Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

        + - -

        For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file matches - the connection request then the first policy in /etc/shorewall/policy that - matches the request is applied. If that policy is REJECT or DROP  the -request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

        - -

        The /etc/shorewall/policy file included with the one-interface sample has -the following policies:

        - -
        + +

        For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common +(the samples provide that file for you).

        + +

        The /etc/shorewall/policy file included with the one-interface sample +has the following policies:

        + +
        - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
        SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
        SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
        fwnetACCEPT  
        netnetDROPinfo 
        allallREJECTinfo 
        fwnetACCEPT  
        netnetDROPinfo 
        allallREJECTinfo 
        -
        - +
        + 
             fw		net	ACCEPT
             net	all	DROP	info
             all	all	REJECT	info
        - +

        The above policy will:

        - +
          -
        1. allow all connection requests from the firewall to the internet
          2. -
        2. drop (ignore) all connection requests from the internet to your -firewall
          3. -
        3. reject all other connection requests (Shorewall requires this catchall - policy).
          4. - +
        4. allow all connection requests from the firewall to the internet
          5. +
        5. drop (ignore) all connection requests from the internet to your + firewall
          6. +
        6. reject all other connection requests (Shorewall requires this +catchall policy).
          7. +
        - -

        At this point, edit your /etc/shorewall/policy and make any changes that - you wish.

        - + +

        At this point, edit your /etc/shorewall/policy and make any changes that + you wish.

        +

        External Interface

        - -

        The firewall has a single network interface. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter (eth0) that is connected to that "Modem"  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be -a ppp0. If you connect via a regular modem, your External Interface - will also be ppp0. If you connect using ISDN, your external interface - will be ippp0.

        - + +

        The firewall has a single network interface. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter (eth0) that is connected to that "Modem"  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point Tunneling + Protocol (PPTP) in which case the External Interface will be +a ppp0. If you connect via a regular modem, your External Interface + will also be ppp0. If you connect using ISDN, your external interface + will be ippp0.

        +

        -     The Shorewall one-interface sample configuration assumes that the -external interface is eth0. If your configuration is different, you -will have to modify the sample /etc/shorewall/interfaces file accordingly. -While you are there, you may wish to review the list of options that are -specified for the interface. Some hints:

        - +     The Shorewall one-interface sample configuration assumes that the + external interface is eth0. If your configuration is different, +you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that are + specified for the interface. Some hints:

        +
          -
        • -

          If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

          -
          • -
        • -

          If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

          -
          • - +
        • +

          If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

          +
          • +
        • +

          If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option + list.

          +
          • +
        - -
        + +

        IP Addresses

        -
        - -
        -

        RFC 1918 reserves several Private IP address ranges - for use in private networks:

        - -
        +
        + +
        +

        RFC 1918 reserves several Private IP address ranges + for use in private networks:

        + +
             10.0.0.0    - 10.255.255.255
             172.16.0.0  - 172.31.255.255
             192.168.0.0 - 192.168.255.255
        -
        - -

        These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation - to rewrite packet headers when forwarding to/from the internet.

        - +
        + +

        These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs + are assigning these addresses then using Network Address Translation + to rewrite packet headers when forwarding to/from the internet.

        +

        -      Before starting Shorewall, you should look at the IP address of - your external interface and if it is one of the above ranges, you should - remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

        -
        - -
        -

        Enabling other Connections

        +      Before starting Shorewall, you should look at the IP address +of your external interface and if it is one of the above ranges, you +should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

        - -
        -

        If you wish to enable connections from the internet to your - firewall, the general format is:

        -
        - -
        -
        + +
        +

        Enabling other Connections

        +
        + +
        +

        If you wish to enable connections from the internet to your + firewall, the general format is:

        +
        + +
        +
        - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfw<protocol><port>  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfw<protocol><port>  
        -
        +
        +
        + +
        +

        Example - You want to run a Web Server and a POP3 Server +on your firewall system:

        - -
        -

        Example - You want to run a Web Server and a POP3 Server on -your firewall system:

        -
        - -
        -
        + +
        +
        - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp80  
        ACCEPTnetfwtcp110  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp80  
        ACCEPTnetfwtcp110  
        -
        +
        +
        + +
        +

        If you don't know what port and protocol a particular +application uses, see here.

        - -
        -

        If you don't know what port and protocol a particular application -uses, see here.

        -
        - -
        -

        Important: 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:

        -
        - -
        -
        + +
        +

        Important: 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:

        +
        + +
        +
        - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        -
        -
        - -
        +
        +
        + +
             ACCEPT	net	fw	tcp	22
        -
        - -
        +
        + +

        -     At this point, edit /etc/shorewall/rules to add other connections - as desired.

        -
        - -
        -

        Starting and Stopping Your Firewall

        +     At this point, edit /etc/shorewall/rules to add other connections + as desired.

        - -
        + +
        +

        Starting and Stopping Your Firewall

        +
        + +

        Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start -Shorewall before configuration is complete. Once you have completed configuration +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start +Shorewall before configuration is complete. Once you have completed configuration of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
        -

        - -

        IMPORTANT: Users of the .deb - package must edit /etc/default/shorewall and set 'startup=1'.
        -

        -
        +

        -
        -

        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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

        -
        - -
        -

        WARNING: 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 /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall -try" command.

        -
        - -

        Last updated 11/21/2002 - IMPORTANT: Users of the .deb + package must edit /etc/default/shorewall and set 'startup=1'.
        +

        +
        + +
        +

        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 /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

        +
        + +
        +

        WARNING: 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 /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall + try" command.

        +
        + +

        Last updated 12/9/2002 - Tom Eastep

        - -

        Copyright 2002 Thomas - M. Eastep

        -
        + +

        Copyright 2002 Thomas + M. Eastep

        +
        +



        diff --git a/Shorewall-docs/subnet_masks.htm b/Shorewall-docs/subnet_masks.htm deleted file mode 100644 index d3d0b3159..000000000 --- a/Shorewall-docs/subnet_masks.htm +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - -Subnet Masks - - - - - - - - -
        -

        Subnet Masks/VLSM Notation

        -
        -

        IP addresses and subnet masks are 32-bit numbers. The notation -w.x.y.z refers to an address where the high-order byte has value "w", the next -byte has value "x", etc. If we take 255.255.255.0 and express it in -hexadecimal, -we get:

        -
        -

        FF.FF.FF.00

        -
        -

        or looking at it as a 32-bit integer

        -
        -

        FFFFFF00

        -
        -

        Each "F" represents the bit pattern "1111" so if we look at the -number in binary, we have:

        -
        -

        11111111111111111111111100000000

        -
        -

        Counting the leading "1" bits, we see that there are 24 -- /24 -in VLSM notation.

        -

        It is handy to remember that the size of the subnet can be -obtained by subtracting the number of consecutive leading "1" bits from 32 and -raising 2 to that power. In the above case, 32 - 24 = 8 and 2 ** 8 = 256 -addresses. Remember that the number of usable addresses is two less than that -(254) because the first and last address in the subnet are reserved as the -sub-network and broadcast addresses respectively.

        -

        The size of a subnet can be any power of two so long as the -address of the subnet is a multiple of it's size. For example, if you want a -subnet of size 8, you could choose 192.168.12.8/29 (8 = 2 ** 3 and 32 - 3 = 29). -The subnet mask would be:

        -
        -

        11111111111111111111111111111000 = FFFFFFF8 = 255.255.255.248.

        -
        -

        This subnet would have 6 usable addresses: 192.168.12.9 - -192.168.12.14.

        -

        You will still hear the terms "Class A network", "Class B -network" and "Class C network". In the early days of IP, sub-networks only came -in three sizes:

        -
        -

        Class A - Subnet mask 255.0.0.0, size = 2 ** 24

        -

        Class B - Subnet mask 255.255.0.0, size = 2 ** 16

        -

        Class C - Subnet mask 255.255.255.0, size = 256

        -
        -

        The class of a network was 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 subnet mask.

        -

        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 corporations and universities were assigned their own class A -network!). It was then that VLSM was devised -- today, any system that you are -likely to work with understands VLSM and Class-based subnetworking is largely a -thing of the past.

        -

        Last updated -7/15/2002 - Tom -Eastep

        -

        Copyright 2002 Thomas M. Eastep

        - - - - \ No newline at end of file diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index a278e2be4..13e6171fc 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,85 +1,122 @@ - + + - + + - + + - + + Support - + + + - + - - - - - - -
        - -

        Shorewall Support

        -
        - -

        "It is -easier to post a problem than to use your own brain" -- Wietse Venema (creator of Postfix)

        - -

        "Any sane computer will tell you how it works -- you just - have to ask it the right questions" -- Tom Eastep

        - -
        - -

        "It irks me when people believe that - free software comes at no cost. The cost is incredibly high." - - Wietse Venem
        -

        - -

        Before Reporting a Problem

        - "Reading the documentation fully is a prerequisite to getting help -for your particular situation. I know it's harsh but you will have to get -so far on your own before you can get reasonable help from a list full of -busy people. A mailing list is not a tool to speed up your day by being spoon -fed". -- Simon White
        - -

        There are also a number of sources for problem solution information.

        - -
          -
        • The FAQ has solutions to common problems.
          • -
        • The Troubleshooting Information - contains a number of tips to help you solve common problems.
          • -
        • The Errata has links to download - updated components.
          • -
        • The Mailing List Archives search facility can locate posts -about similar problems:
          • - -
        - -

        Mailing List Archive Search

        - -
        + + + + + +

        Shorewall Support +

        + + + + + + + +


        +

        + +

        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.

        + +

        -Tom

        + +

        Before Reporting a Problem

        + +

        There are a number of sources for problem solution information. Please + try these before you post.

        + +

        + +

        + +
          +
        • +

          The FAQ has solutions to more than 20 common + problems.

          +
          • + +
        + +

        + +
          +
        • +

          The Troubleshooting Information + contains a number of tips to help you solve common problems.

          +
          • + +
        + +

        + +
          +
        • +

          The Errata has links to download + updated components.

          +
          • + +
        + +

        + +
          +
        • +

          The Mailing List Archives search facility can locate posts + about similar problems:

          +
          • + +
        + +

        + +

        Mailing List Archive Search

        + + + +

        Match: -

        Match: - Format: + Format: + - Sort by: + Sort by: + -
        - Search:

        - - -

        Problem Reporting Guideline

        - -
          -
        • 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.
          • -
        • 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.
          • -
        • Do you see any "Shorewall" messages in /var/log/messages - when you exercise the function that is giving you problems?
          • -
        • Have you looked at the packet flow with a tool like tcpdump - to try to understand what is going on?
          • -
        • 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.
          • -
        • Please include any of the Shorewall configuration files (especially - the /etc/shorewall/hosts file if you have modified that file) that you - think are relevant. If an error occurs when you try to "shorewall start", - include a trace (See the Troubleshooting - section for instructions).
          • -
        • 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.
          • - -
        - -

        Where to Send your Problem Report or to Ask for Help

        - If you run Shorewall on Mandrake 9.0 -- send your problem - reports and questions to MandrakeSoft. I ordered a Mandrake 9.0 boxed set - on October 3, 2002; MandrakeSoft issued a charge against my credit card -on October 4, 2002 (they are really effecient at that part of the order -process) and I haven't heard a word from them since (although their news -letters boast that 9.0 boxed sets have been shipping for the last two weeks). -If they can't fill my 9.0 order within 6 weeks after they have billed -my credit card then I refuse to spend my free time supporting of their -product for them.
        + Search:

        + + +

        Problem Reporting Guidelines

        + "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?
        +
        + 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."
        +
        -

        If you run Shorewall under Bering -- please - post your question or problem to the LEAF Users mailing list.

        - -

        Otherwise, please post your question or problem to the Shorewall users mailing list; - there are lots of folks there who are willing to help you. Your question/problem - description and their responses will be placed in the mailing list archives - to help people who have a similar question or problem in the future.

        - -

        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 mailing list.

        - -

        -Tom

        +
           - Russell Mosemann
        +
        +
        +

        + +
          +
        • +

          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.

          +
          • + +
        + +

        + +
          +
        • +

          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.

          +
          • + +
        + +

        + +
          +
        • +

          Do you see any "Shorewall" messages in /var/log/messages + when you exercise the function that is giving you problems?

          +
          • + +
        + +

        + +
          +
        • +

          Have you looked at the packet flow with a tool like tcpdump + to try to understand what is going on?

          +
          • + +
        + +

        + +
          +
        • +

          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.

          +
          • + +
        + +

        + +
          +
        • +

          Please include any of the Shorewall configuration files (especially + the /etc/shorewall/hosts file if you have modified that file) +that you think are relevant.

          +
          • +
        • +

          If an error occurs when you try to "shorewall start", include +a trace (See the Troubleshooting section +for instructions).

          +
          • + +
        + +

        + +
          +
        • +

          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.

          +
          • + +
        + +

        + +

        Please post in plain text

        +
        +

        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"!!

        +

        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.

        +

        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.

        +

        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.

        +
        +

        Where to Send your Problem Report or to Ask for Help

        + +

        + +
        +

        If you run Shorewall under Bering -- please post your question or problem + to the LEAF Users mailing + list.

        + +

        Otherwise, please post your question or problem to the Shorewall users mailing list.

        +
        + + + +

        + +

        To Subscribe to the mailing list go to http://www.shorewall.net/mailman/listinfo/shorewall-users - .

        - -

        Last Updated 11/19//2002 - Tom Eastep

        - + .

        + + +

        Last Updated 12/27/2002 - Tom Eastep

        +

        Copyright © 2001, 2002 Thomas M. Eastep.
        -

        - +

        +
        +
        +
        +
        +
        diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm index 32c0b1c29..2809537a6 100644 --- a/Shorewall-docs/three-interface.htm +++ b/Shorewall-docs/three-interface.htm @@ -1,1113 +1,1138 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
        - +
        +

        Three-Interface Firewall

        -
        - +

        Version 2.0.1

        - -

        Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the basics - and follow the documentation.

        - -

        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 - in one of its more popular configurations:

        - + +

        Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the basics + and follow the documentation.

        + +

        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 + in one of its more popular configurations:

        +
          -
        • Linux system used as a firewall/router for a small local network.
          • -
        • Single public IP address.
          • -
        • DMZ connected to a separate ethernet interface.
          • -
        • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, - ...
          • - +
        • Linux system used as a firewall/router for a small local +network.
          • +
        • Single public IP address.
          • +
        • DMZ connected to a separate ethernet interface.
          • +
        • Connection through DSL, Cable Modem, ISDN, Frame Relay, +dial-up, ...
          • +
        - +

        Here is a schematic of a typical installation.

        - +

        -

        - -

        This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program on - your firewall system. As root, you can use the 'which' command to check - for this program:

        - +

        + +

        This guide assumes that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program +on your firewall system. As root, you can use the 'which' command to +check for this program:

        + 
             [root@gateway root]# which ip
             /sbin/ip
             [root@gateway root]#
        - -

        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 -

        - + +

        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 +

        +

        -     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.

        - +     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.

        + - +

        Shorewall Concepts

        - -

        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 installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the - files to /etc/shorewall (the files will replace files with the same names - that were placed in /etc/shorewall when Shorewall was installed).

        - -

        As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

        - -

        Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, the -following zone names are used:

        - + +

        +     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 installed Shorewall, download the three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy +the files to /etc/shorewall (the files will replace files with the same +names that were placed in /etc/shorewall when Shorewall was installed).

        + +

        As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

        + +

        Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, the + following zone names are used:

        + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        NameDescription
        netThe Internet
        locYour Local Network
        dmzDemilitarized Zone
        NameDescription
        netThe Internet
        locYour Local Network
        dmzDemilitarized Zone
        - +

        Zone names are defined in /etc/shorewall/zones.

        - -

        Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

        - -

        Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

        - + +

        Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

        + +

        Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

        + - -

        For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  - the request is first checked against the rules in /etc/shorewall/common -(the samples provide that file for you).

        - -

        The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

        - -
        + +

        For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

        + +

        The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT  
        netallDROPinfo 
        allallREJECTinfo 
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT  
        netallDROPinfo 
        allallREJECTinfo 
        -
        - -
        -

        In the three-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.

        - +
        + +
        +

        In the three-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.

        + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT  
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT  
        -
        - +
        +

        The above policy will:

        - +
          -
        1. allow all connection requests from your local network to the - internet
          2. -
        2. drop (ignore) all connection requests from the internet to -your firewall or local network
          3. -
        3. optionally accept all connection requests from the firewall -to the internet (if you uncomment the additional policy)
          4. -
        4. reject all other connection requests.
          5. - +
        5. allow all connection requests from your local network to +the internet
          6. +
        6. drop (ignore) all connection requests from the internet +to your firewall or local network
          7. +
        7. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
          8. +
        8. reject all other connection requests.
          9. +
        - +

        -     At this point, edit your /etc/shorewall/policy file and make -any changes that you wish.

        - +     At this point, edit your /etc/shorewall/policy file and make + any changes that you wish.

        +

        Network Interfaces

        - +

        -

        - -

        The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., -eth0)  unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the External Interface -will be a ppp interface (e.g., ppp0). If you connect via a regular -modem, your External Interface will also be ppp0. If you connect -using ISDN, you external interface will be ippp0.

        - +

        + +

        The firewall has three network interfaces. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter that is connected to that "Modem" (e.g., + eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect via + a regular modem, your External Interface will also be ppp0. If you + connect using ISDN, you external interface will be ippp0.

        +

        -     If your external interface is ppp0 or ippp0 then - you will want to set CLAMPMSS=yes in ppp0 or ippp0 then + you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

        - -

        Your Local Interface 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 cross-over cable).

        - -

        Your DMZ Interface 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 cross-over cable).

        - + +

        Your Local Interface 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 cross-over cable).

        + +

        Your DMZ Interface 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 cross-over cable).

        +

        - Do not connect more than one interface to the same hub or -switch (even for testing). It won't work the way that you expect it to -and you will end up confused and believing that Shorewall doesn't work -at all.

        - + Do not connect more than one interface to the same hub +or switch (even for testing). It won't work the way that you expect it +to and you will end up confused and believing that Shorewall doesn't + work at all.

        +

        -     The Shorewall three-interface sample configuration assumes that - the external interface is eth0, the local interface is eth1 -and the DMZ interface is eth2. If your configuration is different, - you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interfaces. Some hints:

        - +     The Shorewall three-interface sample configuration assumes +that the external interface is eth0, the local interface is eth1 + and the DMZ interface is eth2. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that +are specified for the interfaces. Some hints:

        +
          -
        • -

          If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

          -
          • -
        • -

          If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

          -
          • - +
        • +

          If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

          +
          • +
        • +

          If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the + option list.

          +
          • +
        - +

        IP Addresses

        - -

        Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic - Host Configuration Protocol (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 static IP address; that - means that you configure your firewall's external interface to use that - address permanently. Regardless of how the 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 for your internal network (the -local and DMZ Interfaces on your firewall plus your other computers). RFC -1918 reserves several Private IP address ranges for this purpose:

        - -
        + +

        Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you +a single Public IP address. This address may be assigned via +the Dynamic Host Configuration Protocol (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 static +IP address; that means that you configure your firewall's external interface +to use that address permanently. Regardless of how the 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 for your internal +network (the local and DMZ Interfaces on your firewall plus your other +computers). RFC 1918 reserves several Private IP address ranges for +this purpose:

        + +
             10.0.0.0    - 10.255.255.255
             172.16.0.0  - 172.31.255.255
             192.168.0.0 - 192.168.255.255
        -
        - -
        +
        + +

        -     Before starting Shorewall, you should look at the IP address - of your external interface and if it is one of the above ranges, you - should remove the 'norfc1918' option from the external interface's +     Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you + should remove the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

        -
        - -
        -

        You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another - subnet. For our purposes, we can consider a subnet to consists of a -range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet - Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet - Address and x.y.z.255 is reserved as the Subnet Broadcast -Address. In Shorewall, a subnet is described using Classless InterDomain Routing (CIDR) -notation with consists of the subnet address followed by "/24". The "24" -refers to the number of consecutive "1" bits from the left of the subnet -mask.

        -
        - -
        +
        + +
        +

        You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another + subnet. For our purposes, we can consider a subnet to consists of a +range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet + Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet + Address and x.y.z.255 is reserved as the Subnet Broadcast + Address. In Shorewall, a subnet is described using Classless InterDomain Routing +(CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from +the left of the subnet mask.

        +
        + +

        Example sub-network:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        Range:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        Range:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        -
        -
        - -
        -

        It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

        -
        - -
        -

        One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

        -
        - -
        + +
        + +
        +

        It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

        +
        + +
        +

        One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

        +
        + +

        -     Your local computers (Local Computers 1 & 2) should be -configured with their default gateway set to the IP address of -the firewall's internal interface and your DMZ computers ( DMZ Computers -1 & 2) should be configured with their default gateway set to the -IP address of the firewall's DMZ interface.  

        -
        - -

        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 "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        - -

        The remainder of this quide will assume that you have configured - your network as shown here:

        - +     Your local computers (Local Computers 1 & 2) should +be configured with their default gateway set to the IP address + of the firewall's internal interface and your DMZ computers ( DMZ +Computers 1 & 2) should be configured with their default gateway +set to the IP address of the firewall's DMZ interface.  

        +
        + +

        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 "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        + +

        The remainder of this quide will assume that you have configured + your network as shown here:

        +

        -

        - -

        The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.

        - +

        + +

        The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.

        +

        IP Masquerading (SNAT)

        - -

        The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't forward - packets which have an RFC-1918 destination address. When one of your -local systems (let's assume local computer 1) sends a connection request -to an internet host, the firewall must perform Network Address Translation - (NAT). The firewall rewrites the source address in the packet to be - the address of the firewall's external interface; in other words, the firewall - makes it look as if the firewall itself is initiating the connection.  -This is necessary so that the destination host will be able to route return -packets back to the firewall (remember that packets whose destination -address is reserved by RFC 1918 can't be routed accross the internet). -When the firewall receives a return packet, it rewrites the destination -address back to 10.10.10.1 and forwards the packet on to local computer -1.

        - -

        On Linux systems, the above process is often referred to as - IP Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

        - + +

        The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When one +of your local systems (let's assume local computer 1) sends a connection + request to an internet host, the firewall must perform Network Address + Translation (NAT). The firewall rewrites the source address in the + packet to be the address of the firewall's external interface; in other + words, the firewall makes it look as if the firewall itself is initiating + the connection.  This is necessary so that the destination host will be + able to route return packets back to the firewall (remember that packets + whose destination address is reserved by RFC 1918 can't be routed accross + the internet). When the firewall receives a return packet, it rewrites + the destination address back to 10.10.10.1 and forwards the packet on +to local computer 1.

        + +

        On Linux systems, the above process is often referred to +as IP Masquerading and you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

        +
          -
        • -

          Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

          -
          • -
        • -

          SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local network - to use.

          -
          • - +
        • +

          Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

          +
          • +
        • +

          SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local +network to use.

          +
          • +
        - -

        In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

        - + +

        In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

        +

        -     If your external firewall interface is eth0, your local - interface eth1 and your DMZ interface is eth2 then you do - not need to modify the file provided with the sample. Otherwise, edit - /etc/shorewall/masq and change it to match your configuration.

        - +     If your external firewall interface is eth0, your local + interface eth1 and your DMZ interface is eth2 then you +do not need to modify the file provided with the sample. Otherwise, edit + /etc/shorewall/masq and change it to match your configuration.

        +

        -     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. -

        - -

        Port Forwarding (DNAT)

        - -

        One of your goals will be to run one or more servers on your - DMZ 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 your firewall who rewrites the destination address to the address of -your server and forwards the packet to that server. When your server responds, - the firewall automatically performs SNAT to rewrite the source address -in the response.

        - -

        The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure port - forwarding using DNAT rules in the /etc/shorewall/rules file.

        - -

        The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>  
        -
        - -

        If you don't specify the <server port>, it is assumed to be -the same as <port>.

        - -

        Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
        ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
        -
        - -

        A couple of important points to keep in mind:

        - -
          -
        • When you are connecting to your server from your local systems, - you must use the server's internal IP address (10.10.11.2).
          • -
        • Many ISPs block incoming connection requests to port 80. If -you have problems connecting to your web server, try the following rule -and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
          • - -
        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000  
        -
        - -

        If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can replace - the loc->dmz rule above with:

        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        -
        - -

        If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows (assume - that your external interface is eth0):

        - -
          -
        1. Include the following in /etc/shorewall/params:
          -
          - ETH0_IP=`find_interface_address eth0`
          -  
          2. -
        2. Make your loc->dmz rule:
          3. - -
        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATloc
        -         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        -
        - -

        If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

        - -

        -     At this point, add the DNAT and ACCEPT rules for your servers. +     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.

        - -

        Domain Name Server (DNS)

        - -

        Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your - primary and secondary name servers. It is your responsibility to - configure the resolver in your internal systems. You can take one of two - approaches:

        - + +

        +     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:
        +

        +
          -
        • -

          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.

          -
          • -
        • +
        • NAT_ENABLED=Yes
          • +
        • IP_FORWARDING=On
          +
          • + +
        + +

        Port Forwarding (DNAT)

        + +

        One of your goals will be to run one or more servers on your + DMZ 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 your firewall who rewrites the destination address to the +address of your server and forwards the packet to that server. When your +server responds, the firewall automatically performs SNAT to rewrite +the source address in the response.

        + +

        The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

        + +

        The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>  
        +
        + +

        If you don't specify the <server port>, it is assumed to +be the same as <port>.

        + +

        Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

        + +
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
        ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
        +
        + +

        A couple of important points to keep in mind:

        + +
          +
        • When you are connecting to your server from your local systems, + you must use the server's internal IP address (10.10.11.2).
          • +
        • Many ISPs block incoming connection requests to port 80. +If you have problems connecting to your web server, try the following + rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
          • + +
        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000  
        +
        + +

        If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you can + replace the loc->dmz rule above with:

        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        +
        + +

        If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows +(assume that your external interface is eth0):

        + +
          +
        1. Include the following in /etc/shorewall/params:
          +
          + ETH0_IP=`find_interface_address eth0`
          +  
          2. +
        2. Make your loc->dmz rule:
          3. + +
        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATloc
        +         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        +
        + +

        If you want to access your server from the DMZ using your external IP + address, see FAQ 2a.

        + +

        +     At this point, add the DNAT and ACCEPT rules for your servers. +

        + +

        Domain Name Server (DNS)

        + +

        Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as +your primary and secondary name servers. It is your responsibility +to configure the resolver in your internal systems. You can take one +of two approaches:

        + +
          +
        • +

          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. +

          +
          • +

        • -     You can configure a Caching Name Server on your firewall - or in your DMZ. Red Hat has an RPM for a caching name server (which - also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. - If you take this approach, you configure your internal systems to use - the caching name server as their primary (and only) name server. You use - the internal IP address of the firewall (10.10.10.254 in the example above) - for the name server address if you choose to run the name server on -your firewall. To allow your local systems to talk to your caching name - server, you must open port 53 (both UDP and TCP) from the local network -to the server; you do that by adding the rules in /etc/shorewall/rules. -

          -
          • - +     You can configure a Caching Name Server on your firewall + or in your DMZ. Red Hat has an RPM for a caching name server +(which also requires the 'bind' RPM) and for Bering users, there +is dnscache.lrp. If you take this approach, you configure your internal +systems to use the caching name server as their primary (and only) +name server. You use the internal IP address of the firewall (10.10.10.254 +in the example above) for the name server address if you choose to +run the name server on your firewall. To allow your local systems to talk +to your caching name server, you must open port 53 (both UDP and TCP) +from the local network to the server; you do that by adding the rules +in /etc/shorewall/rules.

          + +
        - -
        -

        If you run the name server on the firewall: - + +

        +

        If you run the name server on the firewall: + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53  
        ACCEPTlocfwudp53  
        ACCEPTdmzfwtcp53  
        ACCEPTdmzfwudp53  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53  
        ACCEPTlocfwudp53  
        ACCEPTdmzfwtcp53  
        ACCEPTdmzfwudp53  
        -

        -
        - -
        -
        +

        +
        + +
        +

        Run name server on DMZ computer 1

        - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocdmz:10.10.11.1tcp53  
        ACCEPTlocdmz:10.10.11.1udp53  
        ACCEPTfwdmz:10.10.10.1tcp53  
        ACCEPTfwdmz:10.10.10.1udp53  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocdmz:10.10.11.1tcp53  
        ACCEPTlocdmz:10.10.11.1udp53  
        ACCEPTfwdmz:10.10.10.1tcp53  
        ACCEPTfwdmz:10.10.10.1udp53  
        -
        -
        - -
        +
        +
        + +

        Other Connections

        -
        - -
        +
        + +

        The three-interface sample includes the following rules:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnetudp53  
        ACCEPTfwnettcp53  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnetudp53  
        ACCEPTfwnettcp53  
        -
        -
        - -
        -

        Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

        -
        - -
        + +
        + +
        +

        Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

        +
        + +

        The sample also includes:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22  
        ACCEPTlocdmztcp22  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22  
        ACCEPTlocdmztcp22  
        -
        -
        - -
        -

        That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers from - your local systems.

        -
        - -
        -

        If you wish to enable other connections between your systems, - the general format is:

        -
        - -
        -
        +
        +
        + +
        +

        That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers + from your local systems.

        +
        + +
        +

        If you wish to enable other connections between your systems, + the general format is:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>  
        -
        -
        - -
        -

        Example - You want to run a publicly-available DNS server - on your firewall system:

        -
        - -
        -
        +
        +
        + +
        +

        Example - You want to run a publicly-available DNS server + on your firewall system:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
        ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
        ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
        -
        -
        - -
        -

        Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

        -
        - -
        -

        If you don't know what port and protocol a particular application -uses, look here.

        -
        - -
        -

        Important: 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:

        -
        - -
        -
        +
        +
        + +
        +

        Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

        +
        + +
        +

        If you don't know what port and protocol a particular +application uses, look here.

        +
        + +
        +

        Important: 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:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        -
        -
        - -
        + +
        + +

        -     Now modify /etc/shorewall/rules to add or remove other connections - as required.

        -
        - -
        +     Now modify /etc/shorewall/rules to add or remove other connections + as required.

        +
        + +

        Starting and Stopping Your Firewall

        -
        - -
        +
        + +

        Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
        -

        - +

        +

        IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
        -

        -
        - -
        -

        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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

        -
        - -
        + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall + and set 'startup=1'.
        +

        +
        + +
        +

        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 /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

        +
        + +

        -     The three-interface sample assumes that you want to enable -routing to/from eth1 (your local network) and eth2 (DMZ) -when Shorewall is stopped. If these two interfaces don't connect to -your local network and DMZ or if you want to enable a different set -of hosts, modify /etc/shorewall/routestopped accordingly.

        -
        - -
        -

        WARNING: 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 /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect to + your local network and DMZ or if you want to enable a different set + of hosts, modify /etc/shorewall/routestopped accordingly.

        +
        + + - -

        Last updated 11/21/2002 - + +

        Last updated 12/20/2002 - Tom Eastep

        - -

        Copyright 2002 Thomas - M. Eastep

        + +

        Copyright 2002 Thomas + M. Eastep

        +
        +

        +



        diff --git a/Shorewall-docs/traffic_shaping.htm b/Shorewall-docs/traffic_shaping.htm index ddff1c3b7..7b9d95f9b 100644 --- a/Shorewall-docs/traffic_shaping.htm +++ b/Shorewall-docs/traffic_shaping.htm @@ -1,257 +1,293 @@ - + - + - + - + Traffic Shaping - + - - - + + - - - + + + +
        +
        +

        Traffic Shaping/Control

        -
        - +

        Beginning with version 1.2.0, Shorewall has limited support -for traffic shaping/control. In order to use traffic shaping under Shorewall, -it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO, -version 0.3.0 or later. You must also install the iproute (iproute2) package -to provide the "ip" and "tc" utilities.

        - + version 0.3.0 or later. You must also install the iproute (iproute2) package + to provide the "ip" and "tc" utilities.

        +

        Shorewall traffic shaping support consists of the following:

        - +
          -
        • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping -also requires that you enable packet mangling.
          -
          • -
        • /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.
          -
          • -
        • /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 new TC_ENABLED parameter in /etc/shorewall.conf. Traffic + Shaping also requires that you enable packet mangling.
          +
          • +
        • /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.
          +
          • +
        • /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 sample 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 HTB (see below). HTB - support may eventually become an integral part of Shorewall since HTB -is a lot simpler and better-documented than CBQ. HTB is currently not -a standard part of either the kernel or iproute2 so both must be patched -in order to use it.
          + 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.
          +
          + 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.

          - In tcstart, when you want to run the 'tc' utility, use the run_tc function - supplied by shorewall.
          + You can generally use off-the-shelf traffic shaping scripts by simply copying + them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB version) +that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and +modified it according to the Wonder Shaper README). WARNING: 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.
          • -
        • /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.
          • - +
        • /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.
          • +
        - +

        Kernel Configuration

        - +

        This screen shot show how I've configured QoS in my Kernel:

        - +

        -

        - +

        +

        /etc/shorewall/tcrules

        - +

        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.

        - + packets for traffic shaping. The /etc/shorewall/tcrules file provides +a means for specifying these marks in a tabular fashion.
        +

        +

        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 +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 +shorewall.conf.
        +

        +

        Columns in the file are as follows:

        - +
          -
        • MARK - Specifies the mark value is to be assigned in case of -a match. This is an integer in the range 1-255.
          -
          - Example - 5
          -
          • -
        • 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 Shorewall Format and/or Subnets.
          -
          - Examples
          -     eth0
          -     192.168.2.4,192.168.1.0/24
          -
          • -
        • DEST -- Destination of the packet. Comma-separated list of IP -addresses and/or subnets.
          -
          • -
        • PROTO - Protocol - Must be the name of a protocol from /etc/protocol, -a number or "all"
          -
          • -
        • 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).
          -
          • -
        • CLIENT PORT(S) - (Optional) Port(s) used by the client. If omitted, -any source port is acceptable. Specified as a comma-separate list of port -names, port numbers or port ranges.
          • - +
        • MARK - Specifies the mark value is to be assigned in case of + a match. This is an integer in the range 1-255.
          +
          + Example - 5
          +
          • +
        • 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 + Shorewall Format and/or Subnets.
          +
          + Examples
          +     eth0
          +     192.168.2.4,192.168.1.0/24
          +
          • +
        • DEST -- Destination of the packet. Comma-separated list of + IP addresses and/or subnets.
          +
          • +
        • PROTO - Protocol - Must be the name of a protocol from +/etc/protocol, a number or "all"
          +
          • +
        • 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).
          +
          • +
        • CLIENT PORT(S) - (Optional) Port(s) used by the client. If + omitted, any source port is acceptable. Specified as a comma-separate + list of port names, port numbers or port ranges.
          • +
        - +

        Example 1 - All packets arriving on eth1 should be marked -with 1. All packets arriving on eth2 should be marked with 2. All packets -originating on the firewall itself should be marked with 3.

        - + 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.

        + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        1eth10.0.0.0/0all  
        2eth20.0.0.0/0all  
        3fw0.0.0.0/0all  
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        1eth10.0.0.0/0all  
        2eth20.0.0.0/0all  
        2
        +         		eth3
        +         		0.0.0.0/0
        +         		all
        +
        +
        +
        3fw0.0.0.0/0all  
        - +

        Example 2 - All GRE (protocol 47) packets not originating -on the firewall and destined for 155.186.235.151 should be marked with 12.

        - + on the firewall and destined for 155.186.235.151 should be marked with +12.

        + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        120.0.0.0/0155.186.235.15147  
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        120.0.0.0/0155.186.235.15147  
        - +

        Example 3 - All SSH packets originating in 192.168.1.0/24 -and destined for 155.186.235.151 should be marked with 22.

        - + and destined for 155.186.235.151 should be marked with 22.

        + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        22192.168.1.0/24155.186.235.151tcp22 
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        22192.168.1.0/24155.186.235.151tcp22 
        - -

        Hierarchical Token Bucket

        - -

        I personally use HTB. I have found a couple of things that may be of use -to others.

        - -
          -
        • The gzipped tc binary at the HTB website didn't work -for me -- I had to download the lastest version of the iproute2 sources and patch -them for HTB.
          • -
        • I'm currently running with this set of shaping rules in my tcstart -file. I recently changed from using a ceiling of 10Mbit (interface speed) -to 384kbit (DSP Uplink speed).
          -
          -
          • - -
        + +

        My Setup
        +

        + +

        While I am currently using the HTB version of The Wonder Shaper (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:
        +

        - 
        run_tc qdisc add dev eth0 root handle 1: htb default 30
        run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

        echo "   Added Top Level Class -- rate 384kbit"
        - - 
        run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k
        run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k
        run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500
        - + 
        run_tc qdisc add dev eth0 root handle 1: htb default 30

        run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

        echo "   Added Top Level Class -- rate 384kbit"
        + + 
        run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
        run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
        run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
        + 
        echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
        - - 
        run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
        run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
        run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10
        - - 
        echo "   Enabled SFQ on Second Level Classes"
        - - 
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
        - + + 
        run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
        run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
        run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
        + + 
        echo "   Enabled PFIFO on Second Level Classes"
        + + 
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
        + 
        echo "   Defined fwmark filters"
        - -

        My tcrules file is shown in Example 1 above. You can look at my network configuration to get an idea of why I want -these particular rules.
        -

        -
        - -

        Last Updated 10/25/2002 - Tom Eastep

        - + + +

        My tcrules file that went with this tcstart file is shown in Example 1 + above. You can look at my network configuration + to get an idea of why I wanted these particular rules.
        +

        + +
          +
        1. I wanted to allow up to 140kbits/second for traffic outbound from + my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic +can use all available bandwidth if there is no traffic from the local systems + or from my laptop or firewall).
          2. +
        2. My laptop and local systems could use up to 224kbits/second.
          3. +
        3. My firewall could use up to 20kbits/second.
          +
          4. + +
        + +

        Last Updated 12/20/2002 - Tom Eastep

        +

        Copyright - © 2001, 2002 Thomas M. Eastep.

        -
        -
        + © 2001, 2002 Thomas M. Eastep.
        +

        diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm index 23bb7faf8..7fc06d028 100644 --- a/Shorewall-docs/troubleshoot.htm +++ b/Shorewall-docs/troubleshoot.htm @@ -1,205 +1,234 @@ - + Shorewall Troubleshooting - + - + - + - - - - - - + + + + + +
        -

        Shorewall Troubleshooting

        -
        + +

        Shorewall TroubleshootingBeating head on table +

        +
        - +

        Check the Errata

        - +

        Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version -of the firewall.

        - + sure that there isn't an update that you are missing for your version + of the firewall.

        +

        Check the FAQs

        - +

        Check the FAQs for solutions to common - problems.

        - + problems.

        +

        If the firewall fails to start

        - 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: +
          -
        • shorewall debug start 2> /tmp/trace
          • -
        • Look at the /tmp/trace file and see if that helps you determine - what the problem is.
          • -
        • If you still can't determine what's wrong then see the support page.
          • - +
        • Make a note of the error message that you see.
          +
          • +
        • shorewall debug start 2> /tmp/trace
          • +
        • 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.
          • +
        • If you still can't determine what's wrong then see the + support page.
          • +
        - +Here's an example. During startup, a user sees the following:
        +
        + 
        Adding Common Rules
        iptables: No chain/target/match by that name
        Terminated
        +
        +A search through the trace for "No chain/target/match by that name" turned +up the following:  +
        + 
        + echo 'Adding Common Rules'
        + add_common_rules
        + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
        ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
        ++ sed 's/!/! /g'
        + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
        iptables: No chain/target/match by that name
        +
        +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 kernel.htm) +

        Your network environment

        - +

        Many times when people have problems with Shorewall, the problem is actually an ill-conceived network setup. Here are several popular snafus: -

        - +

        +
          -
        • Port Forwarding where client and server are in the same - subnet. See FAQ 2.
          • -
        • 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.
          • -
        • 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.
          • - +
        • Port Forwarding where client and server are in the + same subnet. See FAQ 2.
          • +
        • 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.
          • +
        • 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.
          • +
        - +

        If you are having connection problems:

        - +

        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.

        - + 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.

        +

        I also recommend against setting all of your policies to ACCEPT in an effort to make something work. That robs you of one of - your best diagnostic tools - the "Shorewall" messages that Netfilter - will generate when you try to connect in a way that isn't permitted - by your rule set.

        - -

        Check your 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 FAQ 17.

        - + your best diagnostic tools - the "Shorewall" messages that Netfilter + will generate when you try to connect in a way that isn't permitted + by your rule set.

        + +

        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 FAQ 17.

        +

        While you are troubleshooting, it is a good idea to clear - two variables in /etc/shorewall/shorewall.conf:

        - + two variables in /etc/shorewall/shorewall.conf:

        +

        LOGRATE=""
        - LOGBURST=""

        - + LOGBURST=""

        +

        This way, you will see all of the log messages being generated (be sure to restart shorewall after clearing these variables).

        - +

        Example:

        - + +

        Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 - LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47

        -         + LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 +LEN=47

        +

        Let's look at the important parts of this message:

        - +
          -
        • all2all:REJECT - This packet was REJECTed out of the all2all chain - -- the packet was rejected under the "all"->"all" REJECT policy (see - FAQ 17).
          • -
        • IN=eth2 - the packet entered the firewall via eth2
          • -
        • OUT=eth1 - if accepted, the packet would be sent on eth1
          • -
        • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
          • -
        • DST=192.168.1.3 - the packet is destined for 192.168.1.3
          • -
        • PROTO=UDP - UDP Protocol
          • -
        • DPT=53 - DNS
          • - +
        • all2all:REJECT - This packet was REJECTed out of the all2all + chain -- the packet was rejected under the "all"->"all" REJECT policy + (see FAQ 17).
          • +
        • IN=eth2 - the packet entered the firewall via eth2
          • +
        • OUT=eth1 - if accepted, the packet would be sent on eth1
          • +
        • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
          • +
        • DST=192.168.1.3 - the packet is destined for 192.168.1.3
          • +
        • PROTO=UDP - UDP Protocol
          • +
        • DPT=53 - DNS
          • +
        - +

        In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 - is in the "loc" zone. I was missing the rule:

        - + is in the "loc" zone. I was missing the rule:

        +

        ACCEPT    dmz    loc    udp    53
        -

        - +

        +

        See FAQ 17 for additional information -about how to interpret the chain name appearing in a Shorewall log message.
        -

        - + about how to interpret the chain name appearing in a Shorewall log message.
        +

        +

        Other Gotchas

        - + - +

        Still Having Problems?

        - +

        See the support page.

        - + +
        -         -

        Last updated 11/21/2002 - Tom Eastep

        - +         +

        Last updated 12/4/2002 - Tom Eastep

        +

        Copyright - © 2001, 2002 Thomas M. Eastep.
        -

        + © 2001, 2002 Thomas M. Eastep.
        +

        +
        +
        +
        +
        diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm index 9c4b2365b..03faf63fb 100644 --- a/Shorewall-docs/two-interface.htm +++ b/Shorewall-docs/two-interface.htm @@ -1,919 +1,952 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
        +
        +

        Basic Two-Interface Firewall

        -
        - +

        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.

        - + is a fairly straight-forward task if you understand the basics and follow + the documentation.

        +

        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 - in its most common configuration:

        - + Shorewall. It rather focuses on what is required to configure Shorewall + in its most common configuration:

        +
          -
        • Linux system used as a firewall/router for a small local network.
          • -
        • Single public IP address.
          • -
        • Internet connection through cable modem, DSL, ISDN, Frame Relay, - dial-up ...
          • - +
        • Linux system used as a firewall/router for a small local +network.
          • +
        • Single public IP address.
          • +
        • Internet connection through cable modem, DSL, ISDN, Frame +Relay, dial-up ...
          • +
        - +

        Here is a schematic of a typical installation.

        - +

        -

        - +

        + +

        If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing". You should not need to refer to this guide.
        +

        +

        This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell -if this package is installed by the presence of an ip program on -your firewall system. As root, you can use the 'which' command to check -for this program:

        - + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program on + your firewall system. As root, you can use the 'which' command to check + for this program:

        + 
             [root@gateway root]# which ip
             /sbin/ip
             [root@gateway root]#
        - +

        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 - .

        - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with + .

        +

        -     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.

        - +     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.

        + - +

        Shorewall Concepts

        - -

        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 installed Shorewall, download the +     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 installed Shorewall, download the two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall - (these files will replace files with the same name).

        - + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall + (these files will replace files with the same name).

        +

        As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

        - + file on your system -- each file contains detailed configuration instructions + and default entries.

        +

        Shorewall views the network where it is running as being composed of a - set of zones. In the two-interface sample configuration, the following - zone names are used:

        - + set of zones. In the two-interface sample configuration, the following + zone names are used:

        + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
        NameDescription
        netThe Internet
        locYour Local Network
        NameDescription
        netThe Internet
        locYour Local Network
        - +

        Zones are defined in the /etc/shorewall/zones - file.

        - + file.

        +

        Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

        - + the firewall itself is known as fw.

        +

        Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

        - + in terms of zones.

        + - +

        For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file -matches the connection request then the first policy in /etc/shorewall/policy -that matches the request is applied. If that policy is REJECT or DROP  -the request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

        - + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

        +

        The /etc/shorewall/policy file included with the two-interface sample has the following policies:

        - -
        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT  
        netallDROPinfo 
        allallREJECTinfo 
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT  
        netallDROPinfo 
        allallREJECTinfo 
        -
        - -
        +
        + +

        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.

        - + out. If you want your firewall system to have full access to servers +on the internet, uncomment that line.

        + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT  
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT  
        -
        - +
        +

        The above policy will:

        - +
          -
        1. allow all connection requests from your local network to the -internet
          2. -
        2. drop (ignore) all connection requests from the internet to your - firewall or local network
          3. -
        3. optionally accept all connection requests from the firewall to - the internet (if you uncomment the additional policy)
          4. -
        4. reject all other connection requests.
          5. - +
        5. allow all connection requests from your local network to +the internet
          6. +
        6. drop (ignore) all connection requests from the internet to + your firewall or local network
          7. +
        7. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
          8. +
        8. reject all other connection requests.
          9. +
        - +

        -     At this point, edit your /etc/shorewall/policy and make any changes - that you wish.

        - +     At this point, edit your /etc/shorewall/policy and make any +changes that you wish.

        +

        Network Interfaces

        - +

        -

        - +

        +

        The firewall has two network interfaces. Where Internet connectivity is through a cable or DSL "Modem", the External Interface will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be - a ppp interface (e.g., ppp0). If you connect via a regular modem, - your External Interface will also be ppp0. If you connect via ISDN, - your external interface will be ippp0.

        - + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point Tunneling + Protocol (PPTP) in which case the External Interface will +be a ppp interface (e.g., ppp0). If you connect via a regular modem, + your External Interface will also be ppp0. If you connect via ISDN, + your external interface will be ippp0.

        +

        -     If your external interface is ppp0 or ippp0  then -you will want to set CLAMPMSS=yes in -/etc/shorewall/shorewall.conf.

        - +     If your external interface is ppp0 or ippp0  +then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

        +

        Your Internal Interface 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 cross-over cable).

        - + (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 cross-over cable).

        +

        - 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.

        - + 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.

        +

        -     The Shorewall two-interface sample configuration assumes that the - external interface is eth0 and the internal interface is eth1. - If your configuration is different, you will have to modify the sample - /etc/shorewall/interfaces file - accordingly. While you are there, you may wish to review the list of options - that are specified for the interfaces. Some hints:

        - +     The Shorewall two-interface sample configuration assumes that + the external interface is eth0 and the internal interface is +eth1. If your configuration is different, you will have to modify +the sample /etc/shorewall/interfaces +file accordingly. While you are there, you may wish to review the list +of options that are specified for the interfaces. Some hints:

        +
          -
        • +

        • If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

          -
          • -
        • + you can replace the "detect" in the second column with "-".

          +
          • +

        • If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

          -
          • - + or if you have a static IP address, you can remove "dhcp" from the +option list.

          + +
        - +

        IP Addresses

        - +

        Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic - Host Configuration Protocol (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 static IP address; that -means that you configure your firewall's external interface to use that -address permanently. 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 Private IP address ranges for this purpose:

        - -
        + Protocol (IP) addresses. Normally, your ISP will assign you a +single Public IP address. This address may be assigned via the +Dynamic Host Configuration Protocol (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 static IP address; +that means that you configure your firewall's external interface to use +that address permanently. 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 Private IP address ranges for this purpose:

        + +
             10.0.0.0    - 10.255.255.255
             172.16.0.0  - 172.31.255.255
             192.168.0.0 - 192.168.255.255
        -
        - -
        +
        + +

        -     Before starting Shorewall, you should look at the IP address -of your external interface and if it is one of the above ranges, you -should remove the 'norfc1918' option from the external interface's entry -in /etc/shorewall/interfaces.

        -
        - -
        +     Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you + should remove the 'norfc1918' option from the external interface's +entry in /etc/shorewall/interfaces.

        +
        + +

        You will want to assign your addresses from the same sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet - will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 -is reserved as the Subnet Address and x.y.z.255 is reserved as -the Subnet Broadcast Address. In Shorewall, a subnet is described - using Classless InterDomain Routing (CIDR) - notation 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.

        -
        - -
        + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet + will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 + is reserved as the Subnet Address and x.y.z.255 is reserved as + the Subnet Broadcast Address. In Shorewall, a subnet is + described using Classless +InterDomain Routing (CIDR) notation 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.

        +
        + +

        Example sub-network:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
        Range:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        Range:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        -
        -
        - -
        + +
        + +

        It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

        -
        - -
        + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

        +
        + +

        One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, -systems send packets through a  gateway  (router).

        -
        - -
        + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

        +
        + +

        -     Your local computers (computer 1 and computer 2 in the above -diagram) should be configured with their default gateway to be -the IP address of the firewall's internal interface.     

        -
        - +     Your local computers (computer 1 and computer 2 in the above + diagram) should be configured with their default gateway to +be the IP address of the firewall's internal interface.      +

        +
        +

        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 "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        - + regarding subnetting and routing. If you are interested in learning more + about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        +

        The remainder of this quide will assume that you have configured - your network as shown here:

        - + your network as shown here:

        +

        -

        - +

        +

        The default gateway for computer's 1 & 2 would be 10.10.10.254.

        - +

        IP Masquerading (SNAT)

        - +

        The addresses reserved by RFC 1918 are sometimes referred - to as non-routable 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 Network Address Translation (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.

        - + to as non-routable 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 Network Address Translation + (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.

        +

        On Linux systems, the above process is often referred to as IP Masquerading but you will also see the term Source Network Address Translation (SNAT) used. Shorewall follows the convention used with Netfilter:

        - +
          -
        • +

        • Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

          -
          • -
        • + firewall system automatically detect the external interface address. +

          +
          • +

        • SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local network - to use.

          -
          • - + the source address that you want outbound packets from your local network + to use.

          + +
        - +

        In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading - if your external IP is dynamic and SNAT if the IP is static.

        - + entries in the /etc/shorewall/masq file. You will normally use Masquerading + if your external IP is dynamic and SNAT if the IP is static.

        +

        -     If your external firewall interface is eth0, 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.

        - +     If your external firewall interface is eth0, 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.

        +

        -     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.

        - -

        Port Forwarding (DNAT)

        - -

        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.

        - -

        The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure port - forwarding using DNAT rules in the /etc/shorewall/rules file.

        - -

        The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:<server local ip address> [:<server - port>]<protocol><port>  
        -
        - -

        Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

        - -
        - - - - - - - - - - - - - - - - - - - - - - -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:10.10.10.2tcp80  
        -
        - -

        A couple of important points to keep in mind:

        - +     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.
        +
        + +     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:
        +

        +
          -
        • You must test the above rule from a client outside of your local - network (i.e., don't test from a browser running on computers 1 or 2 -or on the firewall). If you want to be able to access your web server -using the IP address of your external interface, see Shorewall FAQ #2.
          • -
        • 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.
          • - +
        • NAT_ENABLED=Yes
          • +
        • IP_FORWARDING=On
          +
          • +
        - -
        + +

        Port Forwarding (DNAT)

        + +

        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.

        + +

        The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

        + +

        The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

        + +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:10.10.10.2:80tcp5000  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:<server local ip address> [:<server + port>]<protocol><port>  
        -
        - -

        -     At this point, modify /etc/shorewall/rules to add any DNAT rules - that you require.

        - -

        Domain Name Server (DNS)

        - -

        Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your -primary and secondary name servers. Regardless of how DNS gets configured -on your firewall, it is your responsibility to configure the resolver -in your internal systems. You can take one of two approaches:

        - +
        + +

        Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:10.10.10.2tcp80  
        +
        + +

        A couple of important points to keep in mind:

        +
          -
        • +
        • You must test the above rule from a client outside of your + local network (i.e., don't test from a browser running on computers + 1 or 2 or on the firewall). If you want to be able to access your web + server using the IP address of your external interface, see Shorewall FAQ #2.
          • +
        • 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.
          • + +
        + +
        + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetloc:10.10.10.2:80tcp5000  
        +
        + +

        +     At this point, modify /etc/shorewall/rules to add any DNAT +rules that you require.

        + +

        Domain Name Server (DNS)

        + +

        Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (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 name servers for you to manually configure as your + primary and secondary name servers. Regardless of how DNS gets configured + on your firewall, it is your responsibility to configure the resolver + in your internal systems. You can take one of two approaches:

        + +
          +

        • 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.

          -
          • -
        • + 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.

          +
          • +

        • -     You can configure a Caching Name Server on your firewall. - 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. -

          -
          • - +     You can configure a Caching Name Server on your firewall. + 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.

          + +
        - -
        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53  
        ACCEPTlocfwudp53  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53  
        ACCEPTlocfwudp53  
        -
        - -
        +
        + +

        Other Connections

        -
        - -
        +
        + +

        The two-interface sample includes the following rules:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnettcp53  
        ACCEPTfwnetudp53  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnettcp53  
        ACCEPTfwnetudp53  
        -
        -
        - -
        + +
        + +

        Those rules allow DNS access from your firewall and may be - removed if you uncommented the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

        -
        - -
        + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

        +
        + +

        The sample also includes:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22  
        -
        -
        - -
        + +
        + +

        That rule allows you to run an SSH server on your firewall - and connect to that server from your local systems.

        -
        - -
        + and connect to that server from your local systems.

        +
        + +

        If you wish to enable other connections between your firewall - and other systems, the general format is:

        -
        - -
        -
        + and other systems, the general format is:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>  
        -
        -
        - -
        + +
        + +

        Example - You want to run a Web Server on your firewall system:

        -
        - -
        -
        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp80#Allow web accessfrom the internet
        ACCEPTlocfwtcp80#Allow web accessfrom the local network
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp80#Allow web accessfrom the internet
        ACCEPTlocfwtcp80#Allow web accessfrom the local network
        -
        -
        - -
        + +
        + +

        Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on your firewall"

        -
        - -
        + listed above under "You can configure a Caching Name Server on your + firewall"

        +
        + +

        If you don't know what port and protocol a particular application uses, look here.

        -
        - -
        +
        + +

        Important: 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:

        -
        - -
        -
        + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

        +
        + +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22  
        -
        -
        - -
        + +
        + +

        -     Now edit your /etc/shorewall/rules file to add or delete other - connections as required.

        -
        - -
        +     Now edit your /etc/shorewall/rules file to add or delete +other connections as required.

        +
        + +

        Starting and Stopping Your Firewall

        -
        - -
        +
        + +

        Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start -Shorewall before configuration is complete. Once you have completed configuration -of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
        -

        - +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file +/etc/shorewall/startup_disabled.
        +

        +

        IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
        -

        -
        - -
        + and set 'startup=1'.
        +

        +
        + +

        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 /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

        -
        - -
        + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

        +
        + +

        -     The two-interface sample assumes that you want to enable routing - to/from eth1 (the local network) when Shorewall is stopped. If - your local network isn't connected to eth1 or if you wish to enable - access to/from other hosts, change /etc/shorewall/routestopped accordingly.

        -
        - -
        +     The two-interface sample assumes that you want to enable +routing to/from eth1 (the local network) when Shorewall is stopped. +If your local network isn't connected to eth1 or if you wish to +enable access to/from other hosts, change /etc/shorewall/routestopped +accordingly.

        +
        + +

        WARNING: 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 /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

        -
        - -

        Last updated 11/21/2002 - alternate configuration + and test it using the "shorewall try" command.

        + + +

        Last updated 12/20/2002 - Tom Eastep

        - +

        Copyright 2002 Thomas - M. Eastep

        + M. Eastep

        +
        +
        +

        +



        diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh index 7c483f676..ca3e10a6b 100755 --- a/Shorewall/fallback.sh +++ b/Shorewall/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.12-Beta3 +VERSION=1.3.12 usage() # $1 = exit status { diff --git a/Shorewall/install.sh b/Shorewall/install.sh index cb03868d5..166ddc017 100755 --- a/Shorewall/install.sh +++ b/Shorewall/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.12-Beta3 +VERSION=1.3.12 usage() # $1 = exit status { diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec index aef244263..05b8bcaf1 100644 --- a/Shorewall/shorewall.spec +++ b/Shorewall/shorewall.spec @@ -1,6 +1,6 @@ %define name shorewall %define version 1.3.12 -%define release 0Beta3 +%define release 1 %define prefix /usr Summary: Shoreline Firewall is an iptables-based firewall for Linux systems. @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Fri Dec 27 2002 Tom Eastep +- Changes version to 1.3.12 * Sun Dec 22 2002 Tom Eastep - Changes version to 1.3.12-0Beta3 * Fri Dec 20 2002 Tom Eastep diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh index 6268ebe0a..6bb0492cc 100755 --- a/Shorewall/uninstall.sh +++ b/Shorewall/uninstall.sh @@ -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-Beta3 +VERSION=1.3.12 usage() # $1 = exit status {